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: recent regression in ppc64x builders: internal compiler error: pointer in non-pointer register g #25504
Comments
It is. @dr2chase has been digging into the cause of this, which is quite peculiar. For some reason we're spilling the g register to the stack and then reloading it back into the g register, which is completely ridiculous and quite possible unsafe (e.g., if there's a setg between the spill and the reload, this would clobber it's effect). I might temporarily ignore the g register in liveness analysis, just to get the build green again. /cc @khr |
Change https://golang.org/cl/114081 mentions this issue: |
In rare circumstances that we don't yet fully understand, the g register can be spilled to the stack and then reloaded. If this happens, liveness analysis sees a pointer load into a non-general-purpose register and panics. We should fix the root cause of this, but fix the build for now by ignoring pointer loads into the g register. For #25504. Change-Id: I0dfee1af9750c8e9157c7637280cdf07118ef2ca Reviewed-on: https://go-review.googlesource.com/114081 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
Change https://golang.org/cl/114087 mentions this issue: |
I think I understand what's going on, though not completely.
I.e.,
which clobbers all the registers, including the one with The SSA dump after trim:
|
Change https://golang.org/cl/114695 mentions this issue: |
This reverts commit ea200340702cf3ccfac7c5db1f11bb65c80971c7 now that CL 114695 fixed the root cause of #25504. Change-Id: If437fc832983bd8793bde28ce0e2e64436a0596c Reviewed-on: https://go-review.googlesource.com/114087 Reviewed-by: David Chase <drchase@google.com>
What version of Go are you using (
go version
)?tip
Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (
go env
)?ppc64 & ppc64le
A regression was introduced earlier today which then hid 2 more regressions introduced after which affect the ppc64 & ppc64le builders. The first two were fixed, now seeing this:
--- FAIL: TestCoverpkgAllRuntime (7.07s)
go_test.go:6004: running testgo [test -coverpkg=all x]
go_test.go:6004: standard output:
go_test.go:6004: FAIL x [build failed]
FAIL
FAIL cmd/go 139.178s
Assuming this is related to the reg changes that have been just added? @aclements
The text was updated successfully, but these errors were encountered: