https://go.dev/play/p/uU_6sbW3r5E
it isn't be able to reproduce.
run perfect 0 and 0 response

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

I did bisect the changes and this issue appears to have been fixed by CL498795, issue #59399.

@bcmills I wonder if we should consider this for backporting to 1.21

This is just extra accuracy provided by FMA (fused multiply-add). Run with -gcflags=-d=fmahash=0 and you'll get the answer you expected.

The difference between f1 and f2 is that f2 inlines and f1 doesn't. That lets the computation in f2 be done entirely at compile time, which doesn't do FMA. If you add a //go:noinline directive to f2, it computes the same answer.

The problem you're seeing is that b := a*a isn't exact, but the computation b-a*a is exact, exactly using the not-quite-the-square-of-a value of b.

@dr2chase Thanks for the flag!

Note that this optimization is explicitly mentioned in the spec.

Per https://go.dev/ref/spec#Floating_point_operators:

An implementation may combine multiple floating-point operations into a single fused operation, possibly across statements, and produce a result that differs from the value obtained by executing and rounding the instructions individually. An explicit floating-point type conversion rounds to the precision of the target type, preventing fusion that would discard that rounding.

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.

adding severely undocumented compiler flags or inline directives to the program to make its behavior consistent

We are suggesting neither of those fixes. They aren't intended for end users, they are just to help with debugging issues like this.
The right fix is mentioned in the spec, adding a float64 cast in places where you want to force rounding.

@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.