Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
ALTree opened this issue Jun 27, 2023 · 12 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsFix The path to resolution is known, but the work has not been done. release-blocker
Milestone

Comments

@ALTree
Copy link
Member

ALTree commented Jun 27, 2023

$ 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

@ALTree ALTree added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jun 27, 2023
@ALTree ALTree added this to the Go1.21 milestone Jun 27, 2023
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jun 27, 2023
@ianlancetaylor
Copy link
Contributor

Marking as a release-blocker for now.

CC @mdempsky @cuonglm

@mdempsky
Copy link
Member

mdempsky commented Jun 27, 2023

@mdempsky
Copy link
Member

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
Copy link
Contributor

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
Copy link
Member

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
Copy link
Contributor

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
Copy link
Contributor

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

@mdempsky
Copy link
Member

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
Copy link
Contributor

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

@mdempsky
Copy link
Member

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

git bisect agrees with that.

@mdempsky
Copy link
Member

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.

@gopherbot
Copy link

Change https://go.dev/cl/506679 mentions this issue: cmd/compile/internal/ssagen: fix min/max codegen, again

@dmitshur dmitshur added NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Jun 28, 2023
bradfitz pushed a commit to tailscale/go that referenced this issue Jul 15, 2023
The large-function phi placement algorithm evidently doesn't like the
same pseudo-variable being used to represent expressions of varying
types.

Instead, use the same tactic as used for "valVar" (ssa.go:6585--6587),
which is to just generate a fresh marker node each time.

Maybe we could just use the OMIN/OMAX nodes themselves as the key
(like we do for OANDAND/OOROR), but that just seems needlessly risky
for negligible memory savings. Using fresh marker values each time
seems obviously safe by comparison.

Fixes golang#61041.

Change-Id: Ie2600c9c37b599c2e26ae01f5f8a433025d7fd08
Reviewed-on: https://go-review.googlesource.com/c/go/+/506679
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsFix The path to resolution is known, but the work has not been done. release-blocker
Projects
None yet
Development

No branches or pull requests

5 participants