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

Jump to bottom

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 Used during the release process for point releases FrozenDueToAge
Milestone
Go1.16.10

Comments

@gopherbot
Copy link

@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 Used during the release process for point releases label Sep 20, 2021
@gopherbot gopherbot mentioned this issue Sep 20, 2021
Closed
@gopherbot gopherbot added this to the Go1.16.9 milestone Sep 20, 2021
@gopherbot
Copy link
Author

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

@randall77
Copy link
Contributor

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

@heschi heschi added CherryPickApproved Used during the release process for point releases and removed CherryPickCandidate Used during the release process for point releases labels Oct 6, 2021
@mknyszek mknyszek modified the milestones: Go1.16.9, Go1.16.10 Oct 7, 2021
@dmitshur
Copy link
Contributor

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

gopherbot pushed a commit that referenced this issue Oct 27, 2021
@randall77 @dmitshur
[release-branch.go1.16] cmd/compile: ensure constant shift amounts ar…
1a6281d 
…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>
@golang golang locked and limited conversation to collaborators Oct 27, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
CherryPickApproved Used during the release process for point releases FrozenDueToAge
Projects
None yet
Milestone
Go1.16.10
Development

No branches or pull requests
5 participants
@mknyszek @dmitshur @randall77 @gopherbot @heschi