I'm still trying to figure out what was wrong with #48, and I'd like another pair of eyes on this because I have no idea what is going on. I added an implementation of `arbitrary_float!` again, and [ran the tests](https://travis-ci.org/mattico/rustc-builtins/builds/164723455). Only [the arm-unknown-linux-gnueabi target](https://travis-ci.org/mattico/rustc-builtins/jobs/164723458#L811) failed. So I grab the arguments that made the test fail and [put them into a regular test](https://github.com/mattico/rustc-builtins/commit/1dd0832a952d2f80ef273cb819b106f1553bc431). On the next build, [the test passes](https://travis-ci.org/mattico/rustc-builtins/jobs/164727780#L784) because we're actually getting the [right answer](https://www.wolframalpha.com/input/?i=0.000000000000000000000000000000000000011540496-0.00000000000000000000000000000000000000359621) in this case. It's gcc_s and compiler-rt that have the wrong answer. Either: 1. There's some subtle bug in the test infrastructure 2. gcc_s and libcompiler-rt both have the same bug but we don't despite the code being almost identical to compiler-rt 3. QEMU is broken but only in this specific way 4. The C compiler's optimizations cause rounding in very small numbers, but rustc does not 5. Something else?