builtin: result of casting float64 NaN to int64 varies depending on GOARCH

[funa12]

Go version

go version go1.22.3 darwin/arm64

Output of go env in your module/workspace:

GO111MODULE=''
GOARCH='arm64'
GOBIN=''
GOCACHE='/Users/administrator/Library/Caches/go-build'
GOENV='/Users/administrator/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/administrator/go/1.22.3/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/administrator/go/1.22.3'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/Users/administrator/.goenv/versions/1.22.3'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/Users/administrator/.goenv/versions/1.22.3/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.22.3'
GCCGO='gccgo'
AR='ar'
CC='clang'
CXX='clang++'
CGO_ENABLED='1'
GOMOD='/dev/null'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/xn/03q51v9n6y9dbstz0jp6g_r00000gn/T/go-build240352322=/tmp/go-build -gno-record-gcc-switches -fno-common'

What did you do?

package main

import "math"

func main() {
	println(int(math.NaN()))
}

What did you see happen?

% go run ./main.go
0
% GOARCH=arm64 go run ./main.go 
0
% GOARCH=amd64 go run ./main.go
-9223372036854775808

What did you expect to see?

i think expect same results even different GOARCHs

[ianlancetaylor]

This is documented and expected. In the section https://go.dev/ref/spec#Conversions, under "Conversions between numeric types", the language spec says:

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.

The type int can't represent a NaN value, so the result is implementation dependent.

You may have better luck with math.Float64bits, but even that is not guaranteed to produce the same results on every implementation, as different implementations use different representations for NaN values produced by expressions.