Cherry Mui [Mon, 8 Dec 2025 17:14:24 +0000 (12:14 -0500)]
[dev.simd] cmd/compile: zero only low 128-bit of X15
Zeroing the upper part of X15 may make the CPU think it is
"dirty" and slow down SSE operations. For now, just not zeroing
the upper part, and construct a zero value on the fly if we need
a 256- or 512-bit zero value. Maybe VZEROUPPER works better than
explicitly zeroing X15, but we need to evaluate.
Long term, we probably want to move more things from SSE to AVX.
This essentially undoes CL 698237 and CL 698238, except keeping
using X15 for 128-bit zeroing for SIMD.
Change-Id: I1564e6332c4c57f9721397c92c7c734c5497534c
Reviewed-on: https://go-review.googlesource.com/c/go/+/728240
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com>
David Chase [Thu, 4 Dec 2025 22:51:04 +0000 (17:51 -0500)]
[dev.simd] simd: add carryless multiply
now with comments, and also a test.
choice of data types, method names, etc, are all up for comment.
It's NOT commutative, because of the immediate operand (unless we
swap the bits of the immediate).
qmuntal [Wed, 3 Dec 2025 11:32:15 +0000 (12:32 +0100)]
crypto/hpke: remove unused hybridKEM field
hybridKEM.pqGenerateKey is not used anywhere. Having it around
is confusing, as it suggests that the mlkem seed is generated within
the mlkem package, when it is not.
Change-Id: Ie0bdb79d6b774db7b21dfff2b966452463f1ce08
Reviewed-on: https://go-review.googlesource.com/c/go/+/726260 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> Reviewed-by: Roland Shoemaker <roland@golang.org>
Ian Lance Taylor [Wed, 3 Dec 2025 01:01:57 +0000 (17:01 -0800)]
cmd/link: don't update offset of existing ELF section name
Fixes #76656
Change-Id: If2e823ba1577700af00f5883e4ea5c139e4749c1
Reviewed-on: https://go-review.googlesource.com/c/go/+/726100 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Michael Stapelberg <stapelberg@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Robert Griesemer [Tue, 2 Dec 2025 19:58:29 +0000 (11:58 -0800)]
doc: pre-announce removal of gotypesalias and asynctimerchan GODEBUG flags
This announcement follows the policy outlined in #76163.
For #76472.
Change-Id: I4299e7f474e314810883dc4f50be6afba8c3e3e7
Reviewed-on: https://go-review.googlesource.com/c/go/+/726020
Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Alan Donovan <adonovan@google.com> Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Robert Griesemer [Tue, 2 Dec 2025 22:32:13 +0000 (14:32 -0800)]
spec: remove restriction on channel element types for close built-in (bug fix)
The spec states that if the argument type for close is a type parameter,
it's type set must only contain channels and they must all have the same
element type. This latter requirement (all must have the same element
type) was never enforced by the compiler, nor is it important for
correctness or required by the implementation.
This change removes this requirement also in the spec and thus
documents what was always (since 1.18) the case.
Fixes #74034.
Change-Id: If65d50bfb581b7f37999413088d3d3b1820e054a
Reviewed-on: https://go-review.googlesource.com/c/go/+/725923
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Robert Findley <rfindley@google.com>
Keith Randall [Tue, 2 Dec 2025 22:22:34 +0000 (14:22 -0800)]
doc: mention stack allocation of slices
Very similar to last release's note.
Change-Id: Ie7afe21d98cee1c9718e53b20e8af8ee18504bb9
Reviewed-on: https://go-review.googlesource.com/c/go/+/725921 Reviewed-by: Dmitri Shuralyov <dmitshur@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>
Auto-Submit: Keith Randall <khr@golang.org>
Devon Mar [Tue, 25 Nov 2025 07:38:09 +0000 (07:38 +0000)]
net: parse addresses without separators in ParseMac
IEEE EUI guidelines states that "an EUI-48 can be represented in the IEEE RA
hexadecimal (hex) form with the octets separated by hyphens, or as a pure
base-16 numerical representation without hyphens"
(https://standards.ieee.org/wp-content/uploads/import/documents/tutorials/eui.pdf p.9).
The latter form is used in Azure Instance Metadata Service
(https://github.com/Azure/azure-container-networking/pull/4122) among others.
Fixes #66682
Change-Id: Id66c23d50ebb1fed1f3bdb5cf3822a8fd60b886d
GitHub-Last-Rev: 77900cc1a68cb535b685a63cf84b5413b480df2c
GitHub-Pull-Request: golang/go#76387
Reviewed-on: https://go-review.googlesource.com/c/go/+/722720
Auto-Submit: Damien Neil <dneil@google.com> 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>
khr@golang.org [Mon, 1 Dec 2025 18:32:23 +0000 (10:32 -0800)]
cmd/compile: more generated equality function tests
Change-Id: I05cd103ea8d8bbee0ad907ff3e594de273d49e86
Reviewed-on: https://go-review.googlesource.com/c/go/+/725600 Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Keith Randall <khr@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>
Nicholas S. Husin [Mon, 24 Nov 2025 19:56:23 +0000 (14:56 -0500)]
crypto/x509: prevent HostnameError.Error() from consuming excessive resource
Constructing HostnameError.Error() takes O(N^2) runtime due to using a
string concatenation in a loop. Additionally, there is no limit on how
many names are included in the error message. As a result, a malicious
attacker could craft a certificate with an infinite amount of names to
unfairly consume resource.
To remediate this, we will now use strings.Builder to construct the
error message, preventing O(N^2) runtime. When a certificate has 100 or
more names, we will also not print each name individually.
Thanks to Philippe Antoine (Catena cyber) for reporting this issue.
Fixes #76445
Fixes CVE-2025-61729
Change-Id: I6343776ec3289577abc76dad71766c491c1a7c81
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/3000 Reviewed-by: Neal Patel <nealpatel@google.com> Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/725920 Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Bypass: Dmitri Shuralyov <dmitshur@golang.org>
Robert Griesemer [Thu, 20 Nov 2025 22:05:27 +0000 (14:05 -0800)]
spec: more precise prose for built-in function new
1) explain new(type) (simpler) before new(expr) (more complicated)
2) for new(expr), explain what happens when expr is an untyped bool
3) explain that new(nil) is not permitted
4) streamline examples slightly
Fixes #76122.
Change-Id: I5ddb26bd88241b4b2b9aa9b532a62f7861c2341c
Reviewed-on: https://go-review.googlesource.com/c/go/+/722482
Auto-Submit: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Robert Griesemer <gri@google.com> Reviewed-by: Alan Donovan <adonovan@google.com>
Commit-Queue: Robert Griesemer <gri@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Damien Neil [Mon, 1 Dec 2025 20:28:19 +0000 (12:28 -0800)]
net/http: deflake TestClientConnReserveAndConsume
This test includes an assertion that a client conn's state hook
is called exactly once, but some of the test cases can result in
two events occurring: A request completes and a connection closes.
Change the assertion to just check that the hook is called
at least once.
Fixes #76480
Change-Id: Ie1438581b072b10623eb3d5fe443294a639c9853
Reviewed-on: https://go-review.googlesource.com/c/go/+/725601
Commit-Queue: Damien Neil <dneil@google.com>
Auto-Submit: Damien Neil <dneil@google.com> Reviewed-by: Nicholas Husin <husin@google.com> Reviewed-by: Nicholas Husin <nsh@golang.org>
TryBot-Bypass: Damien Neil <dneil@google.com>
Both CL 723241 and CL 723581 added identical definitions.
Change-Id: I6a6a636c9e5f8c9080b9389ebf9d3f10305d79ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/725661
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Auto-Submit: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
胡玮文 [Sun, 23 Nov 2025 18:29:24 +0000 (02:29 +0800)]
internal/runtime/cgroup: lineReader fuzz test
The original unit test is converted to a fuzz test, to be more confident
on future refactors. All sub-tests are converted to seed corpus.
Change-Id: Id0c167ed47729a00ea0614d17746ddcc284697d3
Reviewed-on: https://go-review.googlesource.com/c/go/+/723581
Auto-Submit: Michael Pratt <mpratt@google.com>
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>
Ian Lance Taylor [Fri, 28 Nov 2025 22:34:06 +0000 (14:34 -0800)]
debug/elf: correct case of DWARF in comment
Change-Id: I5b80b0e3e50fafdb732c732cdae6e2756d919d20
Reviewed-on: https://go-review.googlesource.com/c/go/+/725360 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Mark Freeman <markfreeman@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>
Brad Fitzpatrick [Wed, 26 Nov 2025 18:11:41 +0000 (10:11 -0800)]
doc/next: clean up some Go 1.26 release notes
The Var.Kind stuff was in Go 1.25.
And the net additions were in the wrong tense and didn't have links.
Change-Id: Ie710e1d41c714fe627a3a21a5afb6b7f78301f68
Reviewed-on: https://go-review.googlesource.com/c/go/+/724780 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Mark Freeman <markfreeman@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
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-20251114195745-4902fdda35c8
go mod tidy
go mod vendor
Change-Id: Id26eb632f637fb2c602d87cb83fdff7f099934ce
Reviewed-on: https://go-review.googlesource.com/c/go/+/725500
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
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>
Dmitri Shuralyov [Mon, 1 Dec 2025 15:32:57 +0000 (10:32 -0500)]
all: update vendored dependencies
The Go 1.26 code freeze has recently started. This is a time to update
all golang.org/x/... module versions that contribute packages to the
std and cmd modules in the standard library to latest master versions.
For #36905.
[git-generate]
go install golang.org/x/build/cmd/updatestd@latest
go install golang.org/x/tools/cmd/bundle@latest
updatestd -goroot=$(pwd) -branch=master
Change-Id: I39c68d4c36d0c83ac07c3cda3c4d042bb32a9624
Reviewed-on: https://go-review.googlesource.com/c/go/+/725480
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@golang.org> Reviewed-by: Alan Donovan <adonovan@google.com>
cmd$ go get golang.org/x/tools@1ad6f3d
cmd$ GOWORK=off go mod tidy
cmd$ GOWORK=off go mod vendor
This merge pulls in the following commits, which include several fixes
needed for go1.26, marked by an asterisk. None of the unmarked commits
affects vendored packages, so it is safe (and simpler) to merge rather
than cherrypick via a release branch.
tools$ git log --oneline 68724afed209...1ad6f3d02713
*4a3f2f81eb go/analysis/passes/printf: panic when function literal is assigned to the blank identifier
*d5d7d21fe7 gopls/internal/cache: fix %q verb use with wrong type
*92a094998a go/analysis/passes/modernize: rangeint: handle usages of loop label
*ffbdcac342 go/analysis/passes/modernize: stditerators: add reflect iters
*2e3e83a050 internal/refactor/inline: preserve local package name used by callee d32ec34454 gopls/internal/protocol/generate: move injections to tables.go 98d172d8bd gopls/internal/protocol: add form field in type CodeAction e1317381e4 go/packages: suppress test on (e.g.) wasm
*e31ed53b51 internal/stdlib: regenerate
*6f1f89817d internal/analysis/driverutil: include end positions in -json output 7839abf5e8 gopls/internal/metadata: document when Module can be nil 98aa9a7d0b gopls/internal/cache: make unimported completions deterministic 4c5faddb0f internal/modindex: unescape import paths c2c902c441 gopls/completion: avoid nil dereference
*4bf3169c8a go/analysis/passes/modernize: waitgroup: highlight "go func" part ba5189b063 gopls/internal/template: fix printf mistake in test
*a7d12506a0 go/analysis/passes/printf: clarify checkForward c7a1a29f93 internal/pkgbits: fix printf mistake in test af205c0a29 gopls/doc/release/v0.21.0.md: tweaks
Change-Id: I23c991987afeb2db3e0f98f76f8ee5000c8a6e02
Reviewed-on: https://go-review.googlesource.com/c/go/+/725460
Auto-Submit: Alan Donovan <adonovan@google.com>
TryBot-Bypass: Alan Donovan <adonovan@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Commit-Queue: Alan Donovan <adonovan@google.com>
debug/elf: make check for empty symbol section consistent for 64-bit and 32-bit binaries
The check for whether a binary's symbols section is empty is
inconsistent across the 32-bit and 64-bit flows.
Change-Id: I1abc235320a53cf957cfb83c9e7bcad6e52bc529
GitHub-Last-Rev: f264915ca2964ad8f34ce1deee4f42c2f9dc21bf
GitHub-Pull-Request: golang/go#75334
Reviewed-on: https://go-review.googlesource.com/c/go/+/702195
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Keith Randall <khr@google.com>
Cuong Manh Le [Fri, 28 Nov 2025 10:19:42 +0000 (17:19 +0700)]
cmd/compile: avoid unnecessary interface conversion in bloop
Fixes #76482
Change-Id: I076568d8ae92ad6c9e0a5797cfe5bbfb615f63d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/725180
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Daniel Morsing [Thu, 27 Nov 2025 06:45:20 +0000 (06:45 +0000)]
runtime/secret: reorganize tests to fix -buildmode=shared
The testing assembly methods had a linkname that was implicitly
satisfied during the regular build but not there during the shared
build. Fix by moving the testing routine into the package itself.
For good measure, section off the assembly files from the non-experiment
build. Should prevent further build failures as we work on this.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-linux-arm64-longtest
Change-Id: I2b45668e44641ae7880ff14f6402d982c7eaedd7
Reviewed-on: https://go-review.googlesource.com/c/go/+/724001 Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org> 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>
胡玮文 [Sat, 22 Nov 2025 03:00:47 +0000 (11:00 +0800)]
internal/runtime/cgroup: stricter unescapePath
8 and 9 in escape sequence is invalid now, it should be octal.
Escape sequence larger than \377 is invalid now, it does not fit one
byte.
Change-Id: I3fdebce1d054c44919f0e66a33c778b5a2b099e2
Reviewed-on: https://go-review.googlesource.com/c/go/+/723242 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
胡玮文 [Fri, 21 Nov 2025 17:44:14 +0000 (01:44 +0800)]
internal/runtime/cgroup: fix path on non-root mount point
We should trim the mount root (4th field in /proc/self/mountinfo) from
cgroup path read from /proc/self/cgroup before appending it to the mount
point. Non-root mount points are very common in containers with cgroup
v1.
parseCPURelativePath is renamed to parseCPUCgroup, as it is unclear what
it is relative to. cgroups(7) says "This pathname is relative to the
mount point of the hierarchy." It should mean the root of the hierarchy,
and we cannot concat it to arbirary cgroup mount point. So just use the
word cgroup, since it parses /proc/self/cgroup.
It now returns errMalformedFile if the cgroup pathname does not start
with "/", and errPathTooLong if the pathname can't fit into the buffer.
We already rely on this when composing the path, just make this explicit
to avoid incorrect paths.
We now parse cgroup first then parse the mount point accordingly. We
consider the previously read cgroup pathname and version to ensure we
got the desired mount point. The out buffer is reused to pass in the
cgroup, to avoid extra memory allocation.
This should also resolve the race mentioned in the comments, so removing
those comments. If our cgroup changed between the two read syscalls, we
will stick with the cgroup read from /proc/self/cgroup. This is the same
behavior as cgroup change after FindCPU() returns, so nothing special to
comment about now.
parseCPUMount now returns error when the combined path is too long, to
avoid panic or truncation if we got a really long path from mountinfo.
cgrouptest is changed to use dev returned from stat() to detect
filesystem boundary, since we don't return mount point and sub-path
separately now. This also avoid using os.Root since we don't handle
untrusted input here. os.Root is too complex, and the performance is
bad.
Fixes #76390
Change-Id: Ia9cbd7be3e58a2d51caf27a973fbd201dac06afc
Reviewed-on: https://go-review.googlesource.com/c/go/+/723241 Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
Change-Id: I7468b56eb26f14bc809f8f7580535e6562795c62
Reviewed-on: https://go-review.googlesource.com/c/go/+/723300 Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
thepudds [Thu, 20 Nov 2025 19:43:50 +0000 (14:43 -0500)]
io: reduce intermediate allocations in ReadAll and have a smaller final result
Currently, io.ReadAll allocates a significant amount of intermediate
memory as it grows its result slice to the size of the input data.
This CL aims to reduce the allocated memory. Geomean benchstat results
comparing existing io.ReadAll to this CL for a variety of input sizes:
│ old | new vs base │
sec/op 132.2µ 66.32µ -49.83%
B/op 645.4Ki 324.6Ki -49.70%
final-capacity 178.3k 151.3k -15.10%
excess-ratio 1.216 1.033 -15.10%
The corresponding full benchstat results are below. The input data sizes
are a blend of random sizes, power-of-2 sizes, and power-of-10 sizes.
This CL reduces intermediate bytes allocated in io.ReadAll by reading
via a set of slices of exponentially growing size, and then copying
into a final perfectly-sized slice at the end.
The current memory allocations impact real uses. For example, in #50774
two real-world reports were ~60% more bytes allocated via io.ReadAll
compared to an alternate approach, and also a separate report of
~5x more bytes allocated than the input data size of ~5MiB.
Separately, bytes.Buffer.ReadFrom uses a 2x growth strategy, which
usually can beat the pre-existing io.ReadAll on total bytes allocated
but sometimes not (depending on alignment between exact input data size
and growth). That said, bytes.Buffer.ReadFrom usually ends up with
more excess memory used in a larger final result than the current
io.ReadAll (often significantly more).
If we compare bytes.Buffer.ReadFrom to this CL, we also see
better geomean overall results reported with this CL:
(Full corresponding benchstat results comparing this CL vs. bytes.Buffer
are at https://go.dev/play/p/eqwk2BkaSwJ).
One challenge with almost any change of growth strategy for something
widely used is there can be a subset of users that benefited more from
the old growth approach (e.g., based on their data size aligning
particularly well with the old growth), even if the majority of users
on average benefit from the new growth approach.
To help mitigate that, this CL somewhat follows the old read pattern
in its early stages.
Here are the full benchstat results comparing the existing
io.ReadAll vs. this CL. The standard metrics are included, plus
the final result capacity and an excess capacity ratio, which is
the final capacity of the result divided by the input data size (so 1.0
is no excess memory present in the result, though due to
size class rounding the ratio is usually above 1.0 unless the
input data size exactly matches a size class).
We consider smaller reported excess capacity to be better for most
uses given it means the final allocation puts less pressure on the GC
(both in cases when it will almost immediately be garbage in user code,
or if for example the final result is held for multiple GC cycles).
The input data sizes used in the benchmarks:
- Six powers of 10.
- Six powers of 2.
- Ten random sizes between 1KiB and 100MiB (chosen uniformly
on a log scale).
- size=300 (so that we have something below 512, which is the
initial read size).
Finally, the read size in this CL currently grows exponentially
at a 1.5x growth rate. The old approach had its read size grow at
a ~1.25x growth rate once the reads are larger. We could consider
for example using a 1.25x read size growth rate here as well.
There are perhaps some ~mild trade-offs. One benefit might
be something like a ~5% smaller peak live heap contribution
(at the end, when copying into the final result) if we used
a 1.25x read growth instead of 1.5x read growth.
That said, for some systems, larger read sizes can trigger
higher throughput behavior further down the stack or
elsewhere in a system, such as via better read-ahead behavior,
larger transfer sizes, etc.
I've observed this effect in various real-world systems,
including distributed systems as well as for example with
spinning platters (which are still widely used, including
backing various "Internet scale" systems). When the effect
exists, it is usually substantial.
Therefore, my guess is it is better to get to larger read
sizes faster, which is one reason the CL is using 1.5x
read size growth rate instead of 1.25x. Also, for something
like peak live heap contribution, we are already getting
substantial wins in this CL for total heap bytes allocated,
so maybe that is OK.
(I have the actual benchmark in a separate commit, which I can
send later, or I can update this CL if preferred).
Fixes #50774
Updates #74299
Change-Id: I65eabf1d83a00fbdbe42e4c697116955f8251740
Reviewed-on: https://go-review.googlesource.com/c/go/+/722500
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Dave Vasilevsky [Tue, 25 Nov 2025 03:55:45 +0000 (03:55 +0000)]
os: allow direntries to have zero inodes on Linux
Some Linux filesystems have been known to return valid enties with
zero inodes. This new behavior also puts Go in agreement with recent
glibc.
Fixes #76428
Change-Id: Ieaf50739a294915a3ea2ef8c5a3bb2a91a186881
GitHub-Last-Rev: 8f83d009ef0320fd3fe7cf03e55d5d24df57f015
GitHub-Pull-Request: golang/go#76448
Reviewed-on: https://go-review.googlesource.com/c/go/+/724220 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Ian Lance Taylor [Tue, 18 Nov 2025 04:20:26 +0000 (20:20 -0800)]
cmd/link: test that moduledata is in its own section
This is a test for CL 720660.
For #76038
Change-Id: I2f630b738ddb5a9c48e3c5d4374c1e995910541a
Reviewed-on: https://go-review.googlesource.com/c/go/+/721480 Reviewed-by: Cherry Mui <cherryyz@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: David Chase <drchase@google.com>
Ian Lance Taylor [Tue, 18 Nov 2025 02:35:50 +0000 (18:35 -0800)]
cmd/link: test that findfunctab is in gopclntab section
This is a test for CL 719743.
Change-Id: I2d7b9d00d2d4dd63a21ca00f09eb7c9378ec70f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/721461 Reviewed-by: David Chase <drchase@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>
Ian Lance Taylor [Tue, 18 Nov 2025 02:29:42 +0000 (18:29 -0800)]
cmd/link: test that funcdata values are in gopclntab section
This is a test for CL 719440.
For #76038
Change-Id: I8fc55118b3c7dea39a36e04ffb060fcb6150af54
Reviewed-on: https://go-review.googlesource.com/c/go/+/721460 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Ian Lance Taylor [Thu, 13 Nov 2025 21:01:14 +0000 (13:01 -0800)]
cmd/link, runtime, debug/gosym: move pclntab magic to internal/abi
Change-Id: I2d3c41b0e61b994d7b04bd16a791fd226dc45269
Reviewed-on: https://go-review.googlesource.com/c/go/+/720302 Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Ian Lance Taylor [Fri, 7 Nov 2025 20:25:03 +0000 (12:25 -0800)]
cmd/link: build shstrtab from ELF sections
Since before Go 1 the Go linker has handled ELF by first building the
ELF section string table, and then pointing ELF section headers to it.
This duplicates code as sections are effectively created twice,
once with the name and then again with the full section header.
The code duplication also means that it's easy to create unnecessary
section names; for example, every internally linked Go program
currently contains the string ".go.fuzzcntrs" although most do not
have a section by that name.
This CL changes the linker to simply build the section string table
after all the sections are known.
Change-Id: I27ba15b2af3dc1b8d7436b6c409f818aa8e6bfb4
Reviewed-on: https://go-review.googlesource.com/c/go/+/718840 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
thepudds [Tue, 25 Nov 2025 14:57:50 +0000 (09:57 -0500)]
cmd/compile: introduce alias analysis and automatically free non-aliased memory after growslice
This CL is part of a set of CLs that attempt to reduce how much work the
GC must do. See the design in https://go.dev/design/74299-runtime-freegc
This CL updates the compiler to examine append calls to prove
whether or not the slice is aliased.
If proven unaliased, the compiler automatically inserts a call to a new
runtime function introduced with this CL, runtime.growsliceNoAlias,
which frees the old backing memory immediately after slice growth is
complete and the old storage is logically dead.
Two append benchmarks below show promising results, executing up to
~2x faster and up to factor of ~3 memory reduction with this CL.
The approach works with multiple append calls for the same slice,
including inside loops, and the final slice memory can be escaping,
such as in a classic pattern of returning a slice from a function
after the slice is built. (The final slice memory is never freed with
this CL, though we have other work that tackles that.)
An example target for this CL is we automatically free the
intermediate memory for the appends in the loop in this function:
func f1(input []int) []int {
var s []int
for _, x := range input {
s = append(s, g(x)) // s cannot be aliased here
if h(x) {
s = append(s, x) // s cannot be aliased here
}
}
return s // slice escapes at end
}
In this case, the compiler and the runtime collaborate so that
the heap allocated backing memory for s is automatically freed after
a successful grow. (For the first grow, there is nothing to free,
but for the second and subsequent growths, the old heap memory is
freed automatically.)
The new runtime.growsliceNoAlias is primarily implemented
by calling runtime.freegc, which we introduced in CL 673695.
The high-level approach here is we step through the IR starting
from a slice declaration and look for any operations that either
alias the slice or might do so, and treat any IR construct we
don't specifically handle as a potential alias (and therefore
conservatively fall back to treating the slice as aliased when
encountering something not understood).
For loops, some additional care is required. We arrange the analysis
so that an alias in the body of a loop causes all the appends in that
same loop body to be marked aliased, even if the aliasing occurs after
the append in the IR:
func f2() {
var s []int
for i := range 10 {
s = append(s, i) // aliased due to next line
alias = s
}
}
For nested loops, we analyse the nesting appropriately so that
for example this append is still proven as non-aliased in the
inner loop even though it aliased for the outer loop:
func f3() {
for range 10 {
var s []int
for i := range 10 {
s = append(s, i) // append using non-aliased slice
}
alias = s
}
}
A good starting point is the beginning of the test/escape_alias.go file,
which starts with ~10 introductory examples with brief comments that
attempt to illustrate the high-level approach.
For more details, see the new .../internal/escape/alias.go file,
especially the (*aliasAnalysis).analyze method.
In the first benchmark, an append in a loop builds up a slice from
nothing, where the slice elements are each 64 bytes. In the table below,
'count' is the number of appends. With 1 append, there is no opportunity
for this CL to free memory. Once there are 2 appends, the growth from
1 element to 2 elements means the compiler-inserted growsliceNoAlias
frees the 1-element array, and we see a ~33% reduction in memory use
and a small reported speed improvement.
As the number of appends increases for example to 5, we are at
a ~20% speed improvement and ~45% memory reduction, and so on until
we reach ~40% faster and ~50% less memory allocated at the end of
the table.
There can be variation in the reported numbers based on -randlayout, so
this table is for 30 different values of -randlayout with a total
n=150. (Even so, there is still some variation, so we probably should
not read too much into small changes.) This is with GOAMD64=v3 on
a VM that gcc reports is cascadelake.
The second benchmark is similar, but instead uses an 8-byte integer
for the slice element. The first 4 appends in the loop never call into
the runtime thanks to the excellent CL 664299 introduced by Keith in
Go 1.25 that allows some <= 32 byte dynamically-sized slices to be on
the stack, so this CL is neutral for <= 32 bytes. Once the 5th append
occurs at count=5, a grow happens via the runtime and heap allocates
as normal, but freegc does not yet have anything to free, so we see
a small ~1.4ns penalty reported there. But once the second growth
happens, the older heap memory is now automatically freed by freegc,
so we start to see some benefit in memory reductions and speed
improvements, starting at a tiny speed improvement (close to a wash,
or maybe noise) by the second growth before count=10, and building up to
~2x faster with ~68% fewer allocated bytes reported.
Of course, these are just microbenchmarks, but likely indicate
there are some opportunities here.
The immediately following CL 712422 tackles inlining and is able to get
runtime.freegc working automatically with iterators such as used by
slices.Collect, which becomes able to automatically free the
intermediate memory from its repeated appends (which earlier
in this work required a temporary hand edit to the slices package).
For now, we only use the NoAlias version for element types without
pointers while waiting on additional runtime support in CL 698515.
Updates #74299
Change-Id: I1b9d286aa97c170dcc2e203ec0f8ca72d84e8221
Reviewed-on: https://go-review.googlesource.com/c/go/+/710015 Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Keith Randall <khr@golang.org> 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>
limeidan [Mon, 24 Nov 2025 09:28:42 +0000 (17:28 +0800)]
cmd/link, cmd/internal/obj: fix a remote call failure issue
When a function call exceeds the immediate value range of the instruction,
a trampoline is required to assist in the jump. Trampoline is only omitted
when plt is needed; otherwise, a check is required.
Change-Id: I7fe2e08d75f6f574475837b560e650bbd4215858
Reviewed-on: https://go-review.googlesource.com/c/go/+/724580 Reviewed-by: abner chenc <chenguoqi@loongson.cn>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: sophie zhao <zhaoxiaolin@loongson.cn> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Mark Freeman [Mon, 24 Nov 2025 22:04:49 +0000 (17:04 -0500)]
go/types, types2: replace setDefType with pending type check
Given a type definition of the form:
type T RHS
The setDefType function would set T.fromRHS as soon as we knew its
top-level type. For instance, in:
type S struct { ... }
S.fromRHS is set to a struct type before type-checking anything inside
the struct.
This permit access to the (incomplete) RHS type in a cyclic type
declaration. Accessing this information is fraught (as it's incomplete),
but was used for reporting certain types of cycles.
This CL replaces setDefType with a check that ensures no value of type
T is used before its RHS is set up.
This CL is strictly more complete than what setDefType achieved. For
instance, it enables correct reporting for the below cycles:
type A [unsafe.Sizeof(A{})]int
var v any = 42
type B [v.(B)]int
func f() C {
return C{}
}
type C [unsafe.Sizeof(f())]int
Fixes #76383
Fixes #76384
Change-Id: I9dfab5b708013b418fa66e43362bb4d8483fedec
Reviewed-on: https://go-review.googlesource.com/c/go/+/724140
Auto-Submit: Mark Freeman <markfreeman@google.com> Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
crypto,testing/cryptotest: ignore random io.Reader params, add SetGlobalRandom
First, we centralize all random bytes generation through drbg.Read. The
rest of the FIPS 140-3 module can't use external functions anyway, so
drbg.Read needs to have all the logic.
Then, make sure that the crypto/... tree uses drbg.Read (or the new
crypto/internal/rand.Reader wrapper) instead of crypto/rand, so it is
unaffected by applications setting crypto/rand.Reader.
Next, pass all unspecified random io.Reader parameters through the new
crypto/internal/rand.CustomReader, which just redirects to drbg.Read
unless GODEBUG=cryptocustomrand=1 is set. Move all the calls to
MaybeReadByte there, since it's only needed for these custom Readers.
Finally, add testing/cryptotest.SetGlobalRandom which sets
crypto/rand.Reader to a locked deterministic source and overrides
drbg.Read. This way SetGlobalRandom should affect all cryptographic
randomness in the standard library.
Fixes #70942
Co-authored-by: qiulaidongfeng <2645477756@qq.com>
Change-Id: I6a6a69641311d9fac318abcc6d79677f0e406100
Reviewed-on: https://go-review.googlesource.com/c/go/+/724480 Reviewed-by: Nicholas Husin <nsh@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: Nicholas Husin <husin@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
matloob [Wed, 26 Nov 2025 23:04:22 +0000 (18:04 -0500)]
runtime: update mkmalloc to make generated code look nicer
This cl adds a new operation that can remove an if statement or replace
it with its body if its condition is var or !var for some variable var
that's being replaced with a constant.
Change-Id: I864abf1f023b2a66b2299ca65d4f837d6a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/724940
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Michael Matloob <matloob@google.com>
Auto-Submit: Michael Matloob <matloob@google.com>
Daniel Morsing [Thu, 25 Sep 2025 16:26:03 +0000 (17:26 +0100)]
runtime/secret: implement new secret package
Implement secret.Do.
- When secret.Do returns:
- Clear stack that is used by the argument function.
- Clear all the registers that might contain secrets.
- On stack growth in secret mode, clear the old stack.
- When objects are allocated in secret mode, mark them and then zero
the marked objects immediately when they are freed.
- If the argument function panics, raise that panic as if it originated
from secret.Do. This removes anything about the secret function
from tracebacks.
For now, this is only implemented on linux for arm64 and amd64.
This is a rebased version of Keith Randalls initial implementation at
CL 600635. I have added arm64 support, signal handling, preemption
handling and dealt with vDSOs spilling into system stacks.
Fixes #21865
Change-Id: I6fbd5a233beeaceb160785e0c0199a5c94d8e520 Co-authored-by: Keith Randall <khr@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/704615 Reviewed-by: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
Alan Donovan [Mon, 21 Jul 2025 18:35:08 +0000 (14:35 -0400)]
go/types: relax NewSignatureType for append(slice, str...)
CL 688815 contained a partial fix for the reported bug, but
NewSignatureType continued to panic. This change relaxes it
to permit construction of the type "func([]byte, B) []byte"
where "type B []byte". We must do so because a client
may instantiate the type "func([]byte, T...)" where [T ~string|~[]byte]
at T=B, and may have no way to know that they are dealing
with this very special edge case of append.
Added a regression test of NewSignatureType, which I should
have done in the earlier CL.
Also, make typestring less pedantic and fragile.
Fixes #73871
Change-Id: I3d8f8609582149f9c9f8402a04ad516c2c63bbc6
Reviewed-on: https://go-review.googlesource.com/c/go/+/689277
TryBot-Bypass: Alan Donovan <adonovan@google.com> Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Alan Donovan <adonovan@google.com> Reviewed-by: Mark Freeman <markfreeman@google.com>
matloob [Wed, 26 Nov 2025 15:30:34 +0000 (10:30 -0500)]
cmd/go: remove experiment checks for compile -c
There's a comment that we should test that compile -c is compatible with
the fieldtrack and preemptibleloops experiments and then remove the
check disabling -c when those experiments are enabled.
I tested this and the tests pass with fieldtrack (with the exception of one go command test that makes the assumption that fieldtrack is off), and the preemptibleloops experiment is already broken without this experiment.
Also remove the check for the value of the GO19CONCURRENTCOMPILATION
environment variable. The compiler concurrency can be limited by setting
GOMAXPROCS.
Change-Id: I0c02745de463ea572673648061185cd76a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/724680 Reviewed-by: Alan Donovan <adonovan@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Dmitri Shuralyov [Wed, 26 Nov 2025 21:12:53 +0000 (16:12 -0500)]
doc/next: document broken freebsd/riscv64 port
Also update comment in cmd/dist's broken map to point to the top-level
umbrella issue.
For #76475.
For #75005.
Change-Id: I43b8384af4264dc5d72ceea8d05730b9db81123a
Reviewed-on: https://go-review.googlesource.com/c/go/+/724860 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Bypass: Dmitri Shuralyov <dmitshur@golang.org>
Daniel Morsing [Mon, 24 Nov 2025 13:08:10 +0000 (13:08 +0000)]
crypto/fips140: add WithoutEnforcement
WithoutEnforcement lets programs running under GODEBUG=fips140=only
selectively opt out of strict enforcement. This is especially helpful
for non-critical uses of cryptography routines like SHA-1 for content
addressable storage backends (E.g. git).
Fixes #74630
Change-Id: Iabba1f5eb63498db98047aca45e09c5dccf2fbdf
Reviewed-on: https://go-review.googlesource.com/c/go/+/723720 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Filippo Valsorda <filippo@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Roland Shoemaker <roland@golang.org>
Michael Matloob [Mon, 24 Nov 2025 23:33:30 +0000 (18:33 -0500)]
cmd/go: limit total compile -c backend concurrency using a pool
Previously we limited the value we passed in to compile -c (which set
the number of SSA compile goroutines that run at one time) to 4. This CL
allows the -c value to go up to GOMAXPROCS, while limiting the total
number of backend SSA compile goroutines to still be less than the
previous worst case of 4*GOMAXPROCS (actually four times the value of
the -p flag, but the default is GOMAXPROCS). We do that by keeping a
pool of tokens to represent the total number of SSA compile goroutines
(with some buffer to allow us to run out of tokens and not exceed
4*GOMAXPROCS). Each time a compile requests a -c value, we'll hand out
half of the remaining tokens (with the number handed otu capped at
GOMAXPROCS) until we run out of tokens, in wich case we'll set -c to
one.
This leads to a speed up of 3-10% on the 16 core intel perf builder and
5-16% on the 88 core builder on the Sweet go-build benchmark.
Change-Id: Ib1ec843fee57f0fb8d36a507162317276a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/724142 Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Matloob <matloob@google.com>
Keith Randall [Thu, 20 Nov 2025 17:42:16 +0000 (09:42 -0800)]
cmd/compile: handle loops better during stack allocation of slices
Don't use the move2heap optimization if the move2heap is inside
a loop deeper than the declaration of the slice. We really only want
to do the move2heap operation once.
Change-Id: I4a68d01609c2c9d4e0abe4580839e70059393a81
Reviewed-on: https://go-review.googlesource.com/c/go/+/722440 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Junyang Shao <shaojunyang@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Robert Griesemer [Wed, 26 Nov 2025 00:26:25 +0000 (16:26 -0800)]
go/types, types2: improve printing of []*operand lists (debugging support)
Special-case an sprintf argument of []*operand type, similar to what
we do for other lists. As a result a list of operands is printed as
[a, b, c] rather than [a b c] (default formatting for slices).
(We could factor out this code into a generic function, but this is
a minimally intrusive change at this point.)
Change-Id: Iea4fc6ea375dd9618316b7317a77b57b4e35544d
Reviewed-on: https://go-review.googlesource.com/c/go/+/724500 Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Mark Freeman <markfreeman@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
qmuntal [Wed, 26 Nov 2025 11:11:50 +0000 (12:11 +0100)]
os,internal/syscall/windows: support O_* flags in Root.OpenFile
These file flags are supported by os.OpenFile since CL 699415.
Closes #73676
Change-Id: Ib37102a565f538d394d2a94bd605d6c6004f3028
Reviewed-on: https://go-review.googlesource.com/c/go/+/724621
Auto-Submit: Damien Neil <dneil@google.com> Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
Xiaolin Zhao [Tue, 18 Nov 2025 08:00:35 +0000 (16:00 +0800)]
cmd/internal/obj/loong64: add aliases to 32-bit arithmetic instructions
Both the MULW and MUL instructions point to the mul.w instruction
in the loong64 ISA. Previously, MULW was not encoded; now it is
encoded and used as an alias for MUL.
The same applies to the following instructions: ADD, SUB, DIV.
For consistency, we have added additional aliases for DIVU, REM and REMU.
Change-Id: Iba201a3c4c2893ff7d301ef877fad9c81e54291b
Reviewed-on: https://go-review.googlesource.com/c/go/+/721523 Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: abner chenc <chenguoqi@loongson.cn> Reviewed-by: abner chenc <chenguoqi@loongson.cn> Reviewed-by: Meidan Li <limeidan@loongson.cn> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
qmuntal [Wed, 26 Nov 2025 09:25:16 +0000 (10:25 +0100)]
os,internal/poll: don't call IsNonblock for consoles and Stdin
windows.IsNonblock can block for synchronous handles that have an
outstanding I/O operation. Console handles are always synchronous, so
we should not call IsNonblock for them. Stdin is often a pipe, and
almost always a synchronous handle, so we should not call IsNonblock for
it either. This avoids potential deadlocks during os package
initialization, which calls NewFile(syscall.Stdin).
Fixes #75949
Updates #76391
Cq-Include-Trybots: luci.golang.try:gotip-windows-amd64-longtest,gotip-windows-amd64-race,gotip-windows-arm64
Change-Id: I1603932b0a99823019aa0cad960f94cee9996505
Reviewed-on: https://go-review.googlesource.com/c/go/+/724640
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Damien Neil <dneil@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
Boris Nagaev [Wed, 26 Nov 2025 08:26:49 +0000 (08:26 +0000)]
crypto/internal/fips140/aes: optimize ctrBlocks8Asm on amd64
Implement overflow-aware optimization in ctrBlocks8Asm: make a fast branch
in case when there is no overflow. One branch per 8 blocks is faster than
7 increments in general purpose registers and transfers from them to XMM.
Added AES-192 and AES-256 modes to the AES-CTR benchmark.
Added a correctness test in ctr_test.go for the overflow optimization.
This improves performance, especially in AES-128 mode.
Alexander Musman [Sat, 5 Jul 2025 20:16:36 +0000 (23:16 +0300)]
cmd/compile,internal/bytealg: add MemEq intrinsic for runtime.memequal
Introduce a new MemEq SSA operation for runtime.memequal. The operation
is initially implemented for arm64. The change adds opt rules (following
existing rules for call to runtime.memequal), working with MemEq, and a
later op version LoweredMemEq which may be lowered differently for more
constant size cases in future (for other targets as well as for arm64).
The new MemEq SSA operation does not have memory result, allowing cse of
loads operations around it.
Change-Id: I6ab507929b861884d17d5818cfbd152cf7879751
Reviewed-on: https://go-review.googlesource.com/c/go/+/686655 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: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
David Chase [Mon, 17 Nov 2025 18:53:58 +0000 (13:53 -0500)]
cmd/compile: adjust start heap size
TLDR
- not-huge increase to default starting heap boost,
- small improvement in build performance,
- remove concurrency dependence of starting heap,
- aligns RSS behavior with GOMEMLIMIT,
- adds a gcflags=-d=gcstart=N (N -> N MiB) flag for
people who want to trade a lot of memory for a
little build performance improvement.
This removes concurrency (-c flag) sensitivity and increases the
nominal default to 128MiB.
Refactored the startheap code into a separate file, to make it
easier to extract and reuse.
Added sensitivity to concurrency=1 and GOMEMLIMIT!="" (in addition
to existing GOGC!=""), those disable the default starting heap boost
because the compiler-invoker has indicated either a desire to control
the GC or a desire to run in minimum memory(or both).
Adds a -d flag gcstart=N (N is number of MiB) for
tinkering/experiments. This always enables the starting heap.
(`GOGC=XXX` and `-d=gcstart=YYY` will use `GOGC=XXX` after starting
heap size is achieved.)
Derated the "boost" obtained by a factor of .70 so that
`-d=gcstart=2000` yields the same RSS as `GOMEMLIMIT=2000MiB`
(Actually adjusts the boost with a high-low breakpoint.)
The parent, with concurrency sensitivity, provided 64MB of plain
boost. Derating reduces the effects of boosting the starting heap
slightly. The benchmark here shows that maintaining 64MB results in
a minor regression, while increasing it to 128MB produces a slight
improvement, and does not grow the RSS versus 64MB.
Ian Lance Taylor [Fri, 22 Aug 2025 20:47:42 +0000 (13:47 -0700)]
runtime: panic if cleanup function closes over cleanup pointer
This would catch problems like https://go.dev/cl/696295.
Benchmark effect with this CL plus CL 697535:
goos: linux
goarch: amd64
pkg: runtime
cpu: 12th Gen Intel(R) Core(TM) i7-1260P
│ /tmp/foo.1 │ /tmp/foo.2 │
│ sec/op │ sec/op vs base │
AddCleanupAndStop-16 81.93n ± 1% 82.87n ± 1% +1.14% (p=0.041 n=10)
For #75066
Change-Id: Ia41d0d6b88baebf6055cb7e5d42bc8210b31630f
Reviewed-on: https://go-review.googlesource.com/c/go/+/714000 Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>