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

Jump to bottom

cmd/compile: crashes in slicing array converted from slice #46907

Closed
go101 opened this issue Jun 24, 2021 · 11 comments
Closed

cmd/compile: crashes in slicing array converted from slice #46907

go101 opened this issue Jun 24, 2021 · 11 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. release-blocker
Milestone
Go1.17

Comments

@go101
Copy link

go101 commented Jun 24, 2021

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 ianlancetaylor added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. release-blocker labels Jun 24, 2021
@ianlancetaylor ianlancetaylor added this to the Go1.17 milestone Jun 24, 2021
@ianlancetaylor
Copy link
Contributor

CC @josharian @randall77 @mdempsky

@toothrot
Copy link
Contributor

toothrot commented Jun 24, 2021 •
edited

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

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.

@mdempsky mdempsky self-assigned this Jun 24, 2021
@gopherbot
Copy link

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

@mdempsky mdempsky assigned mdempsky and unassigned mdempsky Jun 24, 2021
@mdempsky
Copy link
Member

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

cuonglm commented Jun 24, 2021

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

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.

@ALTree
Copy link
Member

ALTree commented Jun 25, 2021

@mdempsky Only people in the go-assignees group can be assigned issues: https://github.com/orgs/golang/teams, but Cuong is not part of that group.

@mdempsky
Copy link
Member

@ALTree Thanks. Do you know how we fix that? I clicked around briefly, and either I couldn't figure out how to add members or I don't have authority to.

Cuong has been a Gerrit approver for a while now.

@ALTree
Copy link
Member

ALTree commented Jun 25, 2021 •
edited

He's a gerrit approver but Github Access and Gerrit Access are two separated things.

He needs to be part of the Golang Github organization first, he's currently not (he's not in https://github.com/orgs/golang/people and his github label says "contributor", not "member").

He should open an issue as described here: https://github.com/golang/go/wiki/GithubAccess asking for Assignees and Editors roles (if he wishes to).

@cuonglm cuonglm mentioned this issue Jun 25, 2021
Closed
@cuonglm
Copy link
Member

cuonglm commented Jun 25, 2021

@ALTree Thanks, I filed #46920

@golang golang locked and limited conversation to collaborators Jun 25, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. release-blocker
Projects
None yet
Milestone
Go1.17
Development

No branches or pull requests
8 participants
@toothrot @mdempsky @josharian @ianlancetaylor @ALTree @cuonglm @gopherbot @go101