cmd/compile: internal compiler error: not lowered: v654, Int64Hi INT32 INT on 32bit GOARCHs

[ALTree]

$ gotip version
go version devel go1.21-942c1c1 Tue Jun 27 18:21:24 2023 +0000 linux/amd64

package p

func f(x int, b bool) int {

	switch x {
	case 0:
		return 0
	case 1:
		return 1
	case 2:
		return 2

	// ...
	// ~100 other cases
	// ...

	case 100:
		return 100
	case 101:
		return 101
	case 102:
		return 102
	}

	if b {
		var a struct{ f int64 }
		_ = max(0, a.f)
	}

	return min(0, len(append([]int{}, []int{}...)))
}

(full reproducer here: https://go.dev/play/p/_bv7gsRF91v?v=gotip)

$ GOARCH=386 gotip build main.go 

# command-line-arguments
./main.go:106:7: internal compiler error: 'f': not lowered: v654, Int64Hi INT32 INT

goroutine 9 [running]:
runtime/debug.Stack()
	./desktop/gotip/src/runtime/debug/stack.go:24 +0x5e
cmd/compile/internal/base.FatalfAt({0x6318d8?, 0xc0?}, {0xc0006318b0, 0x8}, {0xc0005c0fe0, 0x2, 0x2})
	./desktop/gotip/src/cmd/compile/internal/base/print.go:230 +0x1d7
cmd/compile/internal/base.Fatalf(...)
	./desktop/gotip/src/cmd/compile/internal/base/print.go:199
cmd/compile/internal/ssagen.(*ssafn).Fatalf(0x10?, {0xc352c108?, 0x7f45?}, {0xd650f5, 0x2}, {0xc0005f3db0, 0x1, 0xc00002e4e0?})
	./desktop/gotip/src/cmd/compile/internal/ssagen/ssa.go:7994 +0x16a
cmd/compile/internal/ssa.(*Func).Fatalf(0xc0003cf380, {0xd650f5, 0x2}, {0xc0005f3db0, 0x1, 0x1})
	./desktop/gotip/src/cmd/compile/internal/ssa/func.go:716 +0x279
cmd/compile/internal/ssa.checkLower(0xc0003cf380)
	./desktop/gotip/src/cmd/compile/internal/ssa/lower.go:49 +0x405
cmd/compile/internal/ssa.Compile(0xc0003cf380)
	./desktop/gotip/src/cmd/compile/internal/ssa/compile.go:97 +0x9ab
cmd/compile/internal/ssagen.buildssa(0xc0003ffe40, 0x3)
	./desktop/gotip/src/cmd/compile/internal/ssagen/ssa.go:568 +0x2b09
cmd/compile/internal/ssagen.Compile(0xc0003ffe40, 0x0?)
	./desktop/gotip/src/cmd/compile/internal/ssagen/pgen.go:187 +0x45
cmd/compile/internal/gc.compileFunctions.func5.1(0xc0003f3900?)
	./desktop/gotip/src/cmd/compile/internal/gc/compile.go:184 +0x34
cmd/compile/internal/gc.compileFunctions.func3.1()
	./desktop/gotip/src/cmd/compile/internal/gc/compile.go:166 +0x30
created by cmd/compile/internal/gc.compileFunctions.func3 in goroutine 8
	./desktop/gotip/src/cmd/compile/internal/gc/compile.go:165 +0x23a

fails on GOARCH=arm too.

cc @randall77 @cherrymui

[ianlancetaylor]

Marking as a release-blocker for now.

CC @mdempsky @cuonglm

[mdempsky]

Seems to compile successfully at tip: https://go.dev/play/p/Kn0eExXNMsW?v=gotip

I think this was fixed by https://go-review.googlesource.com/c/go/+/506115 or https://go-review.googlesource.com/c/go/+/506055.

Edit: Or https://go-review.googlesource.com/c/go/+/505756.

[mdempsky]

I just noticed this was reported as failing on 386 and arm, not amd64 like the Go playground.

But even checking out 1.21rc2, running make.bash, and using GOARCH=386 go build /tmp/x.go, it seems to build fine for me.

I tried the go1.21rc2 linux release binary too, and can't reproduce either.

Can anyone else reproduce this failure?

[ianlancetaylor]

I was able to reproduce it. Make sure to pull the test case from the Go playground, not from the abbreviated test case in the initial post.

[mdempsky]

Make sure to pull the test case from the Go playground, not from the abbreviated test case in the initial post.

I did:

mdempsky@genji:/tmp/q$ curl -Lo main.go https://go.dev/play/p/_bv7gsRF91v.go
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  2415  100  2415    0     0  16067      0 --:--:-- --:--:-- --:--:-- 16100
mdempsky@genji:/tmp/q$ sha256sum main.go
b7c256b668948283194cbff14bc2b98392110d10fa98b08358fc33383f885079  main.go
mdempsky@genji:/tmp/q$ ./go/bin/go version
go version go1.21rc2 linux/amd64
mdempsky@genji:/tmp/q$ GOARCH=386 ./go/bin/go build main.go
mdempsky@genji:/tmp/q$ echo $?
0
mdempsky@genji:/tmp/q$ GOARCH=arm ./go/bin/go build main.go
mdempsky@genji:/tmp/q$ echo $?
0

[ianlancetaylor]

Hmmm.

> sha256sum ~/foo2.go
b7c256b668948283194cbff14bc2b98392110d10fa98b08358fc33383f885079  /home/iant/foo2.go
> GOARCH=386 go build ~/foo2.go
# command-line-arguments
../../foo2.go:106:7: internal compiler error: 'f': not lowered: v654, Int64Hi INT32 INT

goroutine 21 [running]:
runtime/debug.Stack()
	../../go/src/runtime/debug/stack.go:24 +0x5e
cmd/compile/internal/base.FatalfAt({0x6f38d8?, 0xc0?}, {0xc0006f38b0, 0x8}, {0xc00053af80, 0x2, 0x2})
	../../go/src/cmd/compile/internal/base/print.go:230 +0x1d7
cmd/compile/internal/base.Fatalf(...)
	../../go/src/cmd/compile/internal/base/print.go:199
cmd/compile/internal/ssagen.(*ssafn).Fatalf(0x10?, {0x61e3aa68?, 0x7fb8?}, {0xd650f5, 0x2}, {0xc00057bd80, 0x1, 0xc0001ce4a0?})
	../../go/src/cmd/compile/internal/ssagen/ssa.go:7994 +0x16a
cmd/compile/internal/ssa.(*Func).Fatalf(0xc000275860, {0xd650f5, 0x2}, {0xc00057bd80, 0x1, 0x1})
	../../go/src/cmd/compile/internal/ssa/func.go:716 +0x279
cmd/compile/internal/ssa.checkLower(0xc000275860)
	../../go/src/cmd/compile/internal/ssa/lower.go:49 +0x405
cmd/compile/internal/ssa.Compile(0xc000275860)
	../../go/src/cmd/compile/internal/ssa/compile.go:97 +0x9ab
cmd/compile/internal/ssagen.buildssa(0xc0004b1ce0, 0x3)
	../../go/src/cmd/compile/internal/ssagen/ssa.go:568 +0x2b09
cmd/compile/internal/ssagen.Compile(0xc0004b1ce0, 0x0?)
	../../go/src/cmd/compile/internal/ssagen/pgen.go:187 +0x45
cmd/compile/internal/gc.compileFunctions.func5.1(0xc0004a5900?)
	../../go/src/cmd/compile/internal/gc/compile.go:184 +0x34
cmd/compile/internal/gc.compileFunctions.func3.1()
	../../go/src/cmd/compile/internal/gc/compile.go:166 +0x30
created by cmd/compile/internal/gc.compileFunctions.func3 in goroutine 20
	../../go/src/cmd/compile/internal/gc/compile.go:165 +0x23a

> go version
go version devel go1.21-6691f438c3 Tue Jun 27 21:15:37 2023 +0000 linux/amd64

[ianlancetaylor]

But I can't reproduce it with 1.21rc2, only with HEAD.

[mdempsky]

I ran go clean and go clean -cache and re-ran make.bash at tip a bunch of times in random order, and now I can reproduce it.

[ianlancetaylor]

I suspect it was introduced by https://go.dev/cl/505756 by @randall77 .

[mdempsky]

I suspect it was introduced by https://go.dev/cl/505756 by @randall77 .

git bisect agrees with that.

[mdempsky]

I compared the GOSSAFUNC=f output for the function, with and without the extra switch statement. I noticed this discrepancy:

When the switch statement is absent, the final return block is constructed as:

b16: ← b14 b15
v84 (10) = FwdRef <int> {{[] ternary}}
v86 (10) = FwdRef <mem> {{[] mem}}
v85 (10) = MakeResult <int,mem> v84 v86
Ret v85 (+10)

and then after phi-insertion becomes:

b16: ← b14 b15
v84 (10) = Phi <int> v82 v9
v86 (10) = Copy <mem> v81
v85 (10) = MakeResult <int,mem> v84 v86
Ret v85 (+10)

However, when the switch statement is present, then before phi-insertion we have:

b504: ← b502 b503
v674 (219) = FwdRef <int> {{[] ternary}}
v676 (219) = FwdRef <mem> {{[] mem}}
v675 (219) = MakeResult <int,mem> v674 v676
Ret v675 (+219)

and after phi-insertion:

b504: ← b502 b503
v679 (219) = Phi <int64> v672 v9
v674 (219) = Copy <int> v679
v676 (219) = Copy <mem> v671
v675 (219) = MakeResult <int,mem> v674 v676
Ret v675 (+219)

Note that v679 was inserted as a Phi of type int64, whereas v672 and v9 are both int-typed.

I'm guessing this is somehow related to the fact that the "ternaryVar" pseudo-variable is being used in two min/max expressions within the same function, but with different types.