The ciphertext tail loads and stores were assuming that the ciphertext
would always be followed by at least 16 bytes of tag, which could be
read and masked or written with zeroes innocuously.
Annoyingly, we support short GCM tags, so that assumption does not hold.
Repurposed the plaintext tail load/store assembly, which was making no
such assumption, to be used for the ciphertext tail as well.
Added tests in cryptotest.TestAEAD that surround the buffers with
inaccessible pages, so that any out-of-bounds access will fault. In the
process, normalized how these tests are done across the crypto tree.
Fixes#80288
Change-Id: Id334c3803a593e18c9607d9b0d2b78616a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/801600
Auto-Submit: Filippo Valsorda <filippo@golang.org>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
This allows known bits's debug output to be traversal order independant
(when not considering loops which known bits currently do not know
how to deal with).
Fixes#80451
Change-Id: I33e91bbed27122400f65422a86ab29a5a3d6d277
Reviewed-on: https://go-review.googlesource.com/c/go/+/802141
Auto-Submit: Jorropo <jorropo.pgm@gmail.com>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <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>
I have found some of theses in the wild and we are relying on
known bits to fold theses right now.
Doing in opt allows prove to do a better job.
Change-Id: I30dc6b8acf66356726d50782a95a07a18f1ed1ae
Reviewed-on: https://go-review.googlesource.com/c/go/+/801980
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Jorropo <jorropo.pgm@gmail.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
The -toolexec build flag wraps each toolchain program (compile, asm,
link, ...) in a user-supplied program, e.g. to profile them or swap in
alternates.
To know when to rebuild a cgo package, the go command records the C,
C++, and Fortran compiler versions by probing each compiler:
cc -### -x c -c -
That probe was run under -toolexec, but the real cgo compiles never
are, so the wrapper saw the probe and none of the actual compiles.
Probe under -toolexec only for gccgo, a Go toolchain compiler treated
like cmd/compile. Leave the C, C++, and Fortran probes unwrapped.
Fixes#64580
Change-Id: I2161d6d4a8d49e87e5854dfe17b9eb83db059376
GitHub-Last-Rev: f48be7eda7db9a8e5cd87d46ead5bf65df5fee9a
GitHub-Pull-Request: golang/go#80153
Reviewed-on: https://go-review.googlesource.com/c/go/+/794361
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Sean Liao <sean@liao.dev>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
This CL should have been part of CL 796480, but was mistakenly omitted.
Updates #77485.
Change-Id: Ib18dbbcd01ad2080d14c64494e2c71421a1bd2f5
Reviewed-on: https://go-review.googlesource.com/c/go/+/801960
Reviewed-by: Richard Miller <millerresearch@gmail.com>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: David Chase <drchase@google.com>
I filed #49331 about five years ago, suggesting that the compiler
should re-associate some computations to support ILP.
There was general consensus that it was a decent idea,
and I believe that Ryan Berger may have attempted it,
but so far, nothing has landed.
For md5 in particular, which was the motivating example,
we can get the desired parallelism by adjusting the source code.
So do that. We can always revert if/when the compiler pass lands.
Each MD5 step is of the form
arg0 = arg1 + RotateLeft32(F(arg1,arg2,arg3) + arg0 + x + k, s)
where arg1 is the output of the previous step.
The generated code has the form a+(b+(c+d)) rather than (a+b)+(c+d),
which has a long serial dependency chain.
This is a significant source of the performance difference between
the generic Go code and the handwritten assembly.
Adjust the generator to impose the association we desire.
Group the arg1-independent terms as F + (arg0+x+k).
This lets the compiler schedule the inner sum in parallel with F,
trimming the chain to a single add after F is calculated.
Add two further expression tweaks.
In round 2, use the direct selection form (x&z)|(y&^z)
instead of the XOR-trick form ((x^y)&z)^y.
The direct form puts arg1 on a 2-op path to F instead of 3,
which reduces serialization on the critical path and shortens variable lifetimes.
On arm64, both forms are 3 logical ops.
On default amd64, this adds an instruction,
but it's off the critical path.
And BMI1 is available at GOAMD64 >= v3.
In round 3, associate arg1^arg2^arg3 as arg1^(arg2^arg3), again for ILP.
Before this commit, asm was about ~30% faster than purego on my arm64
machine, and ~37% on the amd64 machine I have access to (no GOAMD64).
This commit narrows the gap to ~13% and ~20%, respectively.
I have follow-up work planned that shrinks the gap further
and should enable deletion of the md5 assembly.
Updates #49248
Updates #49331
Change-Id: Ia317e20cd73c88c4fb9303b31f5b6b441bfa6b63
Reviewed-on: https://go-review.googlesource.com/c/go/+/801240
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
We don't support binary-only packages, and haven't for a while. We would
only check for binary only packages when actually executing the action
graph. But it seems more natural to report the error when loading
packages. The only difference is the reporting of staleness but it
doesn't really make sense to report staleness if we don't even support
building those packages.
While we're here remove the unused needStale need bit.
This also slightly simplifies the logic in checkCacheForBuild.
For #28152
Change-Id: I2bad74152d2c4323026c7513537265a36a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/799002
Auto-Submit: Michael Matloob <matloob@golang.org>
TryBot-Bypass: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: Hongxiang Jiang <hxjiang@golang.org>
t.Parallel and the operations that forbid it (t.Setenv, t.Chdir, and
cryptotest.SetGlobalRandom) shared a single panic message that listed all
three operations, so the panic never named the one that actually caused the
conflict. A test that only calls t.Setenv could panic with a message
mentioning cryptotest.SetGlobalRandom, which is confusing.
Record the specific operation that denies parallelism and report it in both
directions: when t.Parallel is called after one of those operations, and
when one of them is called on a test that is already parallel.
Fixes#80267
Change-Id: I749e22f3e6df3552795c512636a5d2466d95af4f
GitHub-Last-Rev: 68ecf1b19a73937c99f7db5ea3c4122541bfd6d0
GitHub-Pull-Request: golang/go#80313
Reviewed-on: https://go-review.googlesource.com/c/go/+/798641
Reviewed-by: Sean Liao <sean@liao.dev>
Auto-Submit: Sean Liao <sean@liao.dev>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Auto-Submit: Alan Donovan <adonovan@google.com>
Added a newline after each section header and its following paragraph,
so the sections would render properly.
Ran gofmt, which indented the code blocks with tab characters and
replaced * bullets with - ones.
Note: this documentation is intentionally NOT general package
documentation, but is now formatted consistently with other doc
comments.
For #80397
Change-Id: Ib651e204fc9813122934357a67f3c75bd453483c
Reviewed-on: https://go-review.googlesource.com/c/go/+/801900
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Mark Freeman <markfreeman@google.com>
Reviewed-by: Mark Freeman <markfreeman@google.com>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
For unsigned 32-bit division by a constant d on 64-bit targets (amd64,
arm64, riscv64, ...), when the magic multiplier M = 2^32 + m has m odd
(i.e. M is truly 33-bit and cannot be halved to fit in 32 bits), use a
pre-shifted constant C = M << (32 - s) so that a single Hmul64u gives
the quotient directly:
x / d = Hmul64u(ZeroExt32to64(x), C)
This replaces the avg-based sequence for odd divisors (Case 3) and the
SHR+IMULQ+SHR sequence for even divisors whose underlying magic is
33-bit (e.g. d=14=2×7). Divisors where m is even (Case 6) keep their
existing 32-bit constant path to avoid loading a large 64-bit constant
on arm64/riscv64.
Benchmark on Intel Xeon w9-3495X (3 divisions per iteration, go1.26.3):
BenchmarkOdd (d=7,19,107): 3.07 ns/op → 1.92 ns/op (~38% faster)
BenchmarkEven (d=14,38,214): 2.04 ns/op → 1.92 ns/op (~6% faster)
Ref: https://arxiv.org/abs/2604.07902https://github.com/llvm/llvm-project/pull/181288Fixes#79780
Change-Id: I33f551f4f6715ddbcc39f9f56c1331f31f0eca33
Reviewed-on: https://go-review.googlesource.com/c/go/+/785960
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Somewhat surprisingly, ReverseProxy will forward "Upgrade: h2c" headers
which attempt to switch an HTTP/1 connection to an unencrypted HTTP/2 one.
If the backend supports this deprecated protocol switch mechanism,
this lets a client send HTTP requests that bypass the ReverseProxy's
handlers. This is surprising at best, a security issue at worst.
Refuse to forward "Upgrade: h2c" headers.
In the unlikely event anyone actually wants this behavior,
they can use a Rewrite function to add the Upgrade: h2c
to the forwarded request.
Fixes#80416
Change-Id: I3a7d80fadf2eccbcce97f423556f8bf26a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/801722
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Damien Neil <dneil@google.com>
Reviewed-by: Nicholas Husin <husin@google.com>
Reviewed-by: Nicholas Husin <nsh@golang.org>
The Upgrade header is only valid on HTTP/1.1 connections.
(HTTP/2 has a different mechanism, see RFC 8441.)
Reject upgrade requests received on a non-HTTP/1.1 connection.
For #80416
Change-Id: I322ff6a3b4585c560f9ecaa206cd77446a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/801721
Reviewed-by: Nicholas Husin <nsh@golang.org>
Reviewed-by: Nicholas Husin <husin@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Fix the ReverseProxy documentation to indicate that upgrade
requests (like requests establishing a WebSocket connection)
are forwarded.
For #80416
Change-Id: Ia75f01692faf498215a05756637c8be46a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/801720
Reviewed-by: Nicholas Husin <husin@google.com>
Reviewed-by: Nicholas Husin <nsh@golang.org>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Damien Neil <dneil@google.com>
This reverts CL 795261.
Reason for revert: Causing failures on perf builders due to map initialization issues in CockroachDB.
Updates #80141
Updates #77153Fixes#80423
Change-Id: I365f20eec2220894923d4748d730484f6e6ef5c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/802120
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
This change handles the more straightforward targets for composite
literal type inference; they are typically identical to the targets
passed for generic function values.
A variety of test cases are added. Those which are awaiting
implementation are commented out for now.
For #12854
Change-Id: I776e160dd7bce0768589a552c4e7913b1c70220f
Reviewed-on: https://go-review.googlesource.com/c/go/+/794088
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Mark Freeman <markfreeman@google.com>
This change checks for a type target for composite literals and performs
the appropriate type inference. Note that U is currently always nil; we
still need to pipe in the types for the relevant contexts. Thus, this
change is a no-op for now.
For #12854
Change-Id: I8517ef72da3b09328be5661021f700b6b00e5f1f
Reviewed-on: https://go-review.googlesource.com/c/go/+/794060
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Mark Freeman <markfreeman@google.com>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This change threads a type target through the major expression type
checking logic in Checker.expr and its related methods. For now,
this new argument isn't used.
This is done to reduce the surface area of upcoming changes.
For #12854
Change-Id: I0e21c010c5d0d6ea3fd6dd09b5289b1479a88f7f
Reviewed-on: https://go-review.googlesource.com/c/go/+/794040
Auto-Submit: Mark Freeman <markfreeman@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
For channel sends, we currently check the sent value before inspecting
the channel element type. If we check the channel element type first,
we can extract a target type for the value. This change reorders
processing to do so.
This is a necessary prerequisite for composite literal type inference.
For #12854
Change-Id: I19b1ef73a2f82b3c45cd3f4a3f0dc32cd795e7ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/793980
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Mark Freeman <markfreeman@google.com>
The Go 1.28 development tree has opened. 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: I11731202ff1ede6ed905c667b5bbd7546a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/801060
Reviewed-by: Nicholas Husin <husin@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Auto-Submit: Nicholas Husin <nsh@golang.org>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
This CL reapplies CL 666255 , and fixes the previous implementation's unaligned access and panic on mips64x.
Updates #74998
Change-Id: I8e58d25ba5f11520bfbe6e515d378c805bd5984f
Reviewed-on: https://go-review.googlesource.com/c/go/+/696075
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
This CL reapplies CL 666275 , and fixes the previous implementation's unaligned access and panic on mipsx.
Updates #74998
Change-Id: I26cd3fdeb54419407bdc0a2f9616924e2e825bc3
Reviewed-on: https://go-review.googlesource.com/c/go/+/696076
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
CL 787320 changed
go list -compiled -x -f '{{.CompiledGoFiles}}' .
output. But the CL did not changed build_cwd_newline.txt
test because it is only running when CGO_ENABLED=0.
Adjust the test.
Updates #75238
Change-Id: I675abd19ef8fc75e0a8367ef937b202e8ba768ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/801420
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Sean Liao <sean@liao.dev>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
CL 782461 added new test for avoiding temporary on non-softfloat system.
However, the test was set to be run unconditionally, thus it would be
failed on softfloat builders.
Fixing this by moving the test to be run under cmd/internal/testdir, so
it's possible to exclude unwanted softfloat platforms. While at it, also
tighten the test to ensure there would be temporary if the compiler is
forced to emit softfloat code.
Updates #28698Fixes#80422
Cq-Include-Trybots: luci.golang.try:gotip-linux-386-softfloat
Change-Id: I5f7b3a19fe36d070d819d58cc29d43e4b44bb1fe
Reviewed-on: https://go-review.googlesource.com/c/go/+/801560
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
This is done similarly to in CL 646335.
Fixes#80278
Change-Id: Idc0abb682797b9f4e23842b332428a486a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/799984
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: Jorropo <jorropo.pgm@gmail.com>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Add an align128 sentinel type to sync/atomic and
internal/runtime/atomic, analogous to align64. Embedding `_ align128`
in a struct causes the compiler to enforce 16-byte alignment on the
containing struct.
This is required for 128-bit atomic operations (CMPXCHG16B on amd64,
CASP on arm64), which require a 16-byte-aligned memory operand. A
struct containing two uint64 fields has natural alignment of 8 bytes,
so it may otherwise be placed at a non-16-byte-aligned offset within a
larger struct, causing faults or incorrect behavior.
No test: align128 is unexported in sync/atomic, and testing it in internal
would create cyclic dependencies with reflect.
For #61236.
Change-Id: Iab0502776141aed309457b462f2fdb60ec0d5245
GitHub-Last-Rev: 8cf379404d04c1fbe2b011975d5932eb9d9225da
GitHub-Pull-Request: golang/go#79991
Reviewed-on: https://go-review.googlesource.com/c/go/+/790320
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
This ensures that runtime's signal handlers pass through the TSAN and
MSAN like arm64/loong64 does.
Change-Id: I3f6ef61a96e5f1f4c5b68eb5703e77b2dba7dbe9
Reviewed-on: https://go-review.googlesource.com/c/go/+/796100
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Interrupt process uses cmd.Process.Signal(os.Interrupt).
But that call is not implemented on Windows.
Use cmd.Process.Kill() instead.
This CL also adds small test to test the code.
Updates #77485.
Change-Id: Ie0e2326aa3c4c49a20c71e48caf1409c699c41c2
Reviewed-on: https://go-review.googlesource.com/c/go/+/796480
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
They provide a subset of the information that the newer port:*-* counter
provides, making them generally redundant. They were never uploaded, and
there are no plans to start using them, so remove them.
For #79214.
Change-Id: I74b0d8b51c2566b04a980c61e67edfb5a6a1d4a3
Reviewed-on: https://go-review.googlesource.com/c/go/+/775982
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Just move the sign bit down to where it is needed for a boolean.
Change-Id: Ib6543273396d64cf150650d242d1869e1fd46f5d
Reviewed-on: https://go-review.googlesource.com/c/go/+/801282
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Jorropo <jorropo.pgm@gmail.com>
On a clean GOCACHE, buildPkgsite returned a temporary path deleted
by b.Close() before the command execution.
Instead, this CL always returns the cached executable path even
it is fresh built ensuring the existence of the doc executable.
+test
Fixesgolang/go#80287
Change-Id: I949d01dceac817082fa5e38450d0b0b39fc325a3
Reviewed-on: https://go-review.googlesource.com/c/go/+/800720
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
Since Go source code is in UTF-8, smart quotes
should be part of the original source
if they are desired. Characters important to
programming languages should not be mangled.
Fixes#54312Fixes#76975
Change-Id: I20331669bb691eafe66ebcc3f8513c4f6a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/732420
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: kortschak <dan@kortschak.io>
Reviewed-by: Rob Pike <r@golang.org>
go test -cover runs "go tool covdata", which links covdata, caches the
executable into $GOCACHE (CacheExecutable), and execs it from there via
runBuiltTool. When many packages are tested at once (go test ./...), the
covdata invocations share one build cache. A concurrent go process can
still hold a writable descriptor to the freshly written cached file when
this process execs it, so the exec fails with ETXTBSY ("text file busy"):
go tool covdata: fork/exec $GOCACHE/<hash>/covdata: text file busy
Every other exec-from-cache path already retries this race: base.RunStdin
and (*runTestActor).Act in cmd/go/internal/test both loop on ETXTBSY with
backoff (see #22220, #22315). runBuiltTool was the one path that did not.
The race became observable in 1.26 after CL 668035 (test barrier actions)
reordered the scheduling of test/coverage run actions; the underlying
missing-retry bug was latent before that.
Wrap toolCmd.Start() in the same bounded retry. Retrying Start() is safe:
once it succeeds the exec has happened (no ETXTBSY is possible after), and
on failure the child never ran, so re-execing has no side effects.
Fixes#78204
Change-Id: I77d0a5804e69d4fb386bbdb4aa9c5f3b179261b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/790840
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Sean Liao <sean@liao.dev>
Auto-Submit: Michael Pratt <mpratt@google.com>
Func.Names was []*LocalSlot, so every entry was a separately
heap-allocated LocalSlot. Most named values are scalars that are never
decomposed, yet each one still allocated a LocalSlot when it was first
recorded in addNamedValue.
Change Func.Names to []LocalSlot. addNamedValue now appends the slot by
value and no longer eagerly fills CanonicalLocalSlots. The canonical
*LocalSlot used for SplitOf chains and split deduplication is created
lazily by localSlotAddr, so only slots that are actually decomposed pay
for it. The names stay contiguous and the garbage collector has one
fewer pointer per name to scan.
This is a follow-up to CL 790300, the addNamedValue escape fix for
issue #79990. That change stopped the slot escaping; this one removes
the remaining per-name allocation for slots that are never decomposed.
Passes toolstash -cmp; std and cmd build byte-identical.
allocs/op via compilebench -alloc, linux/amd64 (-count 20); all packages
±0%, p<=0.001. "vs parent" is the win over CL 790300, "vs master" folds
in CL 790300 too:
allocs/op vs parent vs master
Template 814.0k -0.16% -0.76%
Unicode 573.7k -0.03% -0.10%
GoTypes 4.956M -0.26% -1.08%
SSA 46.32M -0.37% -1.51%
Flate 811.6k -0.30% -1.45%
GoParser 785.8k -0.23% -0.78%
Reflect 2.293M -0.41% -1.11%
Tar 927.5k -0.34% -1.02%
XML 1.088M -0.32% -0.92%
geomean 1.755M -0.27% -0.97%
Updates #79990
Change-Id: Ib277056a47585d7805438955062c2f59bd77d42f
Reviewed-on: https://go-review.googlesource.com/c/go/+/790920
Reviewed-by: Michael Podtserkovskii <michaelpo@meta.com>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
The IsTrue comment says a value is 'true' when it is not the zero
value of its type. That contradicts the implementation for structs,
which are always true, and is wrong for a negative floating-point
zero, which is untruthy without being 'the' zero of its type.
Describe the rules the implementation actually applies instead.
The comment is duplicated in html/template; update both copies.
Fixes#28394
Change-Id: Idbbabec39ce46bddbbdd4877ac8cfe2b5d4a08dc
GitHub-Last-Rev: 435105c83ac18f4cb64cd8cbc3cc4e00a91f476f
GitHub-Pull-Request: golang/go#80338
Reviewed-on: https://go-review.googlesource.com/c/go/+/799063
Auto-Submit: Sean Liao <sean@liao.dev>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Sean Liao <sean@liao.dev>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
When a passing test in package list mode writes output that does not end
in a newline, and that output is discarded (the default non-verbose,
non-JSON case), cmd/go printed a spurious blank line before the "ok"
summary line.
The newline-before-"ok" guard tested out, a snapshot of the captured
output taken before buf.Reset() discards it, but wrote the newline into
buf, which Reset had already emptied. Test buf itself, so no newline is
added when the captured output was discarded.
Fixes#79786
Change-Id: Iab32de2d8fa9db85681e2e4f01d7af3f08a0f626
GitHub-Last-Rev: 86aaa23984a33a4057e755467156234d35fb24cd
GitHub-Pull-Request: golang/go#80352
Reviewed-on: https://go-review.googlesource.com/c/go/+/799182
Reviewed-by: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Sean Liao <sean@liao.dev>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Sean Liao <sean@liao.dev>
EncodedLen computes the encoded length with int arithmetic that can
wrap for very large n, returning a negative or wrapped value. Callers
that size an allocation from the result (EncodeToString, AppendEncode)
then panic with no indication of the cause, or allocate an undersized
buffer. CL 510635 and CL 512200 raised the overflow threshold of the
unpadded branches but did not eliminate it, and the padded branches
were unchanged: on 32-bit platforms
base64.StdEncoding.EncodedLen(1610612736) still returns -2147483648.
Make EncodedLen panic when the encoded length does not fit in an int,
document the panic, and document the largest n that is guaranteed not
to panic. DecodedLen needs no change: its result is at most n and
cannot overflow.
Fixes#20235
Change-Id: I963a55062a790017b42f49fc3a9178fc3bb024ef
GitHub-Last-Rev: 2a7abbb35f7f5e3a2b74c379c29464e01e2206f5
GitHub-Pull-Request: golang/go#80373
Reviewed-on: https://go-review.googlesource.com/c/go/+/799800
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
