float computation: Mac M1 result changes by adding a print

[catenacyber]

What version of Go are you using (go version)?

$ go version
go version go1.18.4 darwin/arm64

Does this issue reproduce with the latest release?

Indeed

What operating system and processor architecture are you using (go env)?

Mac M1

go env Output

$ go env
GO111MODULE=""
GOARCH="arm64"
GOBIN=""
GOCACHE="/Users/pantione/Library/Caches/go-build"
GOENV="/Users/pantione/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/pantione/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/pantione/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct/"
GOROOT="/usr/local/go"
GOSUMDB="[sum.golang.org](http://sum.golang.org/)"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_arm64"
GOVCS=""
GOVERSION="go1.18.4"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/tt/8bbr243n4_355hq5qwdw3mrr0000gn/T/go-build580019200=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Run https://go.dev/play/p/sTpGr_NKFLk

Then run it again commenting fmt.Printf("lol\n")

What did you expect to see?

The 2 programs printing diff 4.130183266666667e+07

What did you see instead?

The first program prints diff 4.130183266666664e+07 !

The second program prints diff 4.130183266666667e+07 alright

[catenacyber]

Using math.Float64bits I see a bit is flipped : 0x4183b1ba45555555 vs 0x4183b1ba45555556

[randall77]

This is likely increased accuracy due to fused multiply-add instructions. See, e.g. #52293 #44528

[catenacyber]

Thanks @randall77

It looks like it as vi.m2 += delta * (value - vi.Mean)-> vi.m2 += float64(delta * (value - vi.Mean)) gets always 0x4183b1ba45555556

Why does this optimization depend on the presence of fmt.Print ?

[randall77]

Probably because with the extra call, something needs to get spilled/restored around that call. That spill/restore will prevent some op fusing that would otherwise happen.
Just a guess, I haven't actually looked at the code.

Closing, as this seems to be working as intended. Please reopen if you still see anything unexpected.