cmd/compile: float/int conversion differences from CL 691135 causing failures

[jakebailey]

Go version

go1.26-devel_9db7e30b

Output of go env in your module/workspace:

AR='ar'
CC='gcc'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='g++'
GCCGO='gccgo'
GO111MODULE=''
GOAMD64='v1'
GOARCH='amd64'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/home/jabaile/.cache/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/home/jabaile/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build553713773=/tmp/go-build -gno-record-gcc-switches'
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMOD='/home/jabaile/work/TypeScript-go/go.mod'
GOMODCACHE='/home/jabaile/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/jabaile/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/home/jabaile/sdk/gotip'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTELEMETRYDIR='/home/jabaile/.config/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/home/jabaile/sdk/gotip/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.26-devel_9db7e30b Thu Oct 9 09:13:29 2025 -0700'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

The typescript-go repo has implementations of ECMAScript number handling; we have to do terrible things in order to implement the spec for number conversions between float64/int32/uint32. After CL 691135, our tests fail for certain edge cases.

I know the CL was intended to line up AMD64 and ARM64, but our test passed under both previously, so something is weird here.

What did you see happen?

With https://github.com/microsoft/typescript-go, do go test ./internal/jsnum:

--- FAIL: TestBitwiseNOT (0.00s)
    --- FAIL: TestBitwiseNOT/-2147483649 (0.00s)
        jsnum_test.go:123: assertion failed: -1 (got jsnum.Number) != -2147483648 (want jsnum.Number)
--- FAIL: TestToInt32 (0.00s)
    --- FAIL: TestToInt32/MinInt32-1_(-2.147483649e+09) (0.00s)
        jsnum_test.go:89: assertion failed: 0 (int32) != 2147483647 (test.want int32)
    --- FAIL: TestToInt32/-math.Pi_(-3.141592653589793) (0.00s)
        jsnum_test.go:89: assertion failed: 0 (int32) != -3 (test.want int32)
    --- FAIL: TestToInt32/-math.E_(-2.718281828459045) (0.00s)
        jsnum_test.go:89: assertion failed: 0 (int32) != -2 (test.want int32)
    --- FAIL: TestToInt32/MIN_SAFE_INTEGER+1_(-9.00719925474099e+15) (0.00s)
        jsnum_test.go:89: assertion failed: 0 (int32) != 2 (test.want int32)
    --- FAIL: TestToInt32/-2^31_-_0.5_(-2.1474836485e+09) (0.00s)
        jsnum_test.go:89: assertion failed: 0 (int32) != -2147483648 (test.want int32)
    --- FAIL: TestToInt32/MIN_SAFE_INTEGER_(-9.007199254740991e+15) (0.00s)
        jsnum_test.go:89: assertion failed: 0 (int32) != 1 (test.want int32)
    --- FAIL: TestToInt32/-8589934590_(-8.58993459e+09) (0.00s)
        jsnum_test.go:89: assertion failed: 0 (int32) != 2 (test.want int32)
FAIL
FAIL    github.com/microsoft/typescript-go/internal/jsnum       0.167s
FAIL

What did you expect to see?

Passing tests.

cc @dr2chase

[jakebailey]

I also tried using the bisect tool to check this, per the CL description, but it didn't actually seem to work:

$ go run golang.org/x/tools/cmd/bisect@latest -compile=convert go test ./internal/jsnum      
bisect: checking target with all changes disabled
bisect: run: GOCOMPILEDEBUG=converthash=n go test ./internal/jsnum... FAIL (93 matches)
bisect: run: GOCOMPILEDEBUG=converthash=n go test ./internal/jsnum... FAIL (93 matches)
bisect: checking target with all changes enabled
bisect: run: GOCOMPILEDEBUG=converthash=y go test ./internal/jsnum... FAIL (93 matches)
bisect: run: GOCOMPILEDEBUG=converthash=y go test ./internal/jsnum... FAIL (93 matches)
bisect: fatal error: target fails with no changes and all changes
exit status 1

Forgive me for such a big repro (and probably, cursed code), I still need to narrow this down a bit.

[Jorropo]

@jakebailey the newly failing tests just fail under amd64 correct ?
They used to and continue to pass under arm64 ?

[jakebailey]

No, in fact, arm64 is also breaking on my ARM Mac, but passing in 1.25. I will bisect again to double check that it's the same commit there, though that doesn't make much sense...

[Jorropo]

Yeah it's tricky, for example see theses two tests:

func TestJorropo(t *testing.T) {
	assertEqualNumber(t, -2147483649, Number(2147483647).BitwiseNOT())
}

func TestBitwiseNOT(t *testing.T) {
	t.Parallel()

	tests := []struct {
		input, want Number
	}{
		{-2147483649, Number(2147483647).BitwiseNOT()},
		{-4294967296, Number(0).BitwiseNOT()},
		{2147483648, Number(-2147483648).BitwiseNOT()},
		{4294967296, Number(0).BitwiseNOT()},
	}

	for _, test := range tests {
		t.Run(test.input.String(), func(t *testing.T) {
			t.Parallel()
			assertEqualNumber(t, test.input.BitwiseNOT(), test.want)
		})
	}
}

The bottom one is what is in typescript-go the top one is a copy of the first test case manually inlined.
The bottom one passes with 0e466a8d1d89e15e953c7d35bcd9e02d3c89f62b~1 while neither passes with the top one.

Given inlining the first test case changed the behavior in 1.25 I think this is a bug in old versions of go.

This test asserts that -2147483649 == not(2147483647) but not(2147483647) is -2147483648 but but -2147483648 is a valid int32 and a valid float64.

It is truly maddening that someone could come up with a system where a number correctly representable in both number encodings somehow doesn't survive being casted 🙃.

[Jorropo]

@jakebailey also random question but is this test case even correct ?
If I try ~2147483647 in FF's js console I get -2147483648 not -2147483649, is ~2147483647 equivalent javascript to Number(2147483647).BitwiseNOT() ?

[jakebailey]

You're reading the test backwards sideways(?); the test is checking that Number(-2147483649).BitwiseNOT() == Number(2147483647).BitwiseNOT(), which it is:

It's roundabout absolutely, but comes from a test262 testcase.

[Jorropo]

Yeah I just figured out that 🤦.
I would advise hardcoding the RHS of the testcase table to have less variables but ¯`\_(ツ)_/¯

[jakebailey]

Yes, I agree, I am not proud of this specific test case. What I did is the worst combination, and I do not remember why!

[Jorropo]

Ok so for this one the exact problematic line of code is:

> github.com/microsoft/typescript-go/internal/jsnum.Number.toUint32() ./internal/jsnum/jsnum.go:62
    61:		// Convert to uint32, which will wrap negative numbers.
=>  62:		return uint32(x) // x = -2147483649 here

Minimized form:

var x float64 = -2147483649
func main() {
	fmt.Println(uint32(x)) // 1.25: 2147483647, tip: 0
}

[jakebailey]

The same failures happen on ARM64, bisecting to the same commit. But the failures are identical to AMD64.

This is very odd. I had thought the CL did not affect ARM64, but apparently it does.

[Jorropo]

@jakebailey see the change to src/cmd/compile/internal/ssagen/ssa.go file in 0e466a8, this change affect all architectures.

It remove support for float{32,64} → uint{32,64} conversion on all architectures and replace it with some « branchy code ».

[jakebailey]

Peeking at esbuild, they have written fairly similar code to me: https://github.com/evanw/esbuild/blob/8f506d5ca6882f2fa96a4a7233ab9784af0a5298/internal/js_ast/js_ast_helpers.go#L931

But, their code does not have the problem my code has. Perhaps this is all my fault for assuming the platforms did a specific kind of conversion.

[jakebailey]

It remove support for float{32,64} → uint{32,64} conversion on all architectures and replace it with some « branchy code ».

Spooky... This is sometimes hot code, especially for engines written in Go (like goja) so that is somewhat surprising to hear.

[thepudds]

If I try this change on linux/amd64, using 0e466a8 as starting point, it seems to get the typescript-go tests to pass again. (Some other partial reverts attempted did not get those tests to pass).

diff --git a/src/cmd/compile/internal/ssagen/ssa.go b/src/cmd/compile/internal/ssagen/ssa.go
index 2705195bd5..26a89d6b9c 100644
--- a/src/cmd/compile/internal/ssagen/ssa.go
+++ b/src/cmd/compile/internal/ssagen/ssa.go
@@ -2574,12 +2574,12 @@ var fpConvOpToSSA = map[twoTypes]twoOpsAndType{
 
  {types.TFLOAT64, types.TUINT8}: {ssa.OpCvt64Fto32, ssa.OpTrunc32to8, types.TINT32},[/+]
  {types.TFLOAT64, types.TUINT16}: {ssa.OpCvt64Fto32, ssa.OpTrunc32to16, types.TINT32},[/+]
- {types.TFLOAT64, types.TUINT32}: {ssa.OpInvalid, ssa.OpCopy, types.TINT64}, // Cvt64Fto32U, branchy code expansion instead[/+]
+ {types.TFLOAT64, types.TUINT32}: {ssa.OpCvt64Fto64, ssa.OpCopy, types.TINT64}, // Cvt64Fto32U, branchy code expansion instead[/+]
  {types.TFLOAT64, types.TUINT64}: {ssa.OpInvalid, ssa.OpCopy, types.TUINT64}, // Cvt64Fto64U, branchy code expansion instead

~/repos/typescript-go$ go test ./internal/jsnum
ok      github.com/microsoft/typescript-go/internal/jsnum       0.014s

edit: the first diff I posted had two lines changed, but only one line was required, so updated it here to just show the one line.