cmd/compile: internal compiler error: unhandled expr INDEXMAP

[jake-ciolek]

Go version

go 1.26.1 darwin/arm64

Output of go env in your module/workspace:

GOARCH=arm64

What did you do?

package main

var z = map[int]int{0: 1}

func main() {
	_ = make([]byte, z[0], 1)
}

What did you see happen?

go run .                                                                                                                                                                                
# report
./main.go:6:20: internal compiler error: 'main': unhandled expr INDEXMAP

Please file a bug report including a short program that triggers the error.
https://go.dev/issue/new

What did you expect to see?

It shouldn't have erred.

[gabyhelp]

Related Issues

• cmd/compile: internal compiler error: unhandled addr INDEXMAP #14678 (closed)
• cmd/compile: ICE: panic: interface conversion: ir.Node is *ir.ConvExpr, not *ir.IndexExpr #66096 (closed)
• cmd/gc: internal compiler error: cgen INDEXMAP #8094 (closed)
• internal compiler error: gen_as_init couldn't make data statement #16306 (closed)
• gccgo: internal compiler error caused by map[int]int{}[0]++ #9475 (closed)
• cmd/compile: internal compiler error "not lowered: ArrayMake0" for pointer-shaped struct with zero-sized array field #77936 (closed)
• cmd/compile: internal compiler error: panic: interface conversion: ir.Node is *ir.IndexExpr, not *ir.StarExpr #77832 (closed)
• internal compiler error #46153 (closed)
• cmd/compile: tricky map key causes internal compiler error #14988 (closed)
• cmd/compile: internal compiler error: found illegal assignment .shape.*uint8_1 -> PTR-*string; #48453 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[gopherbot]

Change https://go.dev/cl/753100 mentions this issue: cmd/compile: fix ICE when checking slice cap

[cuonglm]

@randall77 Not sure if this issue is qualified for backporting. It has been existed since go1.15, and there could be a workaround for buggy code.

[randall77]

That CL (226737) might have been a while ago, but the failure is new in 1.26. At least for this reproducer. Not sure what caused it to surface, probably a bisect would find the CL.

I agree that there's a pretty easy workaround (assign the length to a temporary and use that in the make call). And the failure isn't silent corruption, but an obvious ICE.

So I would lean toward not backporting.

[cuonglm]

That CL (226737) might have been a while ago, but the failure is new in 1.26. At least for this reproducer. Not sure what caused it to surface, probably a bisect would find the CL.

I believe https://go-review.googlesource.com/c/go/+/226737 is the culprit, the reproducer started failing since go1.15 up-to-now.