cmd/compile: crashes in slicing array converted from slice

[zigo101]

What version of Go are you using (go version)?

$ go version
go version go1.17beta1 linux/amd64

What did you do?

package main

func SumPointer(b []byte) []byte {
	return (*[32]byte)(b[:32])[:]
}

func main() {
}

What did you expect to see?

Compiles okay.

What did you see instead?

Compiler crashes.

# command-line-arguments
./main.go:4:28: internal compiler error: 'SumPointer': bad type in slice int


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

[ianlancetaylor]

CC @josharian @randall77 @mdempsky

[toothrot]

This looks like a serious issue. In 1.16, this would report: cannot convert b[:32] (type []byte) to type *[32]byte.

This also reproduces on tip.

[josharian]

I'm AFK for a while, but on my phone, looks like the type for the return value in ssagen/ssa.go:3177 is wrong. It is TINT, but should be n.Type(). Anyone else should feel free to send this as a CL, if this diagnosis seems right.

[gopherbot]

Change https://golang.org/cl/330672 mentions this issue: cmd/compile: fix wrong type in SSA generation for OSLICE2ARRPTR

[mdempsky]

Sorry for the assignment churn. I was trying to assign it to @cuonglm, because he jumped on it with CL 330672 (thanks @cuonglm!). But GitHub won't allow me to for some reason.

[cuonglm]

Sorry for the assignment churn. I was trying to assign it to @cuonglm, because he jumped on it with CL 330672 (thanks @cuonglm!). But GitHub won't allow me to for some reason.

Yay, I actually have the CL ready one hour ago, but still trying to figure it out why the wrong type is not problem in normal case. Also, sounds like we are not consistent in the type argument passing with OpSlicePtr. But I think n.Type() is best here.

[mdempsky]

still trying to figure it out why the wrong type is not problem in normal case.

Probably because SSA doesn't do any type checking to make sure types are consistent, and int and *[N]T are interchangeable in most cases.

Also, the feature is new, so we probably don't have any code to exercise that *[N]T is handled correctly by the garbage collector if it needs to get spilled out of the register set for some reason.