Change:
While bootstrapping on Fedora 25 armv7l, I'm hitting a SIGILL when some beta-compiled programs are actually executed. This is with a purely default , no external LLVM or anything. On beta (exactly ), I get a little ways into stage1, and then build scripts SIGILL, apparently from double-panics. I reckon that the stable stage0 builds a stage1 compiler that's fine, then that stage1 starts building things that don't even need to execute until we get to a build script. Then: So I also tried the master branch (exactly ), and that fails as soon as it executes at the start of stage1. Here it seems that the downloaded beta stage0 compiler builds all of its stuff fine, which presumably includes executing some builds scripts like above. But the stage1 it creates seems to be bad: I traced through with gdb, and it's not actually crashing, rather the that it execs into. Here's the backtrace: That looks like a triple panic! The actual SIGILL is delivered for a instruction:
(side note: on the beta branch I have also applied , or else you have to configure with an explicit to get armv7.)
I tried to build a debug nightly, but it can't link to in stage0's librustcconstmath:
Looking at , it seems SIGILL is expected because of the . The questions are then, why did it panic in the first place and why did the default hook panic?
is where the default hook is panicking.
Yes, I agree the SIGILL is just a symptom of the nested panics, not something to fix in itself. While I couldn't get a debug build, I got a release build with debuginfo. Here's a better backtrace from running : So the first panic comes from the failed at frame called from . The line right before got a shared -- maybe something isn't marking this released properly? Then the nested panics come from trying to read this same broken , with frames and also trying to .
Looks like you are using an LLVM without the fix in . That will blatantly miscompile rustc and lead to severe problems.
While it does sound the same, unfortunately no, this is with the rust-bundled LLVM, including your fix. :/
That said, there must be something local going wrong, as the official (cross-build) armv7 compiler seems to work fine, at least with the same simple reproducer, e.g. . I'm going to try a fresh build on a fresh system with absolutely no local LLVM present...
So -- that worked, both beta and nightly. I'll make sure to update our distro LLVM patches. What tripped me up on nightly was that stage0 is still 1.17.0-beta.2, which doesn't have the LLVM fix. I bumped that to beta.3, and then it worked. This doesn't affect the official nightly builds because only the host compiler goes through stages, and AIUI the cross-compiled targets only use the host stage2. But doing a native arm compile, the bugged stage0 gave me an unusable stage1. On beta, I don't know what happened before. I think perhaps somewhere when I was jumping between local and rust-llvm and testing different branches, I must have gotten a build of the still-broken rust-llvm, with a timestamp such that rustbuild didn't think it needed rebuilding on the fixed sources. I still have that build directory tarballed here, so I may poke at it when I get a free moment.
So we should update 1.18's stage0?
OK, see to bump stage0.

Discussion:
# tarball for a stable release you'll likely see `1.x.0-$date` where `1.x.0` was # released on `$date` <del> rustc: beta-2017-03-21 </del> <ins> rustc: beta-2017-04-05 </ins>