go: cmd/compile: internal compiler error: 'F': func F, startMem[b1] has different values
$ go version
go version go1.21.0 linux/amd64
$ gotip version
go version devel go1.22-ac64a362 Sat Aug 12 03:56:58 2023 +0000 linux/amd64
package p
type S1 struct {
a, b, c []int
i int
}
type S2 struct {
a, b []int
m map[int]int
}
func F(i int, f func(S1, S2, int) int) int {
return f(
S1{},
S2{m: map[int]int{}},
1<<i)
}
$ gotip build crash.go
# command-line-arguments
./crash.go:17:3: internal compiler error: 'F': func F, startMem[b1] has different values, old v1, new v29
goroutine 9 [running]:
runtime/debug.Stack()
./desktop/gotip/src/runtime/debug/stack.go:24 +0x5e
cmd/compile/internal/base.FatalfAt({0x41f678?, 0xc0?}, {0xc00002bf00, 0x40}, {0xc00040ee60, 0x5, 0x5})
./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?, {0x589a2108?, 0x7eff?}, {0xd978d9, 0x3a}, {0xc000405c00, 0x4, 0x0?})
./desktop/gotip/src/cmd/compile/internal/ssagen/ssa.go:8017 +0x16a
cmd/compile/internal/ssa.(*Func).Fatalf(0xc00037ba00, {0xd978d9, 0x3a}, {0xc000405c00, 0x4, 0x4})
./desktop/gotip/src/cmd/compile/internal/ssa/func.go:716 +0x279
cmd/compile/internal/ssa.memState(0xc00037ba00, {0xc000022800, 0x4, 0x0?}, {0xc000022b00, 0x4, 0x0?})
./desktop/gotip/src/cmd/compile/internal/ssa/tighten.go:240 +0x62a
cmd/compile/internal/ssa.tighten(0xc00037ba00)
./desktop/gotip/src/cmd/compile/internal/ssa/tighten.go:30 +0x228
....
Doesn’t crash on go1.20.7
About this issue
- Original URL
- State: closed
- Created a year ago
- Comments: 26 (21 by maintainers)
Commits related to this issue
- temporary fix for v1.21: https://github.com/golang/go/issues/61992 — committed to tuneinsight/lattigo by Pro7ech 10 months ago
- [release-branch.go1.21] cmd/compile: in expandCalls, move all arg marshalling into call block For aggregate-typed arguments passed to a call, expandCalls decomposed them into parts in the same block ... — committed to golang/go by dr2chase a year ago
- [release-branch.go1.20] cmd/compile: in expandCalls, move all arg marshalling into call block For aggregate-typed arguments passed to a call, expandCalls decomposed them into parts in the same block ... — committed to golang/go by dr2chase a year ago
- reverted temporary fix for v1.21: https://github.com/golang/go/issues/61992 — committed to tuneinsight/lattigo by Pro7ech 10 months ago
I’ve been poking at the old code, and it is horrible, and the expand calls cleanup cherry-picks cleanly onto 1.21. I’m about to test it but given when I wrote the cleanup, it is not a surprise if it works.
This looks like a bug in expand calls. It is confused about which memory to use and gets the memory chain in a bad state. The CL mentioned just notices that bug.
I think we need to backport to both 1.21 and 1.20, see my comment above.
@Nasfame It is a good question whether we need a backport to 1.20. It is not needed for this issue, but we probably want to fix the store chain even if there’s no subsequent pass that notices. Because maybe there is a pass that notices, silently generating incorrect code. I could be convinced otherwise if there was an argument that the broken memory chain can’t cause an issue. But without such an argument I’m sufficiently nervous about it to warrant a backport.
Change https://go.dev/cl/519276 mentions this issue:
cmd/compile: in expandCalls, move all arg marshalling into call block
That’s good for tip, but what can we reasonably backport to 1.21? Maybe just dropping that check is reasonable, as this “bug” has been around for a while. (Just on the 1.21 branch.)