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/internal/obj: add new As type for Prog's As field #14692
Labels
Comments
CL https://golang.org/cl/20341 mentions this issue. |
gopherbot
pushed a commit
that referenced
this issue
Mar 7, 2016
Instead of abusing ALAST. Passes GOARCH=mips64 toolstash -cmp. Updates #14692. Change-Id: Ie85e99cf76508c1d0f5847a4157056b614fd5cc6 Reviewed-on: https://go-review.googlesource.com/20341 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
CL https://golang.org/cl/20345 mentions this issue. |
gopherbot
pushed a commit
that referenced
this issue
Mar 8, 2016
Currently, package obj reserves a range of 1<<12 opcodes for each target architecture. E.g., mips64 has [6<<12, 7<<12). However, because mips.ABEQ and mips.ALAST are both within that range, the expression mips.ABEQ+mips.ALAST in turn falls (far) outside that range around 12<<12, meaning it could theoretically collide with another arch's opcodes. More practically, it's a problem because 12<<12 overflows an int16, which hampers fixing #14692. (We could also just switch to uint16 to avoid the overflow, but that still leaves the first problem.) As a workaround, use Michael Hudson-Doyle's solution from https://golang.org/cl/20182 and use negative values for these variant instructions. Passes toolstash -cmp for GOARCH=arm and GOARCH=mips64. Updates #14692. Change-Id: Iad797d10652360109fa4db19d4d1edb6529fc2c0 Reviewed-on: https://go-review.googlesource.com/20345 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
CL https://golang.org/cl/20350 mentions this issue. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Along the lines of other similar type-safe toolchain refactorings, we should add a new
type to cmd/internal/obj, change the existing
AFOO
consts andProg
'sAs
field to be typed asAs
, and cleanup any unnecessary conversions ofAs
values./cc @davecheney
The text was updated successfully, but these errors were encountered: