aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-02-03internal/testenv: exclude GOMAXPROCS when building test programmakepkgShulhan
In the environment where GOMAXPROCS set explicitly, for example to 3 in shell profile, the runtime tests will fail with the following error, ---- ok regexp/syntax 0.428s --- FAIL: TestCgroupGOMAXPROCS (0.81s) crash_test.go:186: running /home/ms/src/go/bin/go build -o /tmp/go-build1753772192/testprog.exe crash_test.go:208: built testprog in 796.664277ms --- FAIL: TestCgroupGOMAXPROCS/containermaxprocs=0 (0.00s) cgroup_linux_test.go:60: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (907.06µs): ok cgroup_linux_test.go:63: output got "3\n" want "4\n" --- FAIL: TestCgroupGOMAXPROCSNoLimit (0.00s) cgroup_linux_test.go:82: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (879.194µs): ok cgroup_linux_test.go:85: output got "3\n" want "4\n" --- FAIL: TestCgroupGOMAXPROCSHigherThanNumCPU (0.00s) cgroup_linux_test.go:102: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (852.396µs): ok cgroup_linux_test.go:105: output got "3\n" want "4\n" --- FAIL: TestCgroupGOMAXPROCSRound (0.01s) --- FAIL: TestCgroupGOMAXPROCSRound/50000 (0.00s) cgroup_linux_test.go:156: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (852.099µs): ok cgroup_linux_test.go:159: output got "3\n" want "2\n" --- FAIL: TestCgroupGOMAXPROCSRound/100000 (0.00s) cgroup_linux_test.go:156: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (894.001µs): ok cgroup_linux_test.go:159: output got "3\n" want "2\n" --- FAIL: TestCgroupGOMAXPROCSRound/150000 (0.00s) cgroup_linux_test.go:156: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (850.897µs): ok cgroup_linux_test.go:159: output got "3\n" want "2\n" --- FAIL: TestCgroupGOMAXPROCSSchedAffinity (0.00s) cgroup_linux_test.go:229: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (867.987µs): ok cgroup_linux_test.go:232: output got "3\n" want "2\n" FAIL FAIL runtime 23.088s ---- This changes exclude the GOMAXPROCS when building program for testing so it does not affect the tests.
2026-02-03all: set codereview remote name to upstreamShulhan
Change-Id: I474ea1ac91c7e994a1ec7c24ec1ef23bdc0a988f
2026-02-03testing: print the counter if its greater than 1Shulhan
When test run with "-count=Y" and Y is greater that 1, print a line to indicated the current round of test as "### X/Y".
2026-02-03encoding/json: realign struct encodeState, structFields, and fieldShulhan
This reduce the struct encodeState size from 56 to 16 bytes (-42), struct structFields size from 40 to 24 bytes (-16), and struct field size from 136 to 128 bytes (-8). Benchmark memory profiling before and after, File: json.test Type: alloc_space Time: Jan 25, 2024 at 4:51am (WIB) Showing nodes accounting for -4.01GB, 4.66% of 85.95GB total Dropped 64 nodes (cum <= 0.43GB) flat flat% sum% cum cum% -4.25GB 4.94% 4.94% -4.01GB 4.67% encoding/json.Marshal 0.19GB 0.22% 4.73% 0.24GB 0.28% encoding/json.mapEncoder.encode 0.05GB 0.057% 4.67% 0.05GB 0.057% reflect.copyVal 0.04GB 0.049% 4.62% 0.04GB 0.049% bytes.growSlice -0.04GB 0.045% 4.66% -0.04GB 0.045% encoding/json.RawMessage.MarshalJSON 0 0% 4.66% 0.04GB 0.046% bytes.(*Buffer).WriteString 0 0% 4.66% 0.04GB 0.049% bytes.(*Buffer).grow 0 0% 4.66% -0.04GB 0.045% encoding/json.(*Encoder).Encode 0 0% 4.66% 0.20GB 0.23% encoding/json.(*encodeState).marshal 0 0% 4.66% 0.20GB 0.23% encoding/json.(*encodeState).reflectValue
2026-02-03encoding/json: realign struct UnmarshalTypeError and decodeStateShulhan
This reduce the UnmarshalTypeError size from 64 to 56 bytes (-8 bytes), and decodeState from 128 to 96 (-32 bytes).
2026-02-03bufio: realign struct ScannerShulhan
This reduce the Scanner allocation size from 112 to 72 bytes.
2026-02-03bufio: realign struct ReaderShulhan
This reduce the Reader allocation size from 72 to 40 bytes and Writer allocation size from 64 to 40 bytes.
2026-02-03mime/quotedprintable: fix encoding where a period alone on a lineShulhan
Given the following example of message body, A line that precisely have length 75 with . + LF will cause DATA truncation.\n \n Footer.\n The quotedprintable Writer will encode the message into, A line ... truncation=\r\n .\r\n \r\n Footer.\r\n If we pass the Writer output into SMTP DATA command, the server read the "\r\n.\r\n" as the end of DATA which cause the message truncated on the receiver. This changes fix this issue by encode the period at the end with "=2E" based on recommendation in RFC 2049 Section 3, point (8) [1]. [1] https://www.rfc-editor.org/rfc/rfc2049.html#section-3 Fixes #61235 Change-Id: I350387b183ac6b25886f4084a060dcfcb48232a9
2026-02-03encoding/json: optimize isValidNumber functionShulhan
Instead of re-slicing the string for checking the value, use single index variable. Benchmark result, name old time/op new time/op delta NumberIsValid-8 19.0ns ± 0% 14.5ns ± 1% -23.70% (p=0.008 n=5+5) name old alloc/op new alloc/op delta NumberIsValid-8 0.00B 0.00B ~ (all equal) name old allocs/op new allocs/op delta NumberIsValid-8 0.00 0.00 ~ (all equal) Change-Id: I4698c5db134998f83ff47fb3add6a04ba6ec3aa0
2026-02-03all: prealloc slice with possible minimum capabilitiesShulhan
2026-02-03[DO-NOT-MERGE] all: add Makefile for common tasksShulhan
2026-02-03internal/poll: readWriteUnlock should destroy fd when no remaining referencesqmuntal
Fixes #77404 Change-Id: I0402becb94855baf942d6ba3815cc2a3c1526d6e Reviewed-on: https://go-review.googlesource.com/c/go/+/740921 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
2026-02-02compress/bzip2: use obscuretestdata.ReadFile to avoid creating temporaryIan Lance Taylor
The temporary was not being deleted. Not creating it at all is better. Change-Id: Id9c5498a2f7d2f58770a09a2a76f4ab30943dd3d Reviewed-on: https://go-review.googlesource.com/c/go/+/740780 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Michael Pratt <mpratt@google.com> Auto-Submit: Ian Lance Taylor <iant@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-02-02go/types, types2: add missing Named.unpack call in Checker.hasVarSizeMark Freeman
CL 734980 swapped use of Type.Underlying() in Checker.hasVarSize for traversal of Named.fromRHS. It forgot to call Named.unpack() before inspecting Named.fromRHS, allowing access of unexpanded instantiated types. These unexpanded instantiated types are then mistakenly marked as having fixed size, which fails assertions downstream. This change adds the missing Named.unpack() call and swaps direct access of Named.fromRHS for Named.rhs(), which verifies such access in debug mode. Fixes #77382 Change-Id: I324bbbbf790f8b09e95902ebe67f775483f88417 Reviewed-on: https://go-review.googlesource.com/c/go/+/740620 Reviewed-by: Robert Griesemer <gri@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-02-02testing/synctest: add SleepDamien Neil
Add a convenience function which combines time.Sleep and synctest.Wait. Fixes #77169 Change-Id: I2ff105105e95cfd8e5b4f72ccacf7afa59efb6bd Reviewed-on: https://go-review.googlesource.com/c/go/+/740066 Reviewed-by: Alan Donovan <adonovan@google.com> Auto-Submit: Damien Neil <dneil@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-02-02internal/maps,cmd/compile/internal/walk: replace calls to mapaccess1* with ↵ArsenySamoylov
mapaccess2* mapaccess1* and mapaccess2* functions share the same implementation and differ only in whether the boolean "found" is returned. This change replaces mapaccess1* calls with mapaccess2*. We can do this transparently, since the call site can safely discard the second (boolean) result. Ideally, mapacces1* functions could be removed entirely, but this change keeps them as thin wrappers for compatibility. Fixes #73196 Change-Id: I07c3423d22ed1095ac3666d00e134c2747b2f9c1 Reviewed-on: https://go-review.googlesource.com/c/go/+/736020 Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> Auto-Submit: Keith Randall <khr@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@golang.org>
2026-02-02encoding/json: use pooled encoder in Encoder.EncodeJoe Tsai
Due to the lack of MarshalWrite in the v1 API, it is unfortunately common to see: json.NewEncoder(out).Encode(in) where a single-use Encoder is constructed and thrown away. This performed acceptably in v1 since every call to Encode used a globally pooled encoder resource. Prior to this change, the v1-in-v2 implementation relied on a bytes.Buffer cached only for the lifetime of the Encoder object itself. Thus, a single-use Encoder does not benefit. Modify the wrapper implementation to use the internal pooled encoder from v2 and use the intermediate buffer to write directly to the output io.Writer. We assume that the user-provided io.Writer never leaks the buffer, but this assumption was already held in the v1 implementation. We are not increasing the surface area of data corruption risk. Performance of v1 to v1-in-v2 (before the pool fix): name old time/op new time/op delta NewEncoderEncode-32 30.2ms ± 4% 28.3ms ± 9% -6.19% (p=0.002 n=9+10) name old alloc/op new alloc/op delta NewEncoderEncode-32 7.64MB ± 0% 28.37MB ± 0% +271.23% (p=0.000 n=10+10) name old allocs/op new allocs/op delta NewEncoderEncode-32 200k ± 0% 100k ± 0% -49.99% (p=0.000 n=9+10) Interestingly, v1-in-2 is slightly faster, but the amount of allocated memory is massive. Performance of v1 to v1-in-v2 (after the pool fix): name old time/op new time/op delta NewEncoderEncode-32 30.2ms ± 4% 24.0ms ± 7% -20.36% (p=0.000 n=9+10) name old alloc/op new alloc/op delta NewEncoderEncode-32 7.64MB ± 0% 4.09MB ± 3% -46.52% (p=0.000 n=10+10) name old allocs/op new allocs/op delta NewEncoderEncode-32 200k ± 0% 100k ± 0% -50.00% (p=0.000 n=9+9) Now, the v1-in-v2 implementation is better than v1 on all metrics. Fixes #75026 Change-Id: I50c975b1d5b8da806e46bc627966b0a39c1817eb Reviewed-on: https://go-review.googlesource.com/c/go/+/740660 Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Damien Neil <dneil@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-02-02cmd/cover, cmd/covdata: actually delete temp dirsIan Lance Taylor
The code was using defer in TestMain, but was also calling os.Exit, which meant that the deferred functions did not run. TestMain does not require calling os.Exit, so stop doing it. Change-Id: I25ca64c36acf65dae3dc3f46e5fa513b9460a8e9 Reviewed-on: https://go-review.googlesource.com/c/go/+/740781 Reviewed-by: Than McIntosh <thanm@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Ian Lance Taylor <iant@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>
2026-02-02crypto/tls: document resumption behavior across ConfigsFilippo Valsorda
Updates #77113 Updates #77217 Updates CVE-2025-68121 Change-Id: Ia47904a9ed001275aad0243a6a0ce57e6a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/740240 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com> Auto-Submit: Filippo Valsorda <filippo@golang.org>
2026-02-02internal/poll: move buffer pinning inside execIOqmuntal
This is a step towards deferring adding the handle to IOCP until the first IO operation. The goal of this CL is to avoid the fd.isBlocking check in fd.pin, which was happening outside execIO, and making buffer pinning less error-prone. This also fixes an issue where buffer used in Pwrite and WriteTo were unpinned too early when the write buffer was larger than the maximum chunk size. For #76391 Cq-Include-Trybots: luci.golang.try:gotip-windows-amd64-longtest,gotip-windows-amd64-race Change-Id: Ia181dcb57a559ae466a4341c36a307ad6678aac0 Reviewed-on: https://go-review.googlesource.com/c/go/+/740561 Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-02-02internal/poll: consolidate cancelIO logic into waitIOqmuntal
This is a step towards deferring adding the handle to IOCP until the first IO operation. The main goal of this CL is to remove the fd.pollable() check in cancelIO. For #76391 Cq-Include-Trybots: luci.golang.try:gotip-windows-amd64-longtest,gotip-windows-amd64-race Change-Id: I76263ce12980297d88a5f6c514e4074dfee428cb Reviewed-on: https://go-review.googlesource.com/c/go/+/740540 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Damien Neil <dneil@google.com>
2026-02-02net: don't wait 5 seconds to re-read /etc/resolv.confBrad Fitzpatrick
If a Go process starts up, finds /etc/resolv.conf empty, then the DHCP client writes /etc/resolv.conf, the Go program would find itself broken for up to 5 seconds. We noticed this during integration tests in ephemeral VMs using gokrazy that boot into our application. Change-Id: Ia64c2b5c698a4ee3efc15d8a8f1850c47e531b84 Reviewed-on: https://go-review.googlesource.com/c/go/+/739620 Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-02-02net/http: try to drain response body upon closing for better connection re-useNicholas S. Husin
Currently, we have a rather inconsistent behavior in terms of whether a connection can be re-used or not when an HTTP body is not read to completion: - In HTTP/2, not reading bodies to completion is not an issue, since a new HTTP/2 stream can be created on the same TCP connection. - In HTTP/1 server, we discard up to 256 KiB of unconsumed request body, to potentially allow re-use. - In HTTP/1 client, we do not do anything, and fail to re-use a TCP connection if there are any unconsumed response body at all. This has led to some confusion. For example, some users have mistakenly discarded response body for HTTP/2 when doing so is not needed. Manually discarding response body can also be disadvantageous if the body is excessively large or is a never-ending stream. To solve this issue, this CL makes it so that closing a response body will cause any remaining content to be drained, up to a limit of 256 KiB or 50 milliseconds, whichever one is reached first. This allows better connection re-use for HTTP/1, and most users can now avoid having to manually drain their response body. For #77370 Change-Id: I71e1227fc9cf5f901362c8e234320817f6b0be24 Reviewed-on: https://go-review.googlesource.com/c/go/+/737720 Reviewed-by: Nicholas Husin <husin@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Damien Neil <dneil@google.com>
2026-02-02crypto/sha1: use const table for key loading on loong64Julian Zhu
Load constant keys from a static memory table rather than loading immediates into registers on loong64. Benchmark for Loongson-3A5000: goos: linux goarch: loong64 pkg: crypto/sha1 cpu: Loongson-3A5000-HV @ 2500.00MHz │ old │ new │ │ sec/op │ sec/op vs base │ Hash8Bytes/New-4 235.9n ± 0% 229.1n ± 0% -2.88% (p=0.000 n=8) Hash8Bytes/Sum-4 1.892µ ± 0% 1.882µ ± 0% -0.50% (p=0.000 n=8) Hash320Bytes/New-4 1022.0n ± 0% 963.8n ± 0% -5.70% (p=0.000 n=8) Hash320Bytes/Sum-4 1037.0n ± 0% 981.1n ± 0% -5.39% (p=0.000 n=8) Hash1K/New-4 2.760µ ± 0% 2.594µ ± 0% -6.01% (p=0.000 n=8) Hash1K/Sum-4 2.775µ ± 0% 2.610µ ± 0% -5.95% (p=0.000 n=8) Hash8K/New-4 20.46µ ± 0% 19.20µ ± 0% -6.17% (p=0.000 n=8) Hash8K/Sum-4 20.49µ ± 0% 19.22µ ± 0% -6.17% (p=0.000 n=8) geomean 2.498µ 2.377µ -4.87% │ old │ new │ │ B/s │ B/s vs base │ Hash8Bytes/New-4 32.34Mi ± 0% 33.30Mi ± 0% +2.98% (p=0.000 n=8) Hash8Bytes/Sum-4 4.034Mi ± 0% 4.053Mi ± 0% +0.47% (p=0.000 n=8) Hash320Bytes/New-4 298.7Mi ± 0% 316.7Mi ± 0% +6.02% (p=0.000 n=8) Hash320Bytes/Sum-4 294.3Mi ± 0% 311.0Mi ± 0% +5.69% (p=0.000 n=8) Hash1K/New-4 353.8Mi ± 0% 376.5Mi ± 0% +6.41% (p=0.000 n=8) Hash1K/Sum-4 351.9Mi ± 0% 374.1Mi ± 0% +6.31% (p=0.000 n=8) Hash8K/New-4 381.8Mi ± 0% 406.9Mi ± 0% +6.57% (p=0.000 n=8) Hash8K/Sum-4 381.4Mi ± 0% 406.4Mi ± 0% +6.58% (p=0.000 n=8) geomean 146.1Mi 153.6Mi +5.11% Change-Id: I7305caefa1434ab2bb4ce94a1c789d4ee5b7ccf3 Reviewed-on: https://go-review.googlesource.com/c/go/+/732580 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: abner chenc <chenguoqi@loongson.cn> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
2026-01-30runtime: delete unused parameter of userForcedTony Tang
delete unused parameter userForced Change-Id: I71c26ab5e3fadc532b6b1f266212c6f620769efd GitHub-Last-Rev: 6a32c8ff6e63f8b149c0803e8b6636022bd9d066 GitHub-Pull-Request: golang/go#76732 Reviewed-on: https://go-review.googlesource.com/c/go/+/727680 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Tony Tang <jianfeng.tony@gmail.com>
2026-01-30fmt: avoid storing input arguments on pp to help escape analysisthepudds
This is part of a series of CLs that aim to reduce how often interface arguments escape for the print functions in fmt, such as val here: func f(val int) { fmt.Sprintf("%d", val) } Prior to this change, arguments immediately escape in doPrintf because they are stored on the *pp in printArg: parameter a leaks to <heap> for (*pp).doPrintf with derefs=1: flow: <heap> ← *a: from a[argNum] (dot of pointer) at .\print.go:1077:18 from (*pp).printArg(p, a[argNum], rune(c)) (call parameter) at .\print.go:1077:16 parameter arg leaks to <heap> for (*pp).printArg with derefs=0: flow: <heap> ← arg: from p.arg = arg (assign) at .\print.go:682:8 The *pp is heap allocated, and the heap cannot point to stack variables, so the arguments currently cannot be on the stack. This change instead threads through the input arguments as individual type any and reflect.Value parameters, rather than storing on the *pp. After this change, input arguments still escape, but now for other reasons. Updates #8618 Updates #62653 Change-Id: I81984daeceb761ce4ce269b150b888950ce2c5d4 Reviewed-on: https://go-review.googlesource.com/c/go/+/524938 Reviewed-by: Damien Neil <dneil@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2026-01-30runtime: align end of systemstack_switch prologue on amd64 for consistency ↵Vasily Leonenko
with gosave_systemstack_switch gosave_systemstack_switch saves PC with fixed offset of 8 bytes from systemstack_switch to bypass prologue. This commit makes this offset consistent with actual address of UNDEF instruction intended to be at that address. Fixes #71440 Change-Id: Ibe6458c5bcb0bdaec228a2f13d6aec7ecc0e319e Reviewed-on: https://go-review.googlesource.com/c/go/+/740360 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2026-01-30all: switch linux-ppc64 target to ELFv2 ABIPaul Murphy
Go is only capable of producing internally linked, static binaries on linux-ppc64. As such, binaries should run in either ELFv1 or ELFv2 ppc64 userspaces today. This opens the door to enabling cgo and external linking which will require ELFv2 support and userspace, eventually. Fixes #76244 Change-Id: I5ca15037cbe546f352e8693dcf14da51a308b8ca Reviewed-on: https://go-review.googlesource.com/c/go/+/734540 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2026-01-30cmd/go,crypto/mlkem,crypto/x509,encoding/ascii85: clean up ↵Neal Patel
tautological/impossible nil conditions Change-Id: I3cdc599ebc93f5c9be5645e7ef7ce167242d9c1b Reviewed-on: https://go-review.googlesource.com/c/go/+/739800 Reviewed-by: Roland Shoemaker <roland@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-01-29test/codegen: add bitwise operation combination testsXiaolin Zhao
This commit adds two test functions, bitsOptXor1 and bitsOptXor2, to verify that the compiler correctly optimizes certain bitwise expression patterns in future CLs. Change-Id: Idf5bd1ff8653f8fa218604d857639e063546d8e7 Reviewed-on: https://go-review.googlesource.com/c/go/+/736540 Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: abner chenc <chenguoqi@loongson.cn> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-01-29cmd/compile/internal/bloop: avoid extraneous heap allocs in b.Loop body due ↵thepudds
to autotmp variable scope The motivating example I created for #73137 still seems to heap allocate in go1.26rc2 when used in a b.Loop body. │ go1.25 │ go1.26rc2 │ │ allocs/op │ allocs/op vs base │ NewX/b.Loop-basic-4 1.000 ± 0% 1.000 ± 0% ~ (p=1.000 n=10) ¹ I suspect it is because the temps are by default declared outside the loop body, which escape analysis will determine is an escaping value and result in a heap allocation. (I've seen this problem before, including in my older CL 546023 that attempts to help PGO with a similar issue.) This is an attempt to address that by placing ODCLs within the b.Loop body for the temps that are created so that they can be marked keepalive. There are two cases handled in the CL: function return values and function arguments. The first case is what affects my example from #73137, and is also illustrated via the NewX test case in the new test/escape_bloop.go file. Without this CL, the NewX call in the BenchmarkBloop test is inlined, which is an improvement over Go 1.25, but the slice still escapes because the temporary used for the return value is declared outside the loop body. With this CL, the slice does not escape. The second case is illustrated via the new BenchmarkBLoopFunctionArg test, which shows a function argument that escapes without this CL but does not escape with this CL. We can also make the two new b.Loop tests in testing/benchmark_test.go individually pass or fail as expected based on individually reverting the two changes in this CL. While we are here, we add a note to typecheck.TempAt to help make people aware of this behavior. Updates #73137 Fixes #77339 Change-Id: I69abe978367a8d3a931430aec5d85c9c54b42c1f Reviewed-on: https://go-review.googlesource.com/c/go/+/738822 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Junyang Shao <shaojunyang@google.com>
2026-01-29cmd/link: put type:* at the start of the type descriptorsIan Lance Taylor
That used to happen naturally because the symbol had zero size. After CL 724261 we need to force it. Fixes #77372 Change-Id: Ia8eef989bc9cbad5459b60ff6535136e7e0c6cab Reviewed-on: https://go-review.googlesource.com/c/go/+/740400 Reviewed-by: Keith Randall <khr@golang.org> Auto-Submit: Ian Lance Taylor <iant@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Keith Randall <khr@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-01-29cmd/compile: make prove use non-equality in subtraction for a stronger boundJonah Uellenberg
Given: s := /* slice */ k := /* proved valid index in s (0 <= k < len(s)) */ v := s[k:] len(v) >= 1, so v[0] needs no bounds check. However, for len(v) = len(s) - k, we only checked if len(s) >= k and so could only prove len(v) >= 0, thus the bounds check wasn't removed. As far as I can tell these checks were commented out for performance, but after benchmarking prove I see no difference. Fixes: #76429 Change-Id: I39ba2a18cbabc0559924d4d226dcb99dbe9a06ed GitHub-Last-Rev: 53f3344d261986cd021c8d7b8435ab89b5438b8f GitHub-Pull-Request: golang/go#76609 Reviewed-on: https://go-review.googlesource.com/c/go/+/725100 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Auto-Submit: Keith Randall <khr@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2026-01-29cmd/link: remove AIX special case for first type descriptorIan Lance Taylor
It doesn't seem to be necessary, and removing it seems cleaner than adding an AIX case to the code in runtime.moduleTypelinks. Fixes #77365 Change-Id: I59fa56abf42e18017bd112481ea09d0cca47d105 Reviewed-on: https://go-review.googlesource.com/c/go/+/740220 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Ian Lance Taylor <iant@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
2026-01-29go/token: simplify fixOffsetMateusz Poliwczak
Each time I go to definition of this I am deeply confused at what I am looking, so let's clean this a bit with modern Go. Change-Id: I8f44e78f0cdde9b970388f9b98a2720e6a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/738341 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Alan Donovan <adonovan@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Alan Donovan <adonovan@google.com>
2026-01-29cmd/link: adjust symkind comparisons in XCOFF codeIan Lance Taylor
This XCOFF symkind comparison broke when STYPE moved in CL 723580. These comparisons are unmaintainable, but at least the new code is no worse than the old code. Change-Id: I1be9de6afdf1814aaadcd2105e6247a4b66b46fe Reviewed-on: https://go-review.googlesource.com/c/go/+/740200 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Ian Lance Taylor <iant@golang.org>
2026-01-29cmd/compile: update ABI document for loong64Guoqi Chen
The duff device has been dropped on loong64, now we can remove related documentation. Change-Id: I0bd721adc227522ae3c56dfe199ef735cfdf5d33 Reviewed-on: https://go-review.googlesource.com/c/go/+/740260 Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@golang.org>
2026-01-29runtime: use smaller max align for arm32Keith Randall
Maybe fixes a dashboard build failure for linux/arm32 casued by CL 724261. This value comes from cmd/link/internal/arm/l.go (and in general, maxAlign in cmd/link/internal/$ARCH/<something>.go). Change-Id: I4d02cd41072da1b6ad6c7405044bd7788626b013 Reviewed-on: https://go-review.googlesource.com/c/go/+/740101 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> Auto-Submit: Keith Randall <khr@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2026-01-29runtime, cmd/link: store type descriptor length, not endIan Lance Taylor
Storing the type descriptor length lets us save a relocation. It also avoids a problem for Darwin dynamic linking. For #6853 Fixes #77350 Change-Id: If5c94330fe10d75690325f3d0b0658060ef3eb2d Reviewed-on: https://go-review.googlesource.com/c/go/+/739681 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-01-28go/scanner: document implicit semicolon in multiline commentsMateusz Poliwczak
Updates #54941 Change-Id: I62406c53b5b27742003098c77cfba0a96a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/738720 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Alan Donovan <adonovan@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2026-01-28go/parser: use (*Scanner).End instead of scannerhooksMateusz Poliwczak
Also drop the scannerhooks code, as it is now unused. Updates #74958 Updates #76031 Change-Id: I5a0cb8a7fe954e40ce40b8406aed0d3f6a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/738701 Reviewed-by: Alan Donovan <adonovan@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2026-01-28go/parser: use (*Scanner).End in error testingMateusz Poliwczak
Updates #74958 Change-Id: I43dcbff6ec828bddf157b2e6ec80df526a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/738700 Reviewed-by: Alan Donovan <adonovan@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2026-01-28go/scanner: add End method to ScannerMateusz Poliwczak
Fixes #74958 Change-Id: I50ef64ae9ae6a762a7aada3d29914bae6a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/738681 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Alan Donovan <adonovan@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-01-28math: optimize the floating-point pipeline on loong64Xiaolin Zhao
Using the FSEL instruction on loong64 to eliminate branches and reduce pipeline interruptions. On the Loongson CPU 3A6000, there is a 0.09% performance improvement, as follows: goos: linux goarch: loong64 pkg: math/big cpu: Loongson-3A6000-HV @ 2500.00MHz │ old.bench │ new.bench │ │ sec/op │ sec/op vs base │ Exp 7.748m ± 0% 7.740m ± 0% -0.10% (p=0.001 n=10) Exp2 7.747m ± 0% 7.741m ± 0% -0.09% (p=0.002 n=10) geomean 7.747m 7.740m -0.09% Change-Id: If62f2e81bf345c83a1fa9350ace131240cfa3b9b Reviewed-on: https://go-review.googlesource.com/c/go/+/693458 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: abner chenc <chenguoqi@loongson.cn> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Meidan Li <limeidan@loongson.cn>
2026-01-28simd/archsimd: add missing cpufeature to generated mask/merge methodsDavid Chase
Change-Id: I34678f4ef17fe1b8b7657a2c3d39685b4a5951f2 Reviewed-on: https://go-review.googlesource.com/c/go/+/739981 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2026-01-28cmd/compile, simd: capture VAES instructions and fix AVX512VAES featureJunyang Shao
The code previously filters out VAES-only instructions, this CL added them back. This CL added the VAES feature check following the Intel xed data: XED_ISA_SET_VAES: vaes.7.0.ecx.9 # avx.1.0.ecx.28 This CL also found out that the old AVX512VAES feature check is not checking the correct bits, it also fixes it: XED_ISA_SET_AVX512_VAES_128: vaes.7.0.ecx.9 aes.1.0.ecx.25 avx512f.7.0.ebx.16 avx512vl.7.0.ebx.31 XED_ISA_SET_AVX512_VAES_256: vaes.7.0.ecx.9 aes.1.0.ecx.25 avx512f.7.0.ebx.16 avx512vl.7.0.ebx.31 XED_ISA_SET_AVX512_VAES_512: vaes.7.0.ecx.9 aes.1.0.ecx.25 avx512f.7.0.ebx.16 It restricts to the most strict common set - includes avx512vl for even 512-bits although it doesn't requires it. Change-Id: I4e2f72b312fd2411589fbc12f9ee5c63c09c2e9a Reviewed-on: https://go-review.googlesource.com/c/go/+/738500 Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-01-28runtime/metrics: fix panic in Read with empty sliceAmol Yadav
Calling Read with a nil or empty slice previously caused a panic with "index out of range" because the function unconditionally accessed the first element of the slice (via &m[0]) to pass the pointer to the runtime. This change adds a check for len(m) == 0 to return early, preventing the panic when no samples are provided. Fixes #77231 Change-Id: I442635f5c61de432883c8d0efae9cc6aa1363cc9 GitHub-Last-Rev: 6f24f67b18c77a0b36b92017a3f4ef8aa3aa5229 GitHub-Pull-Request: golang/go#77233 Reviewed-on: https://go-review.googlesource.com/c/go/+/737380 Reviewed-by: Amol Yadav <amolyadav6125@gmail.com> Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Michael Pratt <mpratt@google.com> Commit-Queue: Michael Pratt <mpratt@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2026-01-28crypto/tls: check verifiedChains roots when resuming sessionsRoland Shoemaker
When resuming TLS sessions, on the server and client verify that the chains stored in the session state (verifiedChains) are still acceptable with regards to the Config by checking for the inclusion of the root in either ClientCAs (server) or RootCAs (client). This prevents resuming a session with a certificate chain that would be rejected during a full handshake due to an untrusted root. Updates #77113 Updates #77217 Updates CVE-2025-68121 Change-Id: I11fe00909ef1961c24ecf80bf5b97f7b1121d359 Reviewed-on: https://go-review.googlesource.com/c/go/+/737700 Auto-Submit: Roland Shoemaker <roland@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Coia Prant <coiaprant@gmail.com> Reviewed-by: Filippo Valsorda <filippo@golang.org>
2026-01-28crypto/tls: add verifiedChains expiration checking during resumptionRoland Shoemaker
When resuming a session, check that the verifiedChains contain at least one chain that is still valid at the time of resumption. If not, trigger a new handshake. Updates #77113 Updates #77217 Updates CVE-2025-68121 Change-Id: I14f585c43da17802513cbdd5b10c552d7a38b34e Reviewed-on: https://go-review.googlesource.com/c/go/+/739321 Reviewed-by: Coia Prant <coiaprant@gmail.com> Reviewed-by: Filippo Valsorda <filippo@golang.org> Auto-Submit: Roland Shoemaker <roland@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2026-01-28Revert "crypto/tls: don't copy auto-rotated session ticket keys in Config.Clone"Roland Shoemaker
This reverts CL 736709 (commit bba24719a4cad5cc8d771fc9cfff5a38019d554a). Updates #77113 Updates CVE-2025-68121 Change-Id: I0261cb75e9adf9d0ac9890dc91ae8476b8988ba0 Reviewed-on: https://go-review.googlesource.com/c/go/+/739320 Reviewed-by: Coia Prant <coiaprant@gmail.com> Reviewed-by: Filippo Valsorda <filippo@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
generated by cgit v1.3 (git 2.53.0) at 2026-04-15 04:21:56 +0000