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.

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: 64 bits shifts on arm get wrong results [1.16 backport] #48478

Closed
gopherbot opened this issue Sep 20, 2021 · 3 comments
Closed

cmd/compile: 64 bits shifts on arm get wrong results [1.16 backport] #48478

gopherbot opened this issue Sep 20, 2021 · 3 comments
Labels
CherryPickApproved
Milestone

Comments

@gopherbot
Copy link

@gopherbot gopherbot commented Sep 20, 2021

@randall77 requested issue #48476 to be considered for backport to the next 1.16 minor release.

@gopherbot please open backport issues

@gopherbot gopherbot added the CherryPickCandidate label Sep 20, 2021
@gopherbot gopherbot added this to the Go1.16.9 milestone Sep 20, 2021
@gopherbot
Copy link
Author

@gopherbot gopherbot commented Sep 20, 2021

Change https://golang.org/cl/351070 mentions this issue: cmd/compile: ensure constant shift amounts are in range for arm

@randall77
Copy link
Contributor

@randall77 randall77 commented Sep 20, 2021

This issue causes miscompilation. It's hard to trigger, but causes the compiler to generate wrong code if it does.

@heschi heschi added CherryPickApproved and removed CherryPickCandidate labels Oct 6, 2021
@mknyszek mknyszek removed this from the Go1.16.9 milestone Oct 7, 2021
@mknyszek mknyszek added this to the Go1.16.10 milestone Oct 7, 2021
@dmitshur
Copy link
Contributor

@dmitshur dmitshur commented Oct 27, 2021

Closed by merging 1a6281d to release-branch.go1.16.

gopherbot pushed a commit that referenced this issue Oct 27, 2021
…e in range for arm

Ensure constant shift amounts are in the range [0-31]. When shift amounts
are out of range, bad things happen. Shift amounts out of range occur
when lowering 64-bit shifts (we take an in-range shift s in [0-63] and
calculate s-32 and 32-s, both of which might be out of [0-31]).

The constant shift operations themselves still work, but their shift
amounts get copied unmolested to operations like ORshiftLL which use only
the low 5 bits. That changes an operation like <<100 which unconditionally
produces 0, to <<4, which doesn't.

Fixes #48478

Change-Id: I87363ef2b4ceaf3b2e316426064626efdfbb8ee3
Reviewed-on: https://go-review.googlesource.com/c/go/+/350969
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
(cherry picked from commit eff27e8)
Reviewed-on: https://go-review.googlesource.com/c/go/+/351070
Reviewed-by: Austin Clements <austin@google.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CherryPickApproved
Projects
None yet
Development

No branches or pull requests

5 participants