-
Notifications
You must be signed in to change notification settings - Fork 17.5k
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: dev.typeparams commit 0a0e3a3 broke dev.boringcrypto; fixed again at a72a499 #47227
Comments
I haven't looked deeper, but here's a simple reproducer:
Just checkout commit 0a0e3a3 on dev.typeparams. |
Change https://golang.org/cl/334882 mentions this issue: |
Change https://golang.org/cl/334883 mentions this issue: |
@mdempsky @cherrymui So the problem is not related to 0a0e3a3 and a72a499. This failed to compile even with current dev.typeparams tip:
The problem is that ssagen/ssa.go:state.call does't handle direct function value, so it use the wrong ABI to set the offset, which causes offset changed. |
CL 330330 moved logic for wrapping go/defer from order to esacpe analysis. It introduced a bug involves go/defer statement with ABI0 functions. Consider this following code: package p //go:cgo_unsafe_args func g(*int) (r1 struct{}) { return } func f() { defer g(new(int)) } g is a cgo-like generated function with ABI0. While compiling g, we set the offset per ABI0. The function f is rewritten into: func f() { _0, _1 := g, new(int) defer func() { _0(_1) }() } The temporary _0 hold function value with the same type as g, but with class PAUTO. Thus ssagen/ssa.go:state.call cannot handle it and use ABIDefault to set the offset, causes the offset of r1 changed CL 330332 intended to optimize code generated for wrapping function, by rewriting the wrapper function into: func f() { _0 := new(int) defer func() { g(_0) }() } So it fixed the bug unintentionally. This CL add regression test for this bug, and also add a comment to explain while not wrapping declared function is important. Updates #47227 Change-Id: I75c83d1d9cc7fd4699e6b218a295d0c0a10ef471 Reviewed-on: https://go-review.googlesource.com/c/go/+/334882 Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Change https://golang.org/cl/336629 mentions this issue: |
Change https://golang.org/cl/336610 mentions this issue: |
We now understand the root cause of #47227, it will be fixed in #47317. Change-Id: Ifcd44f887a0bd3195818df33e409bd3e818e0b27 Reviewed-on: https://go-review.googlesource.com/c/go/+/336610 Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Go Bot <gobot@golang.org>
Merging 0a0e3a3 into dev.boringcrypto causes make.bash to fail due to:
This build failure was fixed a few commits later at a72a499.
That later commit was just an optimization, so it shouldn't be essential to correctly handling compiling this code. It would be good to get a minimal, standalone reproducer for what failed and add it as a compiler regress test.
To reproduce the issue:
git merge 0a0e3a3
./make.bash
in src./cc @cherrymui @cuonglm
The text was updated successfully, but these errors were encountered: