cmd/compile: float64 to int64 conversion gives different result between amd64 and arm64 on overflows

[aderouineau]

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

$ go version
go version go1.16.3 darwin/amd64

$ go version
go version go1.16.3 linux/arm64

Does this issue reproduce with the latest release?

Yes

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

go env Output (amd64)

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/derouin/Library/Caches/go-build"
GOENV="/Users/derouin/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/derouin/go/pkg/mod"
GONOPROXY="*"
GONOSUMDB="*"
GOOS="darwin"
GOPATH="/Users/derouin/go"
GOPRIVATE="*"
GOPROXY="direct"
GOROOT="/usr/local/Cellar/go/1.16.3/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.16.3/libexec/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.16.3"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/dev/null"
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 x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/2m/168135fn6l73g8k7h7rmzdsc_h4s04/T/go-build1167711572=/tmp/go-build -gno-record-gcc-switches -fno-common"

go env Output (arm64)

$ go env
GO111MODULE=""
GOARCH="arm64"
GOBIN=""
GOCACHE="/home/derouin/.cache/go-build"
GOENV="/home/derouin/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/derouin/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/derouin/go"
GOPRIVATE=""
GOPROXY="direct"
GOROOT="/local/home/derouin/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/local/home/derouin/go/pkg/tool/linux_arm64"
GOVCS=""
GOVERSION="go1.16.3"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build70387541=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Run the following small program on amd64 and arm64: https://play.golang.org/p/8nY1Dwgq-BU

What did you expect to see?

Same result on both platforms.

What did you see instead?

-9223372036854775808 on amd64 and 9223372036854775807 on arm64.

[mknyszek]

For some reason I think this is actually implementation-define behavior, but I'll have a look at the spec real quick. Will CC people in if I can't figure it out.

[mknyszek]

Yes, this appears to be working-as-intended.

From https://golang.org/ref/spec#Conversions:

In all non-constant conversions involving floating-point or complex values, if the result type cannot represent the value the conversion succeeds but the result value is implementation-dependent.

That's what specified now. If you think it should work differently, please file a proposal issue for it. Closing this one for now.

[mknyszek]

FWIW #6923 seems somewhat related (I think for constants this sort of conversion may be well-defined), but I don't actually see any proposals. I believe for constants these non-representable conversions are caught at compile-time.

[aderouineau]

@mknyszek Can you clarify "implementation-dependent" and how to contact the corresponding contributors?

[mknyszek]

I think it means specifically that Go implementations are free to choose the behavior, which includes allowing these differences across architectures. I suspect this particular rule is chosen as a performance optimization.

In general, the result of such a conversion is fairly non-sensical when you can't represent some value in the new type. By allowing a broad range of behaviors, the compiler is able to generate faster code by not having to deal with the case where the conversion fails. Note that there are lots of places where Go doesn't choose implementation-defined behavior for both platform compatibility and just general programmer sanity, but to me this particular case seems sensible because one frequently can't do anything much with such a conversion.

If you'd like to start a discussion about this, the golang-nuts group is a good place to do so. If you have a specific proposal in mind for how this should work, feel free to file a new issue about it with "proposal:" in the title.