-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
cmd/compile: miscompilation of simple arithmetic program targeting darwin/arm64 #62723
Comments
https://go.dev/play/p/uU_6sbW3r5E |
Seems like this only happens for arm64, I reproduced on darwin/arm64 with go 1.19/1.20/1.21. With tip it does not happen anymore. Not sure if it happens for arm as well. Godbolt output for 1.21 vs tip: https://go.godbolt.org/z/Eja7b8jEP cc @golang/arm |
This is just extra accuracy provided by FMA (fused multiply-add). Run with The difference between The problem you're seeing is that |
@dr2chase Thanks for the flag! |
Note that this optimization is explicitly mentioned in the spec. Per https://go.dev/ref/spec#Floating_point_operators:
|
thanks for the spec ref. but this is a quite surprising behavior. I've recently read rsc's post about optimizations affecting program behavior(maybe not a correctness in this case though, but still...). exploiting "unexact" floating point arithmetic inconsistently so that syntactically equivalent programs produces different results feels similar to exploiting undefined behavior in other programming languages as rsc mentioned in the post. adding severely undocumented compiler flags or inline directives to the program to make its behavior consistent and saying "in some languages, performance trumps everything, but golang is different" sounds pretty dubious to me. |
We are suggesting neither of those fixes. They aren't intended for end users, they are just to help with debugging issues like this. |
@y-sh0 Any programming language must make a choice for how to handle floating-point operations. They can aim to get identical results on all platforms, or they can aim to make programs run faster while permitting the possibility of different results. Go has made the latter choice, along with a clear procedure for how to get identical results when that is desirable. For the reason for this choice see, for example, https://people.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf. |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
Here's the reproducer.
What did you expect to see?
What did you see instead?
This also reproduces on linux/arm64.
The text was updated successfully, but these errors were encountered: