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: compiler regression due to deferred call to variadic unsafe-uintptr function #41460

Closed
mdempsky opened this issue Sep 17, 2020 · 3 comments
Assignees
Milestone

Comments

@mdempsky
Copy link
Member

@mdempsky mdempsky commented Sep 17, 2020

This used to compile (albeit with possible memory corruption), but now fails to compile with cannot use a0 (type []uintptr) as type uintptr in argument to f:

package p

import "unsafe"

//go:noinline
//go:uintptrescapes
func f(...uintptr) {}

func g(p unsafe.Pointer) {
	defer f(uintptr(p))
}

Probably due to CL 253457.

I think there are two issues here:

  1. In wrapCall, we need to set the newly created call as a ...-style call if the original one was. (The above code was already rewritten to defer f([]uintptr{uintptr(p)}...) earlier in the compiler.)
  2. wrapCall also needs to look for uintptr(p) conversions within the final []uintptr{...}... argument.

/cc @cuonglm @ianlancetaylor

@mdempsky mdempsky added this to the Go1.16 milestone Sep 17, 2020
@mdempsky mdempsky self-assigned this Sep 17, 2020
@cuonglm
Copy link
Member

@cuonglm cuonglm commented Sep 17, 2020

The first issue is quite easy to fix, the second is tricky. Seems we have to convert from slice of uintptr to slice of unsafe.Pointer?

Loading

@gopherbot
Copy link

@gopherbot gopherbot commented Sep 18, 2020

Change https://golang.org/cl/255877 mentions this issue: cmd/compile: more comprehensive tests for #24991

Loading

gopherbot pushed a commit that referenced this issue Sep 18, 2020
The revised test now checks that unsafe-uintptr correctly works for
variadic uintptr parameters too, and the CL corrects the code so this
code compiles again.

The pointers are still not kept alive properly. That will be fixed by
a followup CL. But this CL at least allows programs not affected by
that to build again.

Updates #24991.
Updates #41460.

Change-Id: If4c39167b6055e602213fb7522c4f527c43ebda9
Reviewed-on: https://go-review.googlesource.com/c/go/+/255877
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
@gopherbot
Copy link

@gopherbot gopherbot commented Oct 17, 2020

Change https://golang.org/cl/263297 mentions this issue: cmd/compile: fix defer/go calls to variadic unsafe-uintptr functions

Loading

@gopherbot gopherbot closed this in 76a615b Oct 17, 2020
@golang golang locked and limited conversation to collaborators Oct 17, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants