Change:
("i686-unknown-linux-musl", i686_unknown_linux_musl), ("mips-unknown-linux-musl", mips_unknown_linux_musl), ("mipsel-unknown-linux-musl", mipsel_unknown_linux_musl), <ins> ("mips-unknown-linux-uclibc", mips_unknown_linux_uclibc), ("mipsel-unknown-linux-uclibc", mipsel_unknown_linux_uclibc), </ins> ("i686-linux-android", i686_linux_android), ("arm-linux-androideabi", arm_linux_androideabi),

Discussion:
Hi all, Asked about this in rust-beginners and was advised it's probably a bug. On MIPS (specifically, on the , ) I'm getting different (incorrect) results from a function that does a bit of math, depending on: if I'm accessing a struct variable from self if I'm taking method arguments if and where the println!'s are in the method the size of the primitives I'm using to calculate each intermediate part (not an issue on my OS X desktop or the playground) Here's a with my ideal variation of the method; ideally, it should compute baud(9600) = . On MIPS, depending on the various factors I've listed above, I've seen varying results including 0 and . From what I can tell, this is falling apart with the floor() call (which appears to be an intrinsic - something I've seen others have difficulty with on MIPS). Take this snippet: Gives the output: (where 5: should be ). If I add another intermediate local in between part4 and part5 (), both and have the 0.0002 value when printed. However, I can seemingly coerce it into working by putting a println! in the right place: This returns the correct result, even on MIPS.
Also, seems like I can make the problem go away by making my own floor(): .. computes the correct result.
Hmm, might be a constant-folding issue. I made a C version of the code and it produces the same ASM as the Rust version on x86. A function that just supplies 9600 to is constant folded to the expected value. I also looked at the MIPS output from clang to see if anything was wrong there, but it looks fine. Furthermore, the constant-folding is correct here. Could you post the MIPS ASM of this please: As setting up a MIPS toolchain is proving difficult.
Are you sure the float ABI between Rust and system libc matches? If the floor intrinsic lowers down to a libc call and the ABI mismatches, then you’ll see weird results like these with any non-native float op. Things to try: .
See and and which are all considerably recent changes to MIPS targets’ float ABI.
I was checking the tessel-rust repository and saw this line: The target system is running uclibc. targets glibc_-based mips systems.

This combination is not guaranteed to work (You are actually lucky it has been working so far). There is also the issue that mentioned: this target now produces hard float ABI code, the toolchain (the C libraries in it) adds soft float ABI code; this combination is a recipe for problems -- one must not mix code with different float ABIs. In conclusion, you want to create and use a target that's tailored for these platforms (OpenWRT 15.05 platforms). The other option is to run OpenWRT trunk, which is musl based, on the Tessel, then you can, instead, use the target, which already exists.
Hey all, thanks so much for all the investigation and deep dive into this. One of the Tessel developers also pointed me to with the same findings. Please feel free to resolve, I'll see about updating the target. Thanks again!
Appropriate targets for this use case (OpenWRT 15.05 on MIPS, e.g. Tessel 2) landed in . Proper support for these targets in libc is being tracked in rust-lang/libc, which contains instructions about how to update libc and run its test suite. Once libc is updated perhaps we can start building binary releases of std for these targets. cc
rust-lang/libc is still open. As I understand it, this specific issue isn't tracking more than "build binary releases of std" which isn't something we currently want to track as far as I know, so I'm going to close this issue. If people are interested, please ask on for instructions on how to add a platform to Rust's standard builds.