aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-01-28cmd/compile: simplify slice/array range loops on loong64Guoqi Chen
loong64 supports R+R addressing ({st,ld}x.{b,h,w,d} instructions) and has implemented the relevant lowering rules (only width is 1). Removes 1616 instructions from the go binary on loong64. file before after Δ % asm 575366 575314 -52 -0.0090% cgo 489972 489884 -88 -0.0180% compile 2920418 2920110 -308 -0.0105% cover 540458 540290 -168 -0.0311% fix 865840 865668 -172 -0.0199% link 732858 732662 -196 -0.0267% preprofile 246022 245978 -44 -0.0179% vet 839268 839124 -144 -0.0172% go 1666470 1666114 -356 -0.0214% gofmt 326526 326438 -88 -0.0270% total 9203198 9201582 -1616 -0.0176% Change-Id: If3518547c785764877a6cf987781d43d8b572990 Reviewed-on: https://go-review.googlesource.com/c/go/+/738240 Reviewed-by: Keith Randall <khr@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2026-01-28cmd/compile: (loong64) optimize float32(abs|sqrt64(float64(x)))Xiaolin Zhao
Ref: #733621 Updates #75463 Change-Id: Idd8821d1713754097a2fe83a050c25d9ec5b17eb Reviewed-on: https://go-review.googlesource.com/c/go/+/735540 Reviewed-by: abner chenc <chenguoqi@loongson.cn> 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>
2026-01-28cmd/compile: remove the NORconst op on mips{,64}Xiaolin Zhao
In the mips{,64} instruction sets and their extensions, there is no NORI instruction. Change-Id: If008442c792297d011b3d0c1e8501e62e32ab175 Reviewed-on: https://go-review.googlesource.com/c/go/+/735900 Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: abner chenc <chenguoqi@loongson.cn> Reviewed-by: Cherry Mui <cherryyz@google.com>
2026-01-27reflect: allow conversions between slices of named {byte,rune} and stringKeith Randall
So the reflect behavior matches that of the language. These conversions are allowed: []myByte <-> string []myRune <-> string []myByte <-> myString []myRune <-> myString And even if the left-hand-side is named, e.g. myBytes([]myByte) <-> string Fixes #53523 Change-Id: I6562e72bc233a45dc7b02f75f68020831ad399ea Reviewed-on: https://go-review.googlesource.com/c/go/+/739680 Auto-Submit: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Robert Griesemer <gri@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-01-27cmd/link, runtime: remove typelinksIan Lance Taylor
Instead of adding a typelinks section to a Go binary, mark the start and end of the typelinked type descriptors. The runtime can then step through the descriptors to find them all, rather than relying on the extra linker-generated offset list. The runtime steps through the type descriptors lazily, as many Go programs don't need the typelinks list at all. This reduces the size of cmd/go by 15K bytes, which isn't much but it's not nothing. A future CL will change the reflect package to use the type pointers directly rather than converting to offsets and then back to type pointers. For #6853 Change-Id: Id0af4ce81c5b1cea899fc92b6ff9d2db8ce4c267 Reviewed-on: https://go-review.googlesource.com/c/go/+/724261 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Ian Lance Taylor <iant@golang.org>
2026-01-27os/exec: document blocking Stdin/Stdout/StderrIan Lance Taylor
WaitDelay only handles writes to Stdin and reads from Stdout/Stderr. If Stdin is set to a blocking Reader, or Stdout/Stderr are set to a blocking Writer, Wait can hang indefinitely. I don't see any way to fix this with the current API, as there is no general way that the os/exec package can interrupt the blocking Read or Write. This CL documents the limitation and points people toward the workaround of using StdinPipe/StdoutPipe/StderrPipe and arranging for their own way to interrupt the blocking Read or Write. Fixes #77227 Change-Id: I3150ae7af89dccf8d859b41eb43eaf0bbbb55fee Reviewed-on: https://go-review.googlesource.com/c/go/+/739422 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Ian Lance Taylor <iant@golang.org> Reviewed-by: Sean Liao <sean@liao.dev> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
2026-01-27cmd/link: remove unused symbol kind SFUNCTABIan Lance Taylor
Change-Id: Ica7201dabe7f72b9470d8acbad043a34a20345a9 Reviewed-on: https://go-review.googlesource.com/c/go/+/724121 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Auto-Submit: Ian Lance Taylor <iant@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2026-01-27simd/archsimd: fix typo in the SHA256Message1 documentation stringNeal Patel
Change-Id: I8bc5fec0475bfaebc0469d0efb2ba89af4b3f150 Reviewed-on: https://go-review.googlesource.com/c/go/+/738640 Reviewed-by: Junyang Shao <shaojunyang@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-01-27cmd/link: handle SRODATALRELRO in xcoffUpdateOuterSizeIan Lance Taylor
This is a followup to CL 723580. This fixes cgo builds on AIX. For #76038 Change-Id: Idea959615891f3f6e33932fae7a9043778db3366 Reviewed-on: https://go-review.googlesource.com/c/go/+/738920 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Auto-Submit: Ian Lance Taylor <iant@golang.org>
2026-01-27go/types, types2: rename Named.finite to Named.varSizeMark Freeman
Change-Id: I81646c2753c2e44953b116138cb41d41a011ff08 Reviewed-on: https://go-review.googlesource.com/c/go/+/739561 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Mark Freeman <markfreeman@google.com> Reviewed-by: Robert Griesemer <gri@google.com>
2026-01-27internal/runtime/gc/scan: include package in expandAVX512 symbol namesMichael Pratt
These symbols are part of the scan package, so they should include the package name in the symbol name for consistency. Change-Id: I6a6a636ca63b34a8da7fb2f0bfe1fa5f8672fff5 Reviewed-on: https://go-review.googlesource.com/c/go/+/738522 Reviewed-by: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-01-27runtime: rename aeshashbody to runtime.aeshashbodyMichael Pratt
Currently this is a raw symbol name with no package component, which is confusing when seen in profilers or similar tools. This function does not follow a Go ABI, and thus should not have a Go function declaration. go vet requires declaration for standard assembly functions. CL 176100 removed the package name as part of making vet pass on package runtime, but simply making the function static via the <> suffix is sufficient, there is no need to shorten the symbol name. Change-Id: I6a6a636c6030f1c9a4b8bb330978733bb336b08e Reviewed-on: https://go-review.googlesource.com/c/go/+/738521 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2026-01-27go/types, types2: add check for map value completeness in IndexExprMark Freeman
An index expression can also go from map[K]V to V. Since V could be incomplete (due to some admittedly contrived syntax), we need a check. Change-Id: I03ffbfc0e5bcc9129591d60dfbaa5fafcf8fb183 Reviewed-on: https://go-review.googlesource.com/c/go/+/737620 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Robert Griesemer <gri@google.com> Auto-Submit: Mark Freeman <markfreeman@google.com>
2026-01-27go/types, types2: replace pendingType with completion checkMark Freeman
This change establishes the invariant that Underlying() cannot observe a nil RHS for a defined type, unless that type was created by go/types with an explicitly nil underlying type. It does so using isComplete, which is a guard to check that a type has an underlying type. This guard is needed whenever we could produce a value of a defined type or access some property of a defined type. Examples include T{}, *x (where x has type *T), T.x, etc. (see CL 734600 for more). The pendingType mechanism to deeply traverse values of a defined type is moved to hasVarSize, since this is only truly needed at the site of a built-in such as unsafe.Sizeof. This ties cycle detection across value context directly to the syntax, which seems like the right direction. Change-Id: Ic47862a2038fb2ba3ae6621e9907265ccbd86ea3 Reviewed-on: https://go-review.googlesource.com/c/go/+/734980 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Robert Griesemer <gri@google.com> Auto-Submit: Mark Freeman <markfreeman@google.com>
2026-01-27cmd/compile, runtime: avoid improper control transfer instruction hints on ↵wangboyao
riscv64 On RISC-V the JAL and JALR instructions provide Return Address Stack(RAS) prediction hints based on the registers used (as per section 2.5.1 of the RISC-V ISA manual). When a JALR instruction uses X1 or X5 as the source register, it hints that a pop should occur. When making a function call, avoid the use of X5 as a source register since this results in the RAS performing a pop-then-push instead of a push, breaking call/return pairing and significantly degrading front-end branch prediction performance. Based on test result of golang.org/x/benchmarks/json on SpacemiT K1, fix version has a performance improvement of about 7% Fixes #76654 Change-Id: I867c8d7cfb54f5decbe176f3ab3bb3d78af1cf64 Reviewed-on: https://go-review.googlesource.com/c/go/+/726760 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Joel Sing <joel@sing.id.au> Run-TryBot: Joel Sing <joel@sing.id.au>
2026-01-27crypto/subtle: add vector implementation of xorBytes for riscv64Joel Sing
On a Banana Pi F3: │ subtle.1 │ subtle.2 │ │ sec/op │ sec/op vs base │ ConstantTimeSelect-8 4.391n ± 1% 4.390n ± 0% ~ (p=0.500 n=10) ConstantTimeByteEq-8 3.763n ± 0% 3.764n ± 0% ~ (p=0.549 n=10) ConstantTimeEq-8 3.767n ± 1% 3.764n ± 0% -0.08% (p=0.002 n=10) ConstantTimeLessOrEq-8 3.136n ± 0% 3.138n ± 0% +0.06% (p=0.002 n=10) XORBytes/8Bytes-8 53.42n ± 0% 52.28n ± 0% -2.13% (p=0.000 n=10) XORBytes/128Bytes-8 64.79n ± 0% 64.12n ± 0% -1.03% (p=0.000 n=10) XORBytes/2048Bytes-8 479.3n ± 0% 322.0n ± 0% -32.84% (p=0.000 n=10) XORBytes/8192Bytes-8 8.897µ ± 26% 7.734µ ± 12% ~ (p=0.165 n=10) XORBytes/32768Bytes-8 39.17µ ± 17% 35.40µ ± 24% -9.63% (p=0.029 n=10) XORBytesAlignment/8Bytes0Offset-8 51.74n ± 0% 54.18n ± 0% +4.72% (p=0.000 n=10) XORBytesAlignment/8Bytes1Offset-8 51.51n ± 1% 53.52n ± 0% +3.92% (p=0.000 n=10) XORBytesAlignment/8Bytes2Offset-8 51.35n ± 1% 53.58n ± 0% +4.34% (p=0.000 n=10) XORBytesAlignment/8Bytes3Offset-8 50.86n ± 0% 53.56n ± 0% +5.31% (p=0.000 n=10) XORBytesAlignment/8Bytes4Offset-8 51.62n ± 0% 54.20n ± 0% +4.98% (p=0.000 n=10) XORBytesAlignment/8Bytes5Offset-8 51.42n ± 1% 53.48n ± 0% +4.02% (p=0.000 n=10) XORBytesAlignment/8Bytes6Offset-8 51.08n ± 1% 53.46n ± 0% +4.67% (p=0.000 n=10) XORBytesAlignment/8Bytes7Offset-8 50.83n ± 0% 53.54n ± 0% +5.33% (p=0.000 n=10) XORBytesAlignment/128Bytes0Offset-8 63.67n ± 0% 66.04n ± 0% +3.72% (p=0.000 n=10) XORBytesAlignment/128Bytes1Offset-8 114.40n ± 0% 67.42n ± 0% -41.07% (p=0.000 n=10) XORBytesAlignment/128Bytes2Offset-8 113.85n ± 0% 67.43n ± 0% -40.78% (p=0.000 n=10) XORBytesAlignment/128Bytes3Offset-8 114.60n ± 0% 67.31n ± 0% -41.27% (p=0.000 n=10) XORBytesAlignment/128Bytes4Offset-8 109.30n ± 0% 67.45n ± 0% -38.29% (p=0.000 n=10) XORBytesAlignment/128Bytes5Offset-8 110.70n ± 0% 67.32n ± 1% -39.19% (p=0.000 n=10) XORBytesAlignment/128Bytes6Offset-8 110.05n ± 0% 67.45n ± 1% -38.71% (p=0.000 n=10) XORBytesAlignment/128Bytes7Offset-8 110.60n ± 0% 67.43n ± 0% -39.04% (p=0.000 n=10) XORBytesAlignment/2048Bytes0Offset-8 478.4n ± 0% 335.6n ± 0% -29.85% (p=0.000 n=10) XORBytesAlignment/2048Bytes1Offset-8 529.7n ± 0% 349.3n ± 0% -34.05% (p=0.000 n=10) XORBytesAlignment/2048Bytes2Offset-8 529.3n ± 0% 349.8n ± 0% -33.91% (p=0.000 n=10) XORBytesAlignment/2048Bytes3Offset-8 529.8n ± 0% 349.5n ± 0% -34.02% (p=0.000 n=10) XORBytesAlignment/2048Bytes4Offset-8 524.7n ± 0% 349.6n ± 0% -33.38% (p=0.000 n=10) XORBytesAlignment/2048Bytes5Offset-8 525.9n ± 0% 349.6n ± 0% -33.52% (p=0.000 n=10) XORBytesAlignment/2048Bytes6Offset-8 525.1n ± 0% 349.8n ± 0% -33.39% (p=0.000 n=10) XORBytesAlignment/2048Bytes7Offset-8 526.0n ± 0% 349.8n ± 0% -33.51% (p=0.000 n=10) geomean 120.0n 96.92n -19.23% │ subtle.1 │ subtle.2 │ │ B/s │ B/s vs base │ XORBytes/8Bytes-8 142.8Mi ± 0% 145.9Mi ± 0% +2.19% (p=0.000 n=10) XORBytes/128Bytes-8 1.840Gi ± 0% 1.859Gi ± 0% +1.05% (p=0.000 n=10) XORBytes/2048Bytes-8 3.979Gi ± 0% 5.925Gi ± 0% +48.89% (p=0.000 n=10) XORBytes/8192Bytes-8 879.1Mi ± 35% 1010.2Mi ± 13% ~ (p=0.165 n=10) XORBytes/32768Bytes-8 797.9Mi ± 21% 882.8Mi ± 31% +10.64% (p=0.029 n=10) XORBytesAlignment/8Bytes0Offset-8 147.5Mi ± 0% 140.8Mi ± 0% -4.50% (p=0.000 n=10) XORBytesAlignment/8Bytes1Offset-8 148.1Mi ± 1% 142.5Mi ± 0% -3.77% (p=0.000 n=10) XORBytesAlignment/8Bytes2Offset-8 148.6Mi ± 1% 142.4Mi ± 0% -4.15% (p=0.000 n=10) XORBytesAlignment/8Bytes3Offset-8 150.0Mi ± 0% 142.4Mi ± 0% -5.04% (p=0.000 n=10) XORBytesAlignment/8Bytes4Offset-8 147.8Mi ± 0% 140.8Mi ± 0% -4.75% (p=0.000 n=10) XORBytesAlignment/8Bytes5Offset-8 148.4Mi ± 1% 142.6Mi ± 0% -3.87% (p=0.000 n=10) XORBytesAlignment/8Bytes6Offset-8 149.4Mi ± 1% 142.7Mi ± 0% -4.45% (p=0.000 n=10) XORBytesAlignment/8Bytes7Offset-8 150.1Mi ± 0% 142.5Mi ± 0% -5.05% (p=0.000 n=10) XORBytesAlignment/128Bytes0Offset-8 1.872Gi ± 0% 1.805Gi ± 0% -3.59% (p=0.000 n=10) XORBytesAlignment/128Bytes1Offset-8 1.042Gi ± 0% 1.768Gi ± 0% +69.65% (p=0.000 n=10) XORBytesAlignment/128Bytes2Offset-8 1.047Gi ± 0% 1.768Gi ± 0% +68.80% (p=0.000 n=10) XORBytesAlignment/128Bytes3Offset-8 1.040Gi ± 0% 1.771Gi ± 0% +70.27% (p=0.000 n=10) XORBytesAlignment/128Bytes4Offset-8 1.090Gi ± 0% 1.767Gi ± 0% +62.08% (p=0.000 n=10) XORBytesAlignment/128Bytes5Offset-8 1.077Gi ± 0% 1.771Gi ± 1% +64.41% (p=0.000 n=10) XORBytesAlignment/128Bytes6Offset-8 1.083Gi ± 0% 1.767Gi ± 1% +63.17% (p=0.000 n=10) XORBytesAlignment/128Bytes7Offset-8 1.078Gi ± 0% 1.768Gi ± 0% +64.07% (p=0.000 n=10) XORBytesAlignment/2048Bytes0Offset-8 3.987Gi ± 0% 5.684Gi ± 0% +42.55% (p=0.000 n=10) XORBytesAlignment/2048Bytes1Offset-8 3.601Gi ± 0% 5.459Gi ± 0% +51.61% (p=0.000 n=10) XORBytesAlignment/2048Bytes2Offset-8 3.604Gi ± 0% 5.453Gi ± 0% +51.31% (p=0.000 n=10) XORBytesAlignment/2048Bytes3Offset-8 3.600Gi ± 0% 5.457Gi ± 0% +51.56% (p=0.000 n=10) XORBytesAlignment/2048Bytes4Offset-8 3.635Gi ± 0% 5.456Gi ± 0% +50.10% (p=0.000 n=10) XORBytesAlignment/2048Bytes5Offset-8 3.627Gi ± 0% 5.455Gi ± 0% +50.39% (p=0.000 n=10) XORBytesAlignment/2048Bytes6Offset-8 3.632Gi ± 0% 5.454Gi ± 0% +50.14% (p=0.000 n=10) XORBytesAlignment/2048Bytes7Offset-8 3.626Gi ± 0% 5.453Gi ± 0% +50.39% (p=0.000 n=10) geomean 881.0Mi 1.097Gi +27.51% Change-Id: Id7f9d87fe1ea39aa91ea7d3fd1ba20737f0dda3c Reviewed-on: https://go-review.googlesource.com/c/go/+/649657 Reviewed-by: Julian Zhu <jz531210@gmail.com> Reviewed-by: Carlos Amedee <carlos@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2026-01-26cmd/compile/internal/reflectdata: fix divide by zero for zero-size array ↵fumiyanokesinn
elements When generating equality signatures for arrays with zero-size ASPECIAL elements (e.g., [3]struct{_ [0]float64}), the compiler crashed with a divide by zero error when computing the loop unroll factor. Skip comparison code generation for zero-size elements since they need no comparison. Fixes #77303 Change-Id: Ib432cfece22b1cb714de4f0a0b0d1a2d89bb0d33 Reviewed-on: https://go-review.googlesource.com/c/go/+/738841 Reviewed-by: Cherry Mui <cherryyz@google.com> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Keith Randall <khr@google.com>
2026-01-26doc/go1.27: document macOS requirementsDmitri Shuralyov
For #75836. Change-Id: I07f607178fadbfec95459b2a446f58ae3c5e8932 Reviewed-on: https://go-review.googlesource.com/c/go/+/739380 Reviewed-by: Carlos Amedee <carlos@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2026-01-26README.vendor: document release cycle considerationsDmitri Shuralyov
Write down a few more things relevant to the process of maintaining the vendor directory for the std and cmd modules. This includes the import path of the package containing a tree consistency check, and some considerations regarding the Go release cycle. Also mention the updatestd command with enough context so that it's clear that it is okay to either use it to update everything at once, or instead update specific modules with individual 'go get' calls, whichever is a better fit for the task at hand. For #31806. For #36905. Change-Id: I37d391c557d6cf6ebf2751d71ab9c8f7c10d922d Reviewed-on: https://go-review.googlesource.com/c/go/+/739301 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Ian Alexander <jitsu@google.com> Reviewed-by: Damien Neil <dneil@google.com> TryBot-Bypass: Dmitri Shuralyov <dmitshur@golang.org>
2026-01-26cmd/pprof: update vendored github.com/google/pprofDmitri Shuralyov
Pull in the latest published version of github.com/google/pprof as part of the continuous process of keeping Go's dependencies up to date. For #36905. [git-generate] cd src/cmd go get github.com/google/pprof@v0.0.0-20260115054156-294ebfa9ad83 go mod tidy go mod vendor Change-Id: Ife3c2d40fa9c34e69cdde27b5c7846e499094abf Reviewed-on: https://go-review.googlesource.com/c/go/+/739300 Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Florian Lehner <lehner.florian86@gmail.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
2026-01-26internal/reflectlite: remove unused codekhr@golang.org
Change-Id: I87ae45657a9bae85b0fbf52692f15552a2987847 Reviewed-on: https://go-review.googlesource.com/c/go/+/738941 Reviewed-by: Junyang Shao <shaojunyang@google.com> Reviewed-by: Keith Randall <khr@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-01-26cmd/compile: reduce lock/scheduler contentionDaniel Morsing
During the parallel section of compilation, we limit the amount of parallelism to prevent scheduler churn. We do this with a worker scheduler, but it does not have insight on when a compilation is blocked due to lock contention. The symbol table was protected with a lock. While most lookups were quick lock->read->unlock affairs, sometimes there would be initialization logic involved. This caused every lookup to stall, waiting for init. Since our worker scheduler couldn't see this, it would not launch new goroutine to "cover" the gap. Fix by splitting the symbol lock into 2 cases, initialization and lookup. If symbols need initialization simultaneously, they will wait for each other, but the common case of looking up a symbol will be handled by a syncmap. In practice, I have yet to see this lock being blocked on. Additionally, get rid of the scheduler goroutine and have each compilation goroutine grab work from a central queue. When multiple compilations finished at the same time, the work scheduler would sometime not get run immediately. This ended up starving the system of work. These 2 changes together cuts -1.37% off the build time of typescriptgo on systems with a lot of cores (specifically, the c3h88 perf builder). Updates #73044. Change-Id: I6d4b3be56fd00a4fdd4df132bcbd52e4b2a3e91f Reviewed-on: https://go-review.googlesource.com/c/go/+/724623 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> Auto-Submit: Keith Randall <khr@golang.org>
2026-01-26go/scanner: clear all fields after Scanner reuseMateusz Poliwczak
We were missing s.nlPos = token.NoPos in Init, but while we are here let's make it less likely to hit this it in future. Change-Id: Ief4c0ba2cf97bc556d901eabc8e172406a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/738680 Reviewed-by: Carlos Amedee <carlos@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Alan Donovan <adonovan@google.com>
2026-01-23cmd/compile: simplify AlgType usageKeith Randall
Only walk needs to distinguish different sizes of AMEM. Move the size-distinguishing AlgType there. Change-Id: I0a725b5bd13795a623b3668325f1068579abd340 Reviewed-on: https://go-review.googlesource.com/c/go/+/727461 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Carlos Amedee <carlos@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-01-23cmd/compile: simplify array parsing in equality signaturesKeith Randall
Change-Id: I166586a1f75165cd17df371f9af7cd5b6b3ddc32 Reviewed-on: https://go-review.googlesource.com/c/go/+/727502 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2026-01-23cmd/compile: clean up eq and hash implementationsKeith Randall
Use unsafe.Pointer instead of *any as the argument type. Now that we're using signatures, we don't have exact types so we might as well use unsafe.Pointer everywhere. Simplify hash function choice a bit. Change-Id: If1a07091031c4b966fde3a1d66295a04fd5a838c Reviewed-on: https://go-review.googlesource.com/c/go/+/727501 Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.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@google.com>
2026-01-23cmd/compile: use equality signatures in hash function generationKeith Randall
There aren't a huge number of generated hash functions, so this probably won't save a whole lot of memory. But it means we can clean up a bunch of code by basing equality and hashing on the same underlying infrastructure. Change-Id: I36ed1e49044fecb33120d8736f1c0403a4a2554e Reviewed-on: https://go-review.googlesource.com/c/go/+/727500 Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-01-23cmd/compile: reorg equality functions a bitKeith Randall
Use signature for closure name instead of type. Use signature instead of type to decide to use a runtime builtin comparator. Remove trailing skips from signatures. Change-Id: I73b2dcd3c6e2f1b2857985e14c24b290941b3ca3 Reviewed-on: https://go-review.googlesource.com/c/go/+/725604 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Keith Randall <khr@google.com>
2026-01-23cmd/compile: redo how equality functions are generatedkhr@golang.org
Instead of generating an equality function for each type that needs it, generate one per "signature". A "signature" is a summary of the comparisons needed to check a type for equality. For instance, the type type S struct { i int32 j uint32 s string e error } Will have the signature "M8SI". M8 = 8 bytes of regular memory S = string I = nonempty interface This way, potentially many types that have the same signature can share the same equality function. The number of generated equality functions in the go binary is reduced from 634 to 286. The go binary is ~1% smaller. The generation of equality functions gets simpler (particularly, how we do inlining of sub-types, unrolling, etc.) and the generated code is probably a bit more efficient. The new function names are kind of weird, but will seldom show up for users. They will appear in cpu profiles, and in tracebacks in the situation where comparisons panic because an interface somewhere in the type being compared contains an uncomparable type (e.g. a slice). Note that this CL only affects generated comparison functions. It does not generally affect generated code for == (except when that code decides to call a comparison function as a subtask). Maybe a TODO for the future. Update #6853 Change-Id: I202bd6424cb6bf7c745a62c9603d4f01dc1a1fc8 Reviewed-on: https://go-review.googlesource.com/c/go/+/725380 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Keith Randall <khr@google.com>
2026-01-23encoding/json: fix typo in package doc.David Symonds
Change-Id: Id5520757e4d73e56e533e4de4f5f303105c4339e Reviewed-on: https://go-review.googlesource.com/c/go/+/738180 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: David Symonds <dsymonds@golang.org> Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: David Symonds <dsymonds@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Joseph Tsai <joetsai@digital-static.net> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-01-23cmd/compile: fix loopvar version detection with line directivesxieyuschen
The Go loop variable semantics changed in Go 1.22: loop variables are now created per-iteration instead of per-loop. The compiler decides which semantics to use based on the Go version in go.mod. When go.mod specifies go 1.21 and the code is built with a Go 1.22+ compiler, the per-loop(compatible behavior) semantics should be used. However, when a line directive is present in the source file, go.mod 1.21 and go1.22+ compiler outputs a per-iteration semantics. For example, the file below wants output 333 but got 012. -- go.mod -- module test go 1.21 -- main.go -- //line main.go:1 func main() { var fns []func() for i := 0; i < 3; i++ { fns = append(fns, func() { fmt.Print(i) }) } for _, fn := range fns { fn() } } The distinctVars function uses stmt.Pos().Base() to look up the file version in FileVersions. Base() returns the file name after line directives are applied (e.g., "main.go" for "//line main.go:1"), not the actual source file path. This causes the version lookup to fail for files with line directives. This CL fixes the bug by using stmt.Pos().FileBase() instead. FileBase() returns the actual file path before line directives are applied, ensuring the correct version information is retrieved from the original source file. Fixes: #77248 Change-Id: Idacc0816d112ee393089262468a02acfe40e4b72 Reviewed-on: https://go-review.googlesource.com/c/go/+/737820 Reviewed-by: Keith Randall <khr@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
2026-01-23runtime: speed up cheaprand and cheaprand64Gavin Lam
The current cheaprand performs 128-bit multiplication on 64-bit numbers and truncate the result to 32 bits, which is inefficient. A 32-bit specific implementation is more performant because it performs 64-bit multiplication on 32-bit numbers instead. The current cheaprand64 involves two cheaprand calls. Implementing it as 64-bit wyrand is significantly faster. Since cheaprand64 discards one bit, I have preserved this behavior. The underlying uint64 function is made available as cheaprandu64. │ old │ new │ │ sec/op │ sec/op vs base │ Cheaprand-8 1.358n ± 0% 1.218n ± 0% -10.31% (n=100) Cheaprand64-8 2.424n ± 0% 1.391n ± 0% -42.62% (n=100) Blocksampled-8 8.347n ± 0% 2.022n ± 0% -75.78% (n=100) Fixes #77149 Change-Id: Ib0b5da4a642cd34d0401b03c1d343041f8230d11 GitHub-Last-Rev: 549d8d407e2bbcaecdee0b52cbf3a513dda637fb GitHub-Pull-Request: golang/go#77150 Reviewed-on: https://go-review.googlesource.com/c/go/+/735480 Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-01-23cmd/compile: on amd64 use 32bits copies for 64bits copies of 32bits valuesJorropo
Fixes #76449 This saves a single byte for the REX prefix per OpCopy it triggers on. Change-Id: I1eab364d07354555ba2f23ffd2f9c522d4a04bd0 Reviewed-on: https://go-review.googlesource.com/c/go/+/731640 Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Auto-Submit: Jorropo <jorropo.pgm@gmail.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-01-23cmd/compile: cleanup noLimit in proveJorropo
- make it immutable - calculate it rather than using hardcoded value (it all is inlined and constant folded away into noLimit's callers) Change-Id: Ica12442df4d03e99123e62c0fe561c1078e35d75 Reviewed-on: https://go-review.googlesource.com/c/go/+/727181 Auto-Submit: Jorropo <jorropo.pgm@gmail.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-01-23cmd/compile: improve PopCount's limits modeling and add bruteforce testsJorropo
This make PopCount perfect within the limitations limits can represent. Change-Id: Ia52e5d79064ad8109117f009c5390a6eba8ccd98 Reviewed-on: https://go-review.googlesource.com/c/go/+/727782 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Carlos Amedee <carlos@golang.org> Auto-Submit: Jorropo <jorropo.pgm@gmail.com> Reviewed-by: Keith Randall <khr@google.com>
2026-01-23cmd/compile: add limits bruteforce tests for bitlenJorropo
This ensure BitLen is perfect within the limitations limits can represent. Change-Id: I5c1770b4a9f6408fd68fe77b4ef2b2cdd52e26cb Reviewed-on: https://go-review.googlesource.com/c/go/+/727781 Reviewed-by: Keith Randall <khr@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Jorropo <jorropo.pgm@gmail.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
2026-01-23cmd/compile: improve Ctz's limits modeling and add bruteforce testsJorropo
This make Ctz perfect within the limitations limits can represent. Change-Id: I1e596d8d01892d1b70031cf03cecc487ce147b38 Reviewed-on: https://go-review.googlesource.com/c/go/+/727780 Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Keith Randall <khr@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Jorropo <jorropo.pgm@gmail.com>
2026-01-23cmd/compile: cleanup isUnsignedPowerOfTwoJorropo
Merge the signed and unsigned generic functions. The only implementation difference between the two is: n > 0 vs n != 0 check. For unsigned numbers n > 0 == n != 0 and we infact optimize the first to the second. Change-Id: Ia2f6c3e3d4eb098d98f85e06dc2e81baa60bad4e Reviewed-on: https://go-review.googlesource.com/c/go/+/726720 Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Carlos Amedee <carlos@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-01-23net: fix some ineffectual assignments reported by ineffassignLin Lin
Updates #35136 Change-Id: I5422a50dde51c0a57f135c83f4963053285a9bc2 GitHub-Last-Rev: 6db1a88da60fce3e4fd6697d5db75d55d53b2b49 GitHub-Pull-Request: golang/go#76704 Reviewed-on: https://go-review.googlesource.com/c/go/+/727080 Reviewed-by: Florian Lehner <lehner.florian86@gmail.com> Reviewed-by: Carlos Amedee <carlos@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Jorropo <jorropo.pgm@gmail.com> Reviewed-by: Michael Pratt <mpratt@google.com>
2026-01-23all: update vendored dependenciesNicholas S. Husin
This CL does the following: 1. Bundles up golang.org/x/net/internal/httpsfv since h2_bundle.go now relies on it. 2. Modifies h2_bundle.go import mapping to account for httpsfv package. 3. Updates all vendored dependencies using golang.org/x/build/cmd/updatestd. For #75500 Change-Id: Ia2f41ad606092fe20b62f946266190502b146977 Reviewed-on: https://go-review.googlesource.com/c/go/+/738621 Reviewed-by: Nicholas Husin <husin@google.com> Reviewed-by: Damien Neil <dneil@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-01-23internal/buildcfg: disable sizespecializedmalloc by defaultMichael Anthony Knyszek
We're finding some regressions in overall icache footprint at scale and we should figure out how to deal with those before rolling this out to everybody. Change-Id: I98e792db31712bf64575d76dfeafedb48898f76a Reviewed-on: https://go-review.googlesource.com/c/go/+/738780 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com> Auto-Submit: Michael Knyszek <mknyszek@google.com>
2026-01-23cmd/compile: fix typos in types2 api_test.gogoto1134
Change-Id: Ifee1b0f590ebb6671efd61a289c8884a225f5d6b GitHub-Last-Rev: 175ae95847b0108949459b881c2cd2144e74353e GitHub-Pull-Request: golang/go#76782 Reviewed-on: https://go-review.googlesource.com/c/go/+/728980 Reviewed-by: Jorropo <jorropo.pgm@gmail.com> Auto-Submit: Jorropo <jorropo.pgm@gmail.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>
2026-01-23cmd/go/internal/vcs: support git worktreesJosh Bleecher Snyder
Fixes golang/go#58218 Change-Id: Ia155b26514557cf822caf37e727e5a410b0a36a6 Reviewed-on: https://go-review.googlesource.com/c/go/+/736260 Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Junyang Shao <shaojunyang@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2026-01-23go/types, types: flip field/method selection logic inside out (cleanup)Robert Griesemer
By selecting on *Var/*Func first, the field/method selection logic becomes a bit cleaner, clearer, and a little bit simpler. No functional changes. Change-Id: I9860f98d52779b0f7ce4484ea77e74a3667d9e6b Reviewed-on: https://go-review.googlesource.com/c/go/+/738080 Reviewed-by: Alan Donovan <adonovan@google.com> Commit-Queue: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Robert Griesemer <gri@google.com>
2026-01-23cmd/compile: avoid extending when already sufficiently shifted on loong64Xiaolin Zhao
This reduces 744 instructions from the go toolchain binary on loong64. file before after Δ % asm 599282 599222 -60 -0.0100% cgo 513606 513534 -72 -0.0140% compile 2939250 2939146 -104 -0.0035% cover 564136 564056 -80 -0.0142% fix 895622 895546 -76 -0.0085% link 759460 759376 -84 -0.0111% preprofile 264960 264916 -44 -0.0166% vet 869964 869888 -76 -0.0087% go 1712990 1712890 -100 -0.0058% gofmt 346416 346368 -48 -0.0139% total 9465686 9464942 -744 -0.0079% Change-Id: I32dfa7506d0458ca0b6de83b030c330cd2b82176 Reviewed-on: https://go-review.googlesource.com/c/go/+/725720 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> Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Keith Randall <khr@google.com>
2026-01-23math/pow10: remove overlapping boundary (n=0)mohanson
Both the first and second conditions include n=0, creating an implicit logic that relies on order of evaluation. Change-Id: Iefbc25a676242fabf272203a3e845363585bff56 Reviewed-on: https://go-review.googlesource.com/c/go/+/730060 Reviewed-by: Robert Griesemer <gri@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Robert Griesemer <gri@google.com>
2026-01-23cmd/compile/internal/pgo: error parsing profile (for pgo) after scalingRyan Diep
If a valid profile is scaled such that the samples/counts become 0, an empty graph in which the compiler complain that we never saw a start line since the graph has no nodes which is a misleading error message. src/cmd/internal/pgo/pprof.go was modified to check if the graph is empty return an empty profile. GitHub-Pull-Request: golang/go#73640 Change-Id: If3f7ab8af6fcf77b2e29ae1df154f87bee377ab0 Reviewed-on: https://go-review.googlesource.com/c/go/+/725120 Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org> Auto-Submit: Michael Pratt <mpratt@google.com>
2026-01-23runtime: remove logical stack sentinel for runtime lock stacksNick Ripley
When CL 533258 added frame pointer support for the block and mutex profiles, it deferred skipping/inline expansion, similar to the execution tracer. The first frame indicated whether this expansion was needed by holding either the number of frames to skip (implying inline expansion) or the logicalStackSentinel placeholder to indicate that no extra handling is needed. However, CL 598515 switched to doing the skipping/inline expansion at sample time. After this, the sentinel value is unused. This CL removes the sentinel from runtime lock profiling, correcting an oversight from that CL. This didn't cause any problems since post-processing would just ignore the bogus sentinel value; this is just a cleanup. Change-Id: Idbec11f57ac7a57426cd8a064782c4fe6a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/726040 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
2026-01-23math: use shared signMask constantmohanson
In abs.go and copysign.go, magic numbers and local constants are used for the sign bit mask (1 << 63), even though a shared constant signMask already exists in bits.go. Change-Id: Ic3aeb9b52674538443cbe074acfeb373a3c74a8e Reviewed-on: https://go-review.googlesource.com/c/go/+/732060 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Robert Griesemer <gri@google.com>
2026-01-23runtime: remove unused mutexevent linknameNick Ripley
CL 29650 added a sync.event linkname for mutexevent, but that does not appear to have ever been used. This linkname isn't in the "hall of shame", so we can just remove it. Change-Id: I778b53ca089b5afda6c6074be9e43e3a6a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/736220 Reviewed-by: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com>
generated by cgit v1.3 (git 2.53.0) at 2026-04-15 03:24:45 +0000