Change:
<del> Subproject commit 8598065bd965d9713bfafb6c1e766d63a7b17b89 </del> <ins> Subproject commit f03ba5a4e8bf16dcf42dd742a4ce255c36321356 </ins>

Discussion:
using . Affected targets: - - This test passes if the crate is compiled with optimizations () enabled. This test passes if compiled with the nightly from 2016-09-13. Given that this test passed two days ago and the list of affected targets, IMO the prime suspect is the recent change related to compiler-rt intrinsics: . Because this test is likely to involve some compiler-rt intrinsic for the affected targets (no FPU). Disclaimer: This test was executed under QEMU. There is a chance this is actually a QEMU bug/failure. cc
Yay smoke!
Float ABI mismatch maybe? We recently switched MIPS to a different float ABI in rustc side, perhaps compiler-rt simply didn’t follow the suite?
triage: P-high
More details: This test is about converting an to . Targets without FPU lower this operation to the intrinsic on ARM or to the one on other architectures. (Both intrinsics have the exact same C implementation, they just have different names on different architectures) Before was merged, this test was using the implementation of this intrinsic (at least on the affected targets). After was merged, this test started using the implementation of this intrinsic. I'm inclined to think that the implementation of this particular intrinsic has some bug. It's possible. We may not be compiling with the right gcc flags or something like that. But I would expect way more test failures if the cause of the problem was ABI mismatch. This was the only test failure from running the unit tests of all the standard crates (see ). For example, the relies on a bunch of intrinsics (both float and non-float related) but only failed on this test and not on the other tests that also involve a integer -float conversion.
After spending much time to establish a test environment, I can reproduce the issue and have found at least one bug in the compiler-rt software floating point routines. In particular, this line: to save you the trouble of following the link, its this: That does not properly handle the case where is already the minimum (negative) value. It needs to instead start by promoting to the wider type before doing things like negation on it. Update: see comments below. In particular, effort has been expended to handle this case, but I still think I'm seeing evidence of something being mishandled down the line.

(Incidentally, I found this bug relatively quickly because I decided to take the C code, once I found it, and port it to Rust before doing things like instrumenting it to inspect the intermediate results. And of course (ta da!) our arithmetic overflow checking catches this case.)
Bravo! Overflow checks pay off. :clap: If you still have your port around, we'd be happy to integrate it into , where we are porting compiler-rt intrinsics to Rust. We'll integrate rustc-builtins into rust-lang/rust at some point the future (hopefully, soon).
yeah I'm still actively working on the port. (That negation issue I raised above is only the first arithmetic overflow that was detected along the control flow; I'm now dissecting a second overflow to determine if it is a mistake in the port or another bug in the original code.)
(further update: comments in code further down indicate that they are aware of potential for INT_MIN to leak in, which means I was wrong up above; but still, seems like something is wrong with this code.)
Oh is negating is undefined behavior in C (for two's complement representation)? ... so even if the code down below tries to compensate for it, it is still a big bug to have that line there?
Seems like if I revise the code to convert the parameter to an at the outset and use for negation when necessary (the portable way to negate that "works" on ), then the problem goes away.