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.

Sign up for GitHub

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: possible liveness bug #16026

Closed
randall77 opened this issue Jun 9, 2016 · 6 comments
Closed

cmd/compile: possible liveness bug #16026

randall77 opened this issue Jun 9, 2016 · 6 comments
Labels
FrozenDueToAge
Milestone
Go1.7

Comments

@randall77
Copy link
Contributor 

type T [10]*int
func f(t T) {
    g = t
}
var g T

compiles to roughly:

autotmp_0 = t (using duffcopy)
if writebarriers_enabled {
    typedmemmove(&g, &autotmp_0)
} else {
    g = autotmp_0 (using duffcopy)
}

Problem: autotmp_0 is not considered live at typedmemmove. The fact that typedmemmove (and callees) are marked as nosplit saves us, but I can't yet convince myself that there won't be other cases like this but without nosplit saving us.

$ go tool compile -live ~/go/tmp4.go
/usr/local/google/home/khr/go/tmp4.go:8: live at entry to f: t
/usr/local/google/home/khr/go/tmp4.go:9: live at call to typedmemmove: t   <- missing autotmp_0

(Another less serious issue is that autotmp_0 is unnecessary in this example, but compilers; go figure.)

Found using CL https://go-review.googlesource.com/23924

@aclements
@randall77 randall77 added this to the Go1.7 milestone Jun 9, 2016
@randall77 randall77 self-assigned this Jun 9, 2016
@adg
Copy link
Contributor

adg commented Jun 15, 2016

@randall77 any movement here?

@randall77
Copy link
Contributor Author

No, I have been unable to write a test that actually demonstrates a real bug. I'm still working on it.

@adg
Copy link
Contributor

adg commented Jun 15, 2016

@randall77 should this block go1.7beta2?

@randall77
Copy link
Contributor Author

No.

@randall77
Copy link
Contributor Author

I've determined that typedmemmove is the only call for which this happens. All other calls are ok. So I'm marking this closed, I'll get my clobber code in (deactivated by default) for 1.8.

@randall77 randall77 mentioned this issue Jun 17, 2016
Closed
@gopherbot
Copy link
Contributor

CL https://golang.org/cl/23924 mentions this issue.

gopherbot pushed a commit that referenced this issue Apr 21, 2017
@randall77
cmd/compile: experiment which clobbers all dead pointer fields
1e72bf6 
The experiment "clobberdead" clobbers all pointer fields that the
compiler thinks are dead, just before and after every safepoint.
Useful for debugging the generation of live pointer bitmaps.

Helped find the following issues:
Update #15936
Update #16026
Update #16095
Update #18860

Change-Id: Id1d12f86845e3d93bae903d968b1eac61fc461f9
Reviewed-on: https://go-review.googlesource.com/23924
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
@golang golang locked and limited conversation to collaborators Feb 3, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Go1.7
Development

No branches or pull requests
3 participants
@randall77 @adg @gopherbot