-
Notifications
You must be signed in to change notification settings - Fork 214
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Floating point add gives different results than compiler-rt on arm-unknown-linux-gnueabi #90
Comments
Oh that's actually a really good point that we should always compile compiler-rt with optimizations. Right now compiler-rt is conditionally optimized, but gcc_s is pulled in from the system so I think that's always optimize. |
Do the errors go away if you test with optimizations enabled ( Are these roundings,
This should be a simple change in the build.rs via gcc::Config (I expect) But ... enabling optimizations shouldn't change the results of the compiler-rt intrinsics, right? That doesn't sound quite right. You should get the same output regardless of the optimization level. |
No, release builds don't change our results. Our answer agrees with wolfram alpha which uses arbitrary precision arithmetic so it seems like I feel like I was a bit unclear about this so here is a table: Answers for 1.1540496e-38 + -3.59621e-39 on arm-unknown-linux-gnueabi
The I think it's still possible that gcc is less strict about reordering or combining float operations than rust/llvm, but this page makes it look like that only happens with non-standard flags so perhaps that is not the case. I'm going to start looking at the disassembly since it doesn't seem like there's a simple answer. |
Hmm. The Rust disassembly is much longer and uses many more registers than the C version. I was expecting them to be a bit more similar. I guess it's time to install IDA. |
Compiling compiler-rt with clang gives an assembly output that is much more similar to the rust version. I'm going to see if it gives the same results. |
That makes given that both clang and rust are based on LLVM. This sounds like gcc has different defaults around rounding compared to LLVM.
Perhaps try compiling compiler-rt using the "full IEEE 754 compliance" flags: -frounding-math -fsignaling-nans. It seems that gcc defaults to not being fully compliant with IEEE 754. I wonder if LLVM is fully compliant with IEEE 754 by default; that could be the difference. |
Adding the flags didn't change anything. |
I used a little C program to test the compiler-rt version of |
😕 So, uhmm, calling the same function from C vs from Rust produces different output? Could this be a calling convention problem? Seems unlikely though as you only get different outputs (between C and Rust) for a few inputs. The only other thing I can think about is side effects: it's possible to change the rounding mode using |
@japaric Yeah I agree it's a bit strange... I'm still investigating. Here's a rough summary of what I did (from memory):
And I did the equivalent for clang as well. I'll look into the crt initialization stuff to see if they mess with floating point rounding. I guess I should also make an equivalent rust program, which should tell us if the error only happens inside our |
I'm currently looking into two possible theories:
|
@mattico I don't think 2. will be the issue as that only affects hard float. |
I don't know if it may be related to this but i noticed that when the test starts running, QEMU complains about |
@ithinuel I see that all the time when running Rust programs compiled for ARM under QEMU. Never bothered investigating but it hasn't been an issue with programs that don't do (too many) floating point operations. |
That's the |
So, using a recent nightly, I tested changing the intrinsics that involve floating point arguments/return values from |
@japaric Did you change the ABI for the |
@Amanieu No, I didn't because those functions get immediately turned into
I only tested changing the calling convention of addsf3 and adddf3 as those are the only intrinsics that are causing problems. Here are my changes: https://gist.github.com/japaric/13755ba481a6cd1199fd07f2f32d8c1e |
@japaric This line should use "aapcs" instead of "C":
EDIT: ah nevermind, I see you duplicated the whole thing just for aapcs |
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. Only the arm-unknown-linux-gnueabi target failed. So I grab the arguments that made the test fail and put them into a regular test. On the next build, the test passes because we're actually getting the right answer in this case. It's gcc_s and compiler-rt that have the wrong answer.Either:
The text was updated successfully, but these errors were encountered: