Repository navigation
LLVM generates incorrect code with -Zprofile #70148
Description
Instructions to reproduce:
git clone git@github.com:servo/html5ever.gitcd html5ever/markup5everCARGO_INCREMENTAL=0 RUSTFLAGS="-Zprofile -Ccodegen-units=1 -Cinline-threshold=0" cargo check- The build script of
markup5eversegfaults.
The actual function with the bug is an instance std::panicking::try in the proc_macro2 crate.
The cause seems to be an LLVM bug.
This LLVM IR is generated:
catch.i: ; preds = %.noexc
%120 = phi i64* [ getelementptr inbounds ([24 x i64], [24 x i64]* @__llvm_gcov_ctr.27, i64 0, i64 11), %.noexc ], !dbg !2861
%121 = landingpad { i8*, i32 }
catch i8* null, !dbg !2861
%122 = load i64, i64* %120, !dbg !2861
%123 = add i64 %122, 1, !dbg !2861
store i64 %123, i64* %120, !dbg !2861```Notice how the phi is inserted before the landingpad instruction. This causes the following asm to be generated:
.LBB27_14: // This is never executed
.loc 27 0 15 is_stmt 0
movq 160(%rsp), %rcx
movl $1, %esi
.Ltmp379: // Landing pad points to here!!!
leaq __llvm_gcov_ctr.27(%rip), %rdi
addq $120, %rdi
.loc 27 274 15
movq (%rcx), %r8
addq $1, %r8
movq %r8, (%rcx)So basically the initialization of %rcx is getting skipped by the incorrect landing pad, which in turn causes the crash.
Edit by @Amanieu, original bug report follows.
Just updated nightly on my CI machine
nightly-aarch64-unknown-linux-gnu updated - rustc 1.44.0-nightly (f509b26 2020-03-18) (from rustc 1.43.0-nightly (c20d7ee 2020-03-11))
and found out that tests stopped compiling few of dependencies like cssparser or string_cache or html5ever.
It probably happens because of my RUSTFLAGS
CARGO_INCREMENTAL=0;
RUSTFLAGS="-Zprofile -Ccodegen-units=1 -Cinline-threshold=0 -Coverflow-checks=off -Zno-landing-pads";
I created repository with reproduction
https://github.com/Lesiuk/rust-nightly-issue-reproduction
Bissect found that this PR introduced this issue #67502
searched toolchains c20d7ee through 3c6f982
regression in be055d9
Log from test run
Compiling html5ever v0.25.1
error: failed to run custom build command forhtml5ever v0.25.1Caused by:
process didn't exit successfully:/Users/XXXXXX/CLionProjects/issue/target/debug/build/html5ever-1a979961379450d7/build-script-build(signal: 6, SIGABRT: process abort signal)
--- stdout
cargo:rerun-if-changed=/Users/XXXXXX/.cargo/registry/src/github.com-1ecc6299db9ec823/html5ever-0.25.1/src/tree_builder/rules.rs--- stderr
fatal runtime error: failed to initiate panic, error 5warning: build failed, waiting for other jobs to finish...
error: build failed
Activity
Mark-Simulacrum commentedon Mar 19, 2020
cc @Amanieu, perhaps related to #67502
Mark-Simulacrum commentedon Mar 19, 2020
Is there a reason you're passing -Zno-landing-pads? I believe in ~all cases you should either be doing -Cpanic=abort today, no-landing-pads is likely to lead to problems... but it would be odd for that to lead to trouble in the compiler I think
Lesiuk commentedon Mar 19, 2020
Yes. I just updated my description of the issue. Bissect found this PR.
Lesiuk commentedon Mar 19, 2020
Those flags are recommended by mozilla's grcov tool:
https://github.com/mozilla/grcov
Amanieu commentedon Mar 19, 2020
Does this problem still happen with
-C panic=abortinstead of-Z no-landing-pads?Amanieu commentedon Mar 19, 2020
-Z no-landing-padswill causecatch_unwindto be optimized away with the new implementation. This is why the runtime can't initiate a panic: it can't find a catch for the exception.I would recommend either using
-C panic=abortor just removing-Z no-landing-pads.Lesiuk commentedon Mar 19, 2020
Changed my RUSTFLAGS to
and still crashes.
Amanieu commentedon Mar 19, 2020
Minimal reproduction:
RUSTFLAGS=-Zprofile CARGO_INCREMENTAL=0 cargo checkOutput:
cargo-bisect-rustc points to e2223c9 as the source of the regression, which seems a bit surprising.
7 remaining items
jonas-schievink commentedon Mar 19, 2020
Unnominating since this requires an unstable compiler flag to trigger
Amanieu commentedon Mar 19, 2020
Instructions to reproduce:
git clone git@github.com:servo/html5ever.gitcd html5ever/markup5everCARGO_INCREMENTAL=0 RUSTFLAGS="-Zprofile -Ccodegen-units=1 -Cinline-threshold=0" cargo check(NOTE:-Cdebuginfo=0will cause the bug to no longer trigger)The actual function with the bug is an instance
std::panicking::tryin the proc_macro2 crate.Lesiuk commentedon Mar 20, 2020
-Cdebuginfo=0basically disables-Zprofilebecause no gcda files are generated. This miscompilation is kinda sad because mozilla's grcov is the most reliable coverage tool for rust. And if you want to have your rust application very well tested coverage is kinda important.I will probably stick to
nightly-2020-03-11until It's not fixed but I can't use it indefinitely.[-]fatal runtime error: failed to initiate panic, error 5[/-][+]LLVM generates incorrect code with -Zprofile[/+]Amanieu commentedon Mar 20, 2020
LLVM bug: https://bugs.llvm.org/show_bug.cgi?id=45261
RalfJung commentedon Mar 20, 2020
Miri has supported panics for a while now. If there are still panic tests excluded by Miri, that's a bug. Do you have an example of such a test?
ssomers commentedon Mar 20, 2020
Never mind, I excluded should_panic tests when testing myself, since I don't know how to run them successfully.
PS and yes, with today's nightly Miri these tests succeed just like any other. I thought they didn't a month ago or so (memory leaks).
briansmith commentedon Mar 27, 2020
AFAICT using these flags is the only way to get code coverage reporting working. A lot of projects (all that I've been associated with) build everything with stable Rust but then do code coverage using nightly Rust + these unstable flags. Temporarily I've reverted back to a 2020-03-11 nightly for this as a workaround, but that workaround will stop working effectively in once Stable Rust is no longer a subset of the nightly-2020-03-11 feature set.
Amanieu commentedon Mar 28, 2020
Fixed in LLVM: rust-lang/llvm-project@e5bf503
Rollup merge of rust-lang#70527 - Amanieu:fix_fastisel, r=Mark-Simula…