commit dddf0ae40fa0c1223aba191d73a44425a08e1035 [browse]
Author: Gopher Robot
Date: 2024-04-03 15:18:03 Z

[release-branch.go1.22] go1.22.2

Change-Id: I9f348a8ddc79c65be86099839523548edef30095
Reviewed-on: https://go-review.googlesource.com/c/go/+/576118
Auto-Submit: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Bypass: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Commit-Queue: Gopher Robot <gobot@golang.org>

commit e55d7cf8435ba4e58d4a5694e63b391821d4ee9b [browse]
Author: Damien Neil
Date: 2024-03-28 16:57:51 -07:00

[release-branch.go1.22] net/http: update bundled golang.org/x/net/http2

Disable cmd/internal/moddeps test, since this update includes PRIVATE
track fixes.

Fixes CVE-2023-45288
For #65051
Fixes #66298

Change-Id: I5bbf774ebe7651e4bb7e55139d3794bd2b8e8fa8
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/2197227
Reviewed-by: Tatiana Bradley <tatianabradley@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/576076
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Bypass: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>

commit 4edf4bb2c617b8e03da34355849c2a23ec058a89 [browse]
Author: Damien Neil
Date: 2024-03-27 15:01:59 -07:00

[release-branch.go1.22] all: update golang.org/x/net

Pulls in one HTTP/2 fix:

	ae3c50b55f http2: reject DATA frames after 1xx and before final headers

For golang/go#65927
Fixes golang/go#66255

Change-Id: Ib810455297083fc0722a997d0aa675132c38393c
Reviewed-on: https://go-review.googlesource.com/c/go/+/574935
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Bypass: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>

commit 2c6d106541c1976c52f0c835ce1edbf5ac06b2f2 [browse]
Author: Keith Randall
Date: 2024-03-12 12:56:03 -07:00

[release-branch.go1.22] cmd/compile: don't assume args are always zero-extended

On amd64, we always zero-extend when loading arguments from the stack.
On arm64, we extend based on the type. This causes problems with
zeroUpper*Bits, which reports the top bits are zero when they aren't.

Fix it to use the type to decide if the top bits are really zero.

For tests, only f32 currently fails on arm64. Added other tests
just for future-proofing.

Fixes #66076

Change-Id: I2f13fb47198e139ef13c9a34eb1edc932eea3ee3
Reviewed-on: https://go-review.googlesource.com/c/go/+/571135
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
(cherry picked from commit 6bf8b76b95b22e3a7fbcd7cb95bfdb3f42bba60a)
Reviewed-on: https://go-review.googlesource.com/c/go/+/573395
Reviewed-by: Cherry Mui <cherryyz@google.com>

commit 46587483e30188ce485097cdeb48a4d1e0c8a445 [browse]
Author: Keith Randall
Date: 2024-03-02 19:22:07 -08:00

[release-branch.go1.22] cmd/compile: fix sign/zero-extension removal

When an opcode generates a known high bit state (typically, a sub-word
operation that zeros the high bits), we can remove any subsequent
extension operation that would be a no-op.

x = (OP ...)
y = (ZeroExt32to64 x)

If OP zeros the high 32 bits, then we can replace y with x, as the
zero extension doesn't do anything.

However, x in this situation normally has a sub-word-sized type.  The
semantics of values in registers is typically that the high bits
beyond the value's type size are junk. So although the opcode
generating x *currently* zeros the high bits, after x is rewritten to
another opcode it may not - rewrites of sub-word-sized values can
trash the high bits.

To fix, move the extension-removing rules to late lower. That ensures
that their arguments won't be rewritten to change their high bits.

I am also worried about spilling and restoring. Spilling and restoring
doesn't preserve the high bits, but instead sets them to a known value
(often 0, but in some cases it could be sign-extended).  I am unable
to come up with a case that would cause a problem here, so leaving for
another time.

Update #66076

Change-Id: I3b5c091b3b3278ccbb7f11beda8b56f4b6d3fde7
Reviewed-on: https://go-review.googlesource.com/c/go/+/568616
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
(cherry picked from commit a46ecdca36b2359e7496c6d694703a9a9706d760)
Reviewed-on: https://go-review.googlesource.com/c/go/+/573375