Change:
<del> Subproject commit ecd2b1f6d689d5afbf5debe8afb3739337323852 </del> <ins> Subproject commit 3bc0272cab9fdcfc2ef4df9625ec3c9d5909db79 </ins>

Discussion:
I just tried builds of 1.13.0-beta.3 on and (with LLVM 3.8 and 3.9 respectively), and both builds failed only on armv7hl, in the exact same place: That full function is: This particular code hasn't changed in over a year, and my i686, x86_64, and aarch64 builds were fine with it. Only armv7hl has the error, and note even then it wasn't until . I had no problem with armv7hl on prior releases, so this appears to be a beta regression. I do have one patch applied from to disable NEON, but I also had that on 1.12.1 and it went fine. I'm baffled what else could be specific to armv7hl to cause this...
This could be related to and it's fix (rust-lang/compiler-rt), now maybe the opposite situation (if the compiler uses some of the builtins during the unreachability checking). cc
Just to check: is armv7hl your host architecture? which compiler are you bootstrapping from?
Yes, Fedora builds always use native hosts. These are bootstrapping from Fedora's own 1.12.1. I could start a build using upstream bootstrap binaries, if that's a useful data point
Mh, no I think 1.12.1 was not affected by that bug, so using the upstream binaries wouldn't help, I think.
If you want, you could try with rust-lang/compiler-rt reverted, although I'm not really sure how much that will help, the code responsible for pattern checking does not seem to need any builtins from a quick glance.
I started a build with that reverted, if you care to watch paint dry... However, assuming your fix was correct, there are two more places with explicit "aapcs": and , used in support of the asm and . These sound like functions that could be used in pattern checking, but I don't know how you're checking this. Of course the ABI of each needs to match what the asm caller expects. But this seems to open a big can of worms if all of those are using the wrong ABI, not matching their_ callers.
Then that is probably the real problem. I just looked around a bit in , and found that from a glance, only was used on floats.

I expected the to not use any builtins since this is a hard float target (is it not?).
Yes, it's hard float, but not NEON if that matters to your point. Actually, I have another build going without that patch, in case NEON does make a difference.
Alright, so parsing floats seems to be broken (printing constants works fine): Test program: For input , the output is . So the comparisons / match checking are probably fine but the parsed floats are bad. Edit: This was compiled with the official rust beta binaries. cc
Edit: forget that, I must have confused something, I cannot reproduce on either of those nightlies.
The NEON build (withholding ) still failed in the same way. The build with reverted rust-lang/compiler-rt is still going, but it just got past that failure point of librand , so it seems in good shape so far.
Alright, so with the test program above, the current beta, running on an RPi 2 with armv7-unknown-linux-gnu, I observer the following: the parsing code calls returns the (correct) value in ; the callee of expects the result in , the callee is , which is just an
So, this is ... interesting. According to this , for eabihf ("hard float") target, libgcc calls floating point intrinsics, like "floatundidf", using the hard float convention (argument passing over FPU registers (s0, d0, etc.)) (FWIW, this seems consistent to me, it respects the global calling convention, the "hf" in gnueabihf) whereas clang/llvm calls them using the soft float convention (argument passing over "general purpose" registers (r0, r1)). It seems that llvm does that because libgcc used to do it that way but libgcc (apparently) broke its ABI and changed from soft float to the current hard float ABI. So, what to do. For gnueabihf, we should compile these floating point intrinsics using the soft float convention because that's how LLVM call these intrinsics. Except for the powisf2 intrinsic, that should be compiled using the hard float convention to avoid re-introducing . It's weird that LLVM calls some floating point intrinsics using the soft float convention but others with the hard float one ... but we have to do what LLVM dictates.

Is that really LLVM's doing? I see the intrinsics explicitly declared by rustc and , but I haven't found the same for / . That makes me wonder if perhaps LLVM is internally using consistent soft float for these, when they are implicitly , whereas the calls generated for intrinsics by Rust are using the default hard float ABI. Maybe there's some attribute missing on Rust's declarations to get the right code generation out of it.
Yeah, that seems to be the case. You mean to call powi using the soft float convention? would work I think but the intrinsic is already . IMO, all the intrinsics should use hard float because that's the global setting. It'd be better if we could make that work.
I have found new discreps in stable vs beta in
IIRC you can tag a instruction in LLVM with the calling convention, so presumably if compiler-rt compiles all intrinsics (not just those in C) with the aapcs calling convention then for these platforms we should tag the calls to intrinsics with that calling convention? Hm... I'm not so sure any more. Compiling this: with clang yields: That is, nothing weird with calling conventions here. What's going on?!
I think we should be consistent. Going fully hard float would be ideal, but we'd have to figure out how to influence the LLVM internal calls, as well as fork all the asm implementations in for hard float. Getting Rust's calls like powi to use soft float seems like it will be an easier task for now.
This is a beta regression that will be on stable Thursday.
Ok I've and believe ironically fixes everything, and I've to update to that compiler-rt.
Note that since the official Rust builds were not fixed, those armhf 1.13.0 binaries won't be usable as a host stage0 to build 1.14.0. I just tried such a build for the new beta, and it failed right away, segfault compiling libcore. Using Fedora's own 1.13.0 binary (patched with rust-lang/compiler-rt) does appear to work so far as stage0 for the beta.