cmd/compile: encoding/binary.PutUint16 sometimes doesn't write [1.20 backport] #59374
Labels
CherryPickApproved
Used during the release process for point releases
compiler/runtime
Issues related to the Go compiler and/or runtime.
FrozenDueToAge
Milestone
Comments
gopherbot
added
the
CherryPickCandidate
gopherbot
added
the
compiler/runtime
|
Change https://go.dev/cl/483176 mentions this issue: |
dr2chase
added
the
CherryPickApproved
gopherbot
removed
the
CherryPickCandidate
|
Closed by merging 0684cec to release-branch.go1.20. |
gopherbot
pushed a commit
that referenced
this issue
Apr 24, 2023
…n multi-byte stores Use the type of the store for the byteswap, not the type of the store's value argument. Normally when we're storing a 16-bit value, the value being stored is also typed as 16 bits. But sometimes it is typed as something smaller, usually because it is the result of an upcast from a smaller value, and that upcast needs no instructions. If the type of the store's arg is thinner than the type being stored, and the byteswap'd value uses that thinner type, and the byteswap'd value needs to be spilled & restored, that spill/restore happens using the thinner type, which causes us to lose some of the top bits of the value. Fixes #59374 Change-Id: If6ce1e8a76f18bf8e9d79871b6caa438bc3cce4d Reviewed-on: https://go-review.googlesource.com/c/go/+/481395 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> (cherry picked from commit b3bc862) Reviewed-on: https://go-review.googlesource.com/c/go/+/483176 Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
bradfitz
pushed a commit
to tailscale/go
that referenced
this issue
May 25, 2023
…n multi-byte stores Use the type of the store for the byteswap, not the type of the store's value argument. Normally when we're storing a 16-bit value, the value being stored is also typed as 16 bits. But sometimes it is typed as something smaller, usually because it is the result of an upcast from a smaller value, and that upcast needs no instructions. If the type of the store's arg is thinner than the type being stored, and the byteswap'd value uses that thinner type, and the byteswap'd value needs to be spilled & restored, that spill/restore happens using the thinner type, which causes us to lose some of the top bits of the value. Fixes golang#59374 Change-Id: If6ce1e8a76f18bf8e9d79871b6caa438bc3cce4d Reviewed-on: https://go-review.googlesource.com/c/go/+/481395 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> (cherry picked from commit b3bc862) Reviewed-on: https://go-review.googlesource.com/c/go/+/483176 Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
bradfitz
pushed a commit
to tailscale/go
that referenced
this issue
May 25, 2023
…n multi-byte stores Use the type of the store for the byteswap, not the type of the store's value argument. Normally when we're storing a 16-bit value, the value being stored is also typed as 16 bits. But sometimes it is typed as something smaller, usually because it is the result of an upcast from a smaller value, and that upcast needs no instructions. If the type of the store's arg is thinner than the type being stored, and the byteswap'd value uses that thinner type, and the byteswap'd value needs to be spilled & restored, that spill/restore happens using the thinner type, which causes us to lose some of the top bits of the value. Fixes golang#59374 Change-Id: If6ce1e8a76f18bf8e9d79871b6caa438bc3cce4d Reviewed-on: https://go-review.googlesource.com/c/go/+/481395 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> (cherry picked from commit b3bc862) Reviewed-on: https://go-review.googlesource.com/c/go/+/483176 Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
@randall77 requested issue #59367 to be considered for backport to the next 1.20 minor release.
The text was updated successfully, but these errors were encountered: