-
Notifications
You must be signed in to change notification settings - Fork 18k
cmd/compile: internal compiler error: bad live variable at entry #55254
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
Comments
This happens on ppc64le. |
Are you sure 00bee6d is the first bad commit? |
Last known successful was with 7db923f |
The same build failure in k8s: https://prow.k8s.io/view/gs/kubernetes-jenkins/logs/ci-build-and-push-k8s-at-golang-tip/1572196947165450240 |
#55269 (comment) mentions commit cf53990 or 4c414c7 . It is unlikely the former, but the latter is possible, which changes scheduling. Is there a way we can do the build ourselves? Preferably in a cross-compile environment without running the make file. Thanks. |
I can reproduce on linux-amd64 as well:
|
Revert 4c414c7 makes the build success. |
Created revert, CL 432196 |
Sorry for introducing this issue, and thanks @randall77 for reverting 4c414c7673. I will find out the cause of this issue and resubmit. |
Change https://go.dev/cl/432275 mentions this issue: |
The problem here is that CL 424907 schedules the address fetching operation (MOVDaddr) of a local variable before the variable definition operation (VarDef). Please see v127 and v124 in the image below. But in fact the scheduling logic is correct or expected. A simpler fix is to adjust the priority of ScoreCarryChainTail. But I think it might be a better fix if the address fetching operation depends on the variable's definition operation, like op LocalAddr . |
The culprit CL has been reverted. I think we can close this. |
We thought about this before. But the problem is that introducing memory ordering for MOVDaddr may make it not able to be CSE'd or rematerialized. We didn't choose that path. I think it may be possible to make the schedule more careful about this, maybe schedule VarDef early (it doesn't generate code). |
Yeah, CL 432275 does just that. It's just that this looks a little fragile. |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
yes, master branch
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
What did you expect to see?
Tests should be successful
What did you see instead?
The text was updated successfully, but these errors were encountered: