-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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: incorrect liveness information #19078
Comments
@rsc, cool. Glad that this helps! In summary:
|
@rsc, fwiw, also not reproducible on Go 1.8.rc3 for us. So again, this is only reproducible on current Go master (2017-02-14). |
This keeps popping up on the issue tracker under various guises. I think it'd be good to prioritize it. |
I'm working on it now. The fix is pretty easy. The test is hard. |
@randall77 What's your planned fix? Only add Addrtaken PPARAMOUT variables to livedefer? |
My planned fix is to zero results earlier. Currently we walk down the results list once, issuing zeroings and move-to-heaps as we go. I'm changing it to walk down the list twice, all the zeroings first and then all the move-to-heaps after that. |
I thought for a while about a more complicated fix, which was to be more precise about when result slots were live. We'd need to mark every instruction that could panic so we could mark all the result slots as live at each of those points. It is a more precise fix but it is also more complicated and fragile. |
CL https://golang.org/cl/38133 mentions this issue. |
This bug is not present in release-branch.go1.8 nor earlier versions of Go. It is the root cause for some failures reported on #19029 (but not the ones using Go 1.7.5).
Here's a source file:
The liveness debugging output begins:
Note that in bb 0~r1 has magically become live between the start of the function and the call to newobject. That's wrong. It is not initialized until bb 3.
My guess is this was introduced by Keith's change to the handling of results in liveness bitmaps, but that's just a guess.
Again, not present in Go 1.8rc3, nor in Go 1.7.5. Those correctly delay ~r1 being live until after it is initialized.
/cc @mdempsky @randall77
The text was updated successfully, but these errors were encountered: