The code previously filters out VAES-only instructions, this CL added
them back.
This CL added the VAES feature check following the Intel xed data:
XED_ISA_SET_VAES: vaes.7.0.ecx.9 # avx.1.0.ecx.28
This CL also found out that the old AVX512VAES feature check is not
checking the correct bits, it also fixes it:
XED_ISA_SET_AVX512_VAES_128: vaes.7.0.ecx.9 aes.1.0.ecx.25 avx512f.7.0.ebx.16 avx512vl.7.0.ebx.31
XED_ISA_SET_AVX512_VAES_256: vaes.7.0.ecx.9 aes.1.0.ecx.25 avx512f.7.0.ebx.16 avx512vl.7.0.ebx.31
XED_ISA_SET_AVX512_VAES_512: vaes.7.0.ecx.9 aes.1.0.ecx.25 avx512f.7.0.ebx.16
It restricts to the most strict common set - includes avx512vl for even
512-bits although it doesn't requires it.
Change-Id: I4e2f72b312fd2411589fbc12f9ee5c63c09c2e9a
Reviewed-on: https://go-review.googlesource.com/c/go/+/738500
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
When resuming TLS sessions, on the server and client verify that the
chains stored in the session state (verifiedChains) are still acceptable
with regards to the Config by checking for the inclusion of the root in
either ClientCAs (server) or RootCAs (client). This prevents resuming
a session with a certificate chain that would be rejected during a full
handshake due to an untrusted root.
Updates #77113
Updates #77217
Updates CVE-2025-68121
Change-Id: I11fe00909ef1961c24ecf80bf5b97f7b1121d359
Reviewed-on: https://go-review.googlesource.com/c/go/+/737700
Auto-Submit: Roland Shoemaker <roland@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Coia Prant <coiaprant@gmail.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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: 549d8d407e
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>
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>
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>
This change rewrites and simplifies the relro handling.
We eliminate the separate relro SymKind values and the complex
shifting of symbol kinds. Instead, we put the possible relro data
into their own sections, and make those sections relro when appropriate.
We put type descriptors and their associated data into a
new .go.type section. As part of this we change the runtime.etypes
symbol to be the end of the new section, rather than the end of
rodata as it was before.
We put function descriptors into a new .go.func section.
Ordinary rodata relro stays in the .data.rel.ro section.
We stop making the typelink section relro, as it only contains
offsets and never has dynamic relocations.
We drop the typerel:* and go:funcdescrel symbols.
For #76038
Change-Id: I7aab7cfad3f2623ff06c09a70b756fe1e43f4169
Reviewed-on: https://go-review.googlesource.com/c/go/+/723580
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
The generic SSA representation uses explicit extension and
truncation operations to change widths of values. The map
intrinsics were playing somewhat fast and loose with this
requirement. Fix that, and add a check to make sure we
don't regress.
I don't think there is a triggerable bug here, but I ran into
this with some prove pass modifications, where
cmd/compile/internal/ssa/prove.go:isCleanExt (and/or its uses)
is actually wrong when this invariant is not maintained.
Change-Id: Idb7be6e691e2dbf6d7af6584641c3227c5c64bf5
Reviewed-on: https://go-review.googlesource.com/c/go/+/731300
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Process:
- Disable unicode TestProperties.
- Run UNICODE_VERSION=17.0.0 go -C ../src/golang.org/x/text generate
- Run go generate strconv
- Update unicode TestProperties by hand to add missing test cases.
This will break x/text using the main repo until the corresponding
x/text CL is submitted. It should not break anything else.
For #77266.
Change-Id: Ia3ffb5a81e212b991714eef70eebfca98a0c8aab
Reviewed-on: https://go-review.googlesource.com/c/go/+/737420
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
TryBot-Bypass: Russ Cox <rsc@golang.org>
The json/v2 working group decided to commit to no default representation
for time.Duration for the foreseeable future.
Thus, we can remove the issue reference in the error message.
If JavaScript (TC39) formally adopts the Temporal.Duration type,
which uses ISO 8601 as the JSON representation for a duration,
we may consider changing the default.
Switching from no default to some default in the future
is generally a compatible change.
Updates #71631
Change-Id: I6f71a0fa97dcefba56aab0c0ddf445d9d38f6e58
Reviewed-on: https://go-review.googlesource.com/c/go/+/735080
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The StaticInit pass asserts that the operand of &v is a global,
but this is not so for the &autotemp desugaring of new(expr).
(The variable has by that point escaped to the heap, so
the object code calls runtime.newobject. A future optimization
would be to statically allocate the variable when it is safe
and advantageous to do so.)
Thanks to khr for suggesting the fix.
+ static test
Fixes#77237
Change-Id: I71b34a1353fe0f3e297beab9851f8f87d765d8f1
Reviewed-on: https://go-review.googlesource.com/c/go/+/737680
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>
Constructing the zip index (which is done once when first opening
a file in an archive) can consume large amounts of CPU when
processing deeply-nested directory paths.
Switch to a less inefficient algorithm.
Thanks to Jakub Ciolek for reporting this issue.
goos: darwin
goarch: arm64
pkg: archive/zip
cpu: Apple M4 Pro
│ /tmp/bench.0 │ /tmp/bench.1 │
│ sec/op │ sec/op vs base │
ReaderOneDeepDir-14 25983.62m ± 2% 46.01m ± 2% -99.82% (p=0.000 n=8)
ReaderManyDeepDirs-14 16.221 ± 1% 2.763 ± 6% -82.96% (p=0.000 n=8)
ReaderManyShallowFiles-14 130.3m ± 1% 128.8m ± 2% -1.20% (p=0.003 n=8)
geomean 3.801 253.9m -93.32%
Fixes#77102
Fixes CVE-2025-61728
Change-Id: I2c9c864be01b2a2769eb67fbab1b250aeb8f6c42
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/3060
Reviewed-by: Nicholas Husin <husin@google.com>
Reviewed-by: Neal Patel <nealpatel@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/736713
Auto-Submit: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
net/url does not currently limit the number of query parameters parsed by
url.ParseQuery or URL.Query.
When parsing a application/x-www-form-urlencoded form,
net/http.Request.ParseForm will parse up to 10 MB of query parameters.
An input consisting of a large number of small, unique parameters can
cause excessive memory consumption.
We now limit the number of query parameters parsed to 10000 by default.
The limit can be adjusted by setting GODEBUG=urlmaxqueryparams=<n>.
Setting urlmaxqueryparams to 0 disables the limit.
Thanks to jub0bs for reporting this issue.
Fixes#77101
Fixes CVE-2025-61726
Change-Id: Iee3374c7ee2d8586dbf158536d3ade424203ff66
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/3020
Reviewed-by: Nicholas Husin <husin@google.com>
Reviewed-by: Neal Patel <nealpatel@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/736712
Auto-Submit: 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>
In various situations, the toolchain invokes VCS commands. Some of these
commands take arbitrary input, either provided by users or fetched from
external sources. To prevent potential command injection vulnerabilities
or misinterpretation of arguments as flags, this change updates the VCS
commands to use various techniques to separate flags from positional
arguments, and to directly associate flags with their values.
Additionally, we update the environment variable for Mercurial to use
`HGPLAIN=+strictflags`, which is the more explicit way to disable user
configurations (intended or otherwise) that might interfere with command
execution.
We also now disallow version strings from being prefixed with '-' or
'/', as doing so opens us up to making the same mistake again in the
future. As far as we know there are currently ~0 public modules affected
by this.
While I was working on cmd/go/internal/vcs, I also noticed that a
significant portion of the commands being implemented were dead code.
In order to reduce the maintenance burden and surface area for potential
issues, I removed the dead code for unused commands.
We should probably follow up with a more structured change to make it
harder to accidentally re-introduce these issues in the future, but for
now this addresses the issue at hand.
Thanks to splitline (@splitline) from DEVCORE Research Team for
reporting this issue.
Fixes CVE-2025-68119
Fixes#77099
Change-Id: I9d9f4ee05b95be49fe14edf71a1b8e6c0784378e
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/3260
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Nicholas Husin <husin@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/736710
Auto-Submit: 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>
Once a tls.Config is used, it is not safe to mutate. We provide the
Clone method in order to allow users to copy and modify a Config that
is in use.
If Config.SessionTicketKey is not populated, and if
Config.SetSessionTicketKeys has not been called, we automatically
populate and rotate session ticket keys. Clone was previously copying
these keys into the new Config, meaning that two Configs could share
the same auto-rotated session ticket keys. This could allow sessions to
be resumed across different Configs, which may have completely different
configurations.
This change updates Clone to not copy the auto-rotated session ticket
keys.
Additionally, when resuming a session, check that not just that the leaf
certificate is unexpired, but that the entire certificate chain is still
unexpired.
Fixes#77113
Fixes CVE-2025-68121
Change-Id: I011df7329de83068d11b3f0c793763692d018a98
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/3300
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Nicholas Husin <husin@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/736709
Auto-Submit: 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>
Currently, all FMA operations are marked as requiring AVX512, even on
smaller vector widths. This is happening because the narrower FMA
operations are marked as extension "FMA" in the XED. Since this
extension doesn't start with "AVX", we filter them out very early in
the XED process. However, this is just a quirk of naming: the FMA
feature depends on the AVX feature, so it is part of AVX, even if it
doesn't say so on the tin.
Fix this by accepting the FMA extension and adding FMA to the table of
CPU features. We also tweak internal/cpu slightly do it correctly
enforces that the logical FMA feature depends on both the FMA and AVX
CPUID flags.
This actually *deletes* a lot of generated code because we no longer
need the AVX-512 encoding of these 128- and 256-bit operations.
Change-Id: I744a18d0be888f536ac034fe88b110347622be7e
Reviewed-on: https://go-review.googlesource.com/c/go/+/736160
Auto-Submit: Austin Clements <austin@google.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/736201
Reviewed-by: Austin Clements <austin@google.com>
This simplifies our handling of XED features, adds a table of which
features imply which other features, and adds this information to the
documentation of the CPU features APIs.
As part of this we fix an issue around the "AVXAES" feature. AVXAES is
defined as the combination of the AVX and AES CPUID flags. Several
other features also work like this, but have hand-written logic in
internal/cpu to compute logical feature flags from the underlying
CPUID bits. For these, we expose a single feature check function from
the SIMD API.
AVXAES currently doesn't work like this: it requires the user to check
both features. However, this forces the SIMD API to expose an "AES"
feature check, which really has nothing to do with SIMD. To make this
consistent, we introduce an AVXAES feature check function and use it
in feature requirement docs. Unlike the others combo features, this is
implemented in the simd package, but the difference is invisible to
the user.
Change-Id: I2985ebd361f0ecd45fd428903efe4c981a5ec65d
Reviewed-on: https://go-review.googlesource.com/c/go/+/736100
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/736200
Reviewed-by: Austin Clements <austin@google.com>
This makes it easier to identify which functions are used for memory
allocation by looking for functions that start with mallocgc. The Size
suffix is added so that the isSpecializedMalloc function in
cmd/compile/internal/ssa can distinguish between the generated functions
and the mallocgcTiny function called by mallocgc, similar to the SC
suffixes for the mallocgcSmallNoScanSC* and mallocgcSmallScanNoHeaderSC*
functons.
Change-Id: I6ad7f15617bf6f18ae5d1bfa2a0b94e86a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/735780
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Calls to dupSocket may fail, but the error is not properly handled
because the surrounding code incorrectly checks for nil error instead
of non-nil error.
I'm not aware of any code paths that would trigger this error, and
I haven't been able to create a test case that does so, but this
change fixes the error handling to correctly propagate any errors
from dupSocket.
Change-Id: I5ffd3cbe8ed58a83634f3b97c0878a7c73e0505e
Reviewed-on: https://go-review.googlesource.com/c/go/+/734821
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
- introduce subtitles to make various sub-sections easier to find
- split rules for struct literals into two groups (literals without
and with keys)
- move section on syntax ambiguity up as it pertains to the syntax
introduced at the start
- move prose specific to map literals into its own section
No language changes.
Change-Id: If8895b869138693179ca6e4d8b1c6ebdc705eccf
Reviewed-on: https://go-review.googlesource.com/c/go/+/734322
Reviewed-by: Alan Donovan <adonovan@google.com>
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>
We manipulate the dependencies of the build action when adding the
non-test variant of the package being tested as a dependency for the
test, so the set of deps of the build package doesn't correctly
represent the dependencies of the package that have been built. Restrict
the set of dependencies we use to populate the vet data to the actual
build dependencies depended on by the check cache action so we don't
check an action that we don't actually depend on (and which may not have
completed yet!)
Fixes#75380
Change-Id: I029080d00b3b10a837abcfb7039e00206a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/734961
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently the Broadcast128/256/512 methods broadcast the lowest
element of the input vector to a vector of the corresponding width.
There are also variations of broadcast operations that broadcast
the whole (128- or 256-bit) vector to a larger vector, which we
don't yet support. Our current naming is unclear which version it
is, though. Rename the current ones to Broadcast1ToN, to be clear
that they broadcast one element. The vector version probably will
be named BoradcastAllToN (not included in this CL).
Change-Id: I47a21e367f948ec0b578d63706a40d20f5a9f46d
Reviewed-on: https://go-review.googlesource.com/c/go/+/734840
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Exposition is also added to outline a difference between syntax which
can / cannot produce values of incomplete types.
For us to enforce non-nilness of type RHS and remove the pending type
mechanism, I suspect we would need to add completeness guards to
the syntax which *can*.
Enforcing non-nilness of type RHS currently breaks the below test
cases, but I suspect that is simply an implementation artifact.
In other words, they just call Underlying at a bad time.
- T0
- T3
- T6 / T7
- T10
- T12
If we also remove pendingType, all of these test cases break; again,
we would need guards in the appropriate syntax logic.
Change-Id: Ibe22042232e542de1d38b923dd1d5cc50dce08cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/734600
TryBot-Bypass: Mark Freeman <markfreeman@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Mark Freeman <markfreeman@google.com>
To allow this, we also increase the size of the pool to allow the
minimum number for each action, with an extra 2*GOMAXPROCS number of
tokens to boost -c when there are fewer concurrently running actions.
That means the pool will now have the size 6*GOMAXPROCS instead of the
previous 4*GOMAXPROCS.
The goal is to maintain the boosting behavior added by the pool, while
guarding from starving compiles when there are too few tokens left, so
that the value of -c is always at least min(4,GOMAXPROCS), which is what
it was set to before Go 1.26.
Cq-Include-Trybots: luci.golang.try:gotip-linux-arm64_c4as16-perf_vs_parent,gotip-linux-arm64_c4ah72-perf_vs_parent,gotip-linux-amd64_c3h88-perf_vs_parent,gotip-linux-amd64_c2s16-perf_vs_parent
Change-Id: I113a38584514a6c025d3d1bc727ff8d86a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/734040
Commit-Queue: Michael Matloob <matloob@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Bypass: Michael Matloob <matloob@google.com>
Reviewed-by: Michael Matloob <matloob@google.com>
This fixes a bug where we only incremented concurrentProcesses but never
decremented it, causing us to run out of tokens and give all compiles
-c=1 after a point.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64_c2s16-perf_vs_parent,gotip-linux-amd64_c3h88-perf_vs_parent,gotip-linux-arm64_c4ah72-perf_vs_parent,gotip-linux-arm64_c4as16-perf_vs_parent
Change-Id: I41f4c1edb77004cbc1772d6d672045946a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/734260
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Matloob <matloob@google.com>
TryBot-Bypass: Michael Matloob <matloob@google.com>
Pull in the following x/tools changes:
- CL 732260: go/analysis/passes/modernize: disable BLoop analyzer
- CL 733340: gopls/internal/analysis/modernize: mapsloop: undefined loop-var
For #74967.
For #77008.
[git-generate]
go install golang.org/x/build/cmd/updatestd@latest
go install golang.org/x/tools/cmd/bundle@latest
updatestd -goroot=$(pwd) -branch=internal-branch.go1.26-vendor
Change-Id: Ic0c10569a4a3a292aec9164e6dd034e55d052904
Reviewed-on: https://go-review.googlesource.com/c/go/+/733780
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>
Reviewed-by: Cherry Mui <cherryyz@google.com>
An atomic.Bool isn't necessary here since, unless otherwise
specified, the methods of an object are not concurrency-safe
w.r.t. each other. Using an atomic causes the copylocks vet
check to warn about copying of Cmd, which is not wrong, because
one shouldn't be copying opaque complex structs from other
packages, but it is a nuisance in the absence of any safe way
to copy a Cmd.
If and when we add a Clone method to Cmd (see #77075) then
it would be appropriate to revert this change so that we get
the benefit of the static check (though ideally we would make
a more explicit tool-readable declaration of the "do not copy"
attribute than merely happening to use an atomic.Bool).
For #77075
Change-Id: I982d4e86623ca165a3e76bbf648fd44041d5f6bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/734200
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
VPMOVMSKB, VMOVMSKPS, and VMOVMSKPD moves AVX1/2-style masks to
integer registers, similar to VPMOV[BWDQ]2M (which moves to mask
registers). The former is available on AVX1/2, the latter requires
AVX512. So use the former if it is supported, i.e. for 128- and
256-bit vectors with 8-, 32-, and 64-bit elements (16-bit elements
always require AVX512).
Change-Id: I972195116617ed2faaf95cee5cd6b250e671496c
Reviewed-on: https://go-review.googlesource.com/c/go/+/734060
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Currently, the IsNan API is defined as x.IsNan(y), which returns
a mask to represent, for each element, either x or y is NaN.
Albeit closer to the machine instruction, this is weird API, as
IsNaN is a unary operation. This CL changes it to unary, x.IsNaN().
It compiles to VCMPPS $3, x, x (or VCMPPD). For the two-operand
version, we can optimize x.IsNaN().Or(y.IsNaN()) to VCMPPS $3, x,
y (not done in this CL).
While here, change the name to IsNaN (uppercase both Ns), which
matches math.IsNaN.
Tests in the next CL.
Change-Id: Ib6e7afc2635e6c3c606db5ea16420ee673a6c6d6
Reviewed-on: https://go-review.googlesource.com/c/go/+/733660
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
adonovan pointed out this bug in the review of CL 733320 and this seems
to be the cause of all those list_empty_importpath flakes. It makes
sense that something nondeterministic would be tied up with the module
index because the state of the cache could depend on the order tests are
run in.
Also remove the parts of the test that accept the flaky behavior so we
can verify the issue has been resolved.
For #73976
Change-Id: Ib64ce6b8eed1dc8d327b7c5e842c1e716a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/733321
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Auto-Submit: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
Fix a pattern in test/codegen/comparisons.go to use whitespace instead
of a tab. The test needs a whitespace to properly fail if the regalloc
change from CL686655 would be missing (in that case we would have a
spill immediately after call to memequal, which is supposed to be
captured by this pattern).
Change-Id: I5b6fb5e861b9327c7f071660592b8ffa265e0030
Reviewed-on: https://go-review.googlesource.com/c/go/+/727620
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
The rangefunc rewrite pass implements defer using deferrangefunc and
deferproccat. The loop body is rewritten into a closure, it cannot be
inlined due to defer call. But the outer function may still be inlined
in certain scenarios (e.g., with PGO), leading to the defer executing
at the wrong time.
Fixes#77033
Change-Id: I4649fad5cd1b65891832523522002d9352711123
Reviewed-on: https://go-review.googlesource.com/c/go/+/732140
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The test is designed to ensure that behavior introduced in Go 1.23
to garbage collect async timed channels is working correctly. If
GO111MODULE=off is set (or GODEBUG=asynctimerchan=1) Go reverts to the
Go 1.20 behavior of not garbage collecting these channels, which fails
the test.
Instead of running a test in conditions where we know it will fail,
just skip the test. A more comprehensive test does not make sense
right now because this code may go away soon.
Fixes#76948.
Change-Id: Ib186abd2ea583a06b5c246bfd6df932522cf7f1e
Reviewed-on: https://go-review.googlesource.com/c/go/+/732100
Reviewed-by: Nicholas Husin <husin@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
CL 726964 has two bugs.
One is fairly obvious. Where there was previous a decrement of
nGsyscallNoP in exitsyscallTryGetP, it added a call to addGSyscallNoP.
Oops.
The other is more subtle. In needm we set isExtraInC to false very
early. This will cause exitsyscall (via cgocallbackg) to decrement
nGsyscallNoP when the thread never had a corresponding increment. (It
could not have, otherwise it would not have called needm, on Linux
anyway.) The fix is simple: increment nGsyscallNoP. CL 726964 actually
removed this increment erroneously. I'm pretty sure I removed it because
the first bug was the real issue, and removing this increment "fixed it"
in the context of the test. I was right that this case was subtle, but
wrong about how.
Fixes#76435.
Change-Id: I1ff1dfbf43bd4cf536b0965da370fee58e3f8753
Reviewed-on: https://go-review.googlesource.com/c/go/+/732320
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Previously it would return an error only if the first call
resulted in process creation, contra the intent of the
comment at exec.Cmd:
// A Cmd cannot be reused after calling its [Cmd.Start], [Cmd.Run],
// [Cmd.Output], or [Cmd.CombinedOutput] methods.
Also, clear the Cmd.goroutines slice in case of failure to
start a process, so that the closures can be GC'd and their
pipe fds finalized and closed.
Fixes#76746
Change-Id: Ic63a4dced0aa52c2d4be7d44f6dcfc84ee22282c
Reviewed-on: https://go-review.googlesource.com/c/go/+/728642
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
The DotProductQuadruple methods are currently defined on Int8
vectors. There are some problems for that.
1. We defined a DotProductQuadrupleSaturated method, but the dot
product part does not need saturation, as it cannot overflow. It
is the addition part of VPDPBUSDS that does the saturation.
Currently we have optimization rules like
x.DotProductQuadrupleSaturated(y).Add(z) -> VPDPBUSDS
which is incorrect, in that the dot product doesn't do (or need)
saturation, and the Add is a regular Add, but we rewrite it to a
saturated add. The correct rule should be something like
x.DotProductQuadruple(y).AddSaturated(z) -> VPDPBUSDS
2. There are multiple flavors of DotProductQuadruple:
signed/unsigned × signed/unsigned, which cannot be completely
disambiguated by the type. The current naming may preclude adding
all the flavors.
For these reasons, remove the methods for now. We can add them
later with the issues addressed.
Change-Id: I549c0925afaa68c7e2cc956105619f2c1b46b325
Reviewed-on: https://go-review.googlesource.com/c/go/+/731441
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
They operate on 128-bit groups, so name them Grouped to be clear,
and consistent with other grouped operations. Reword the
documentation, mention the grouping only for grouped versions.
Also, SaturateToUnt16Concat(Grouped) is a signed int32 to unsigned
uint16 saturated conversion. The receiver and the parameter should
be signed. The result remains unsigned.
Change-Id: I30e28bc05e07f5c28214c9c6d9d201cbbb183468
Reviewed-on: https://go-review.googlesource.com/c/go/+/731501
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This is a pain to test.
Also the original test was never executed, because it was wrong.
It looks like processors that might lack this features
include Intel 11th generation and AMD Zen 4. These might
or might not have bit 2 set in the 7th cpuid "leaf" (SM4)
which is what the incorrect test was checking; the bug
is triggered by ^VNNI & SM4. Apparently the SM4 bit is
not usually set, else we would have seen a test failure.
The "Lion Cove" microarchitecture (Arrow Lake, Lunar Lake)
appears to trigger this problem, it's not clear if there are
others. It was hard to verify this from online information.
Fixes#76881.
Change-Id: I21be6b4f47134d81e89799b0f06f89fcb6563264
Reviewed-on: https://go-review.googlesource.com/c/go/+/731240
TryBot-Bypass: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
During a naive attempt to test the new runtime/secret package, I tried
wrapping the entire handshake in a secret.Do call. This lead to a panic
because some of the allocator logic had been previously untested.
freeSpecial takes p and size, but they can be misleading. They don't
refer to the pointer and size of the object with the special attached,
but a pointer to the enclosing object and the size of the span element.
The previous code did not take this into account and when passing the
size to memclr would overwrite nearby objects.
Fix by storing the size of the object being cleared inside the special.
Fixes#76865.
Change-Id: Ifae31f1c8d0609a562a37f37c45aec2f369dc6a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/730361
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
The discussion at #76477 warranted some stronger documentation about
what is expected from users of the secret package. In addition, #76764
presented a problem about when a user can expect their secrets to be
deleted.
Fix by loosening the guarantee to when all allocations from within a
secret function have been deemed unreachable. Provide some guidance for
users to steer them away from situations where allocations live on for
long after the secret function has finished executing
Fixes#76764.
Updates #76477.
Change-Id: I0cef3e7275737f32ec48f71355e588b3be26ea32
Reviewed-on: https://go-review.googlesource.com/c/go/+/728921
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
For TLS 1.3, after procesesing the server/client hello, if there isn't a
CCS message, reject the trailing messages which were appended to the
hello messages. This prevents an on-path attacker from injecting
plaintext messages into the handshake.
Additionally, check that we don't have any buffered messages before we
switch the read traffic secret regardless, since any buffered messages
would have been under an old key which is no longer appropriate.
We also invert the ordering of setting the read/write secrets so that if
we fail when changing the read secret we send the alert using the
correct write secret.
Fixes#76443
Fixes CVE-2025-61730
Change-Id: If6ba8ad16f48d5cd5db5574824062ad4244a5b52
Reviewed-on: https://go-review.googlesource.com/c/go/+/724120
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Coia Prant <coiaprant@gmail.com>
Some tests require enabling specific Go experiments via the GOEXPERIMENT
, like "jsonv2", "runtimesecret", or "simd".
When running these tests, we should preserve any existing GOEXPERIMENT
settings, so that multiple experiments can be tested together.
I've found this limitation while working in my own Go fork, where in
some situations I pass additional experiments to the tests that alter
the Go runtime and other core packages.
Change-Id: Ib0324cd93282f6993611dea2f0c57d00ab304a33
Reviewed-on: https://go-review.googlesource.com/c/go/+/730360
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
On 386, in some build modes we need to create the __x86.get_pc_thunk
symbols, to support PC-relative addressing. In some situation
the thunk symbols may already exist, e.g. loaded from a C object
in internal linking mode. In this case, we should use the exiting
symbol instead of making a new one. The current code updates the
symbol content in place but also adds a duplicated entry to Textp,
which breaks the address sorting order.
Fixes#76815.
Change-Id: Iab11106ce592dc5219b7a0e07cfafcd270661a2f
Reviewed-on: https://go-review.googlesource.com/c/go/+/730161
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The go doc command now displays the comparable constraint when embedded
in an interface, matching the existing behavior for the error type.
Previously, when an interface embedded comparable, it was not shown in
the documentation and incorrectly triggered the "Has unexported methods"
message even when no unexported methods existed.
Fixes#76125
Change-Id: Idaae07fcb1dfc79b1fae374f9fc68df0052ff38e
Reviewed-on: https://go-review.googlesource.com/c/go/+/727100
Reviewed-by: Sean Liao <sean@liao.dev>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
A stackObjectRecord should always be in funcdata, between gofunc
and the end of pclntab, except for the special case of
methodValueCallFrameObjs, which should always be in noptrbss.
Adjust the two loops that look for the moduledata corresponding
to a stackObjectRecord to search more precisely, rather than
relying on datap.end.
Closely based on a patch by Michael Stapelberg.
For #76038
Change-Id: I751801d8fd030af751825a67905b2a343280e7d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/728840
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>
During review of CL 704615, a suggestion was made that spawning a
goroutine inside a call to secret.Do result in a panic. I agreed with
this at the time, but had missed that this had been extensively
discussed on the proposal. Revert the behavior back to what was agreed
upon.
Change-Id: Ifaa9e24bd03ecbd870ae2217137d1a9527c96842
Reviewed-on: https://go-review.googlesource.com/c/go/+/728920
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Because we dropg before emitting a trace event in preemptPark, we end up
failing to emit a status for the goroutine if this happens to be the
first event for it in the generation. We only really see this with
multiple subscribers in TestSubscribers.
This is for two reasons:
1. If we are missing a status event for a non-initial generation then
the trace parser won't validate that (an oversight, but we can only
enforce that for new traces because of this bug), and
2. If we're starting the tracer fresh, then we have a STW which
effectively guarantees that the first event for a goroutine cannot
come from preemptPark.
Therefore, we cannot observe this situation unless the first generation
manifests the bug, but prior to having flight recording and/or multiple
subscribers being able to "cut" the trace data at any point, this was
impossible.
The fix is simple: dropg only after emitting the trace event. This is
also safe, because the tracer doesn't care. The tracer will also start
taking a stack trace of the goroutine in this circumstance, but that is
also safe, since we are able to generally unwind the stack of
asynchronously preempted goroutines, and here we're at the very, very
end of asynchronous preemption where all the state to do so is already
set up.
Fixes#75665.
Change-Id: I7ee1142697d0a53b62d4c5647aa53775d2f6976a
Reviewed-on: https://go-review.googlesource.com/c/go/+/729400
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Issue #76540 reports failures in this test from the leaked goroutine
count being too small. The test makes an effort to wait for the
goroutines to leak, but there's no guarantee.
This change instead changes TestGoroutineLeakProfileConcurrency to wait
for the number of leaked goroutines to reach at least the minimum
expected before proceeding. This deflakes this particular issue.
The downside of this change is that a failure to detect leaked
goroutines due to a bug will lead to a timeout instead of an instant
failure, but this change makes an effort to log and report that it was
waiting for the goroutines to leak and timed out for that reason, so at
least the failure is more obvious.
Overall, this is still better than random flakes.
While we're here, I also make some minor stylistic changes and document
the helper functions a little more. I also noticed that checkFrames was
using the wrong *testing.T, so this change fixes that too.
Fixes#76540.
Change-Id: I0508855dc39b91f8c6b72d059ce88dbfc68fe748
Reviewed-on: https://go-review.googlesource.com/c/go/+/729280
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Update the blocklist with new linknames added in Go 1.26.
Some goroutine leak profile symbols were manually added but they
did not match the actual symbol names. Corrected.
runtime.freegc is not itself push-linknamed, so there is no need
to explicitly add it to blocklist. Keep the test, to ensure one
cannot linkname-pull freegc.
Change-Id: Ie5fd6bc191e9afa164fa79055cc39e6fa9ed4c7f
Reviewed-on: https://go-review.googlesource.com/c/go/+/729720
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Currently TestFinalizerOrCleanupDeadlock runs a bunch of tests for both
cleanups and finalizers. However, it doesn't actually distinguish these
two cases in the subtest names. This change adds another layer of
subtest to distinguish them.
For #76523.
Change-Id: I18c2857e970cde43c18cbbcbc44e4d4ada3b2628
Reviewed-on: https://go-review.googlesource.com/c/go/+/728821
Reviewed-by: Carlos Amedee <carlos@golang.org>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Bypass: Michael Knyszek <mknyszek@google.com>
This reverts CL 588435.
This new API is difficult to use correctly, and in many cases cannot
be used efficiently. We're going to work on this problem a bit more.
The release notes are removed by CL 729340, since they were moved to
the x/website repository since the original CL was made.
Reopens#67546.
Change-Id: I2a2bd25f2fce5f02e4d28cd33a9cc651bf35ab50
Reviewed-on: https://go-review.googlesource.com/c/go/+/729360
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Sean Liao <sean@liao.dev>
Currently we don't break out of the loop on a failure. This is
leading to timeouts trying to parse a broken trace over and over,
forever.
But there's another issue where when we try to dump the trace, we pass
only the unread portion of the bytes.Buffer.
Change-Id: I1a338eea08eaf7f592fb7dd2a736a6fe0728c62d
Reviewed-on: https://go-review.googlesource.com/c/go/+/729320
Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently, between the forEachP that ensures every P has a status in the
trace and readying dead Ps for the next generation, there's a big window
where GOMAXPROCS could run and change the number of Ps. In such
circumstances, P state will not get properly prepared for the next
generation, and we may fail to emit a status for a P.
This change addresses the problem by holding worldsema across both
operations. It also moves the status emission and state clearing to
before the generation transition because that makes the code *much*
clearer.
Currently we do both these things after the generation transition
targeting the next-next generation. The reason for this is to avoid an
extra forEachP (because we already handle P status in the STW for
enabling tracing to begin with) but approach is just plain harder to
reason about. Preparing the next generation before transitioning to it,
like we do for goroutines, is much clearer. Furthermore, we also need to
set up the dead P state even if we're stopping the trace, which would
mean duplicating code into both branches (if stopping the trace, then we
go non-preemptible, otherwise we do it under worldsema) which is also
less clear.
Note that with this change we no longer need to emit the P statuses
during the STW, which was probably the worse choice anyway, since
holding up the STW for an O(P) operation is worse than a forEachP we're
going to do anyway. So, this change does away with that too.
Fixes#76572.
Change-Id: Ie7908adff43a8a372cae432bcc2f4e0d6a87d7bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/729023
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Currently the trace summarization incorrectly handles GoUndetermined by
treating it too much like GoNotExist. In particular, it should be
accumulating all the time since the start of the trace in a particular
bucket, but it doesn't, so that instead gets counted as "unknown time"
because the "creation time" is at the start of the trace.
This change fixes the problem by simply doing the accumulation. It's
very straightforward. It also side-steps some other inaccuracies, like
associating a goroutine that is being named with the current task. I
don't think this can ever actually happen in practice, but splitting up
the two cases, GoUndetermined and GoNotExist, fixes it.
Fixes#76716.
Change-Id: I3ac1557044f99c92bada2cb0e124b2192b1d6ebb
Reviewed-on: https://go-review.googlesource.com/c/go/+/728822
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Nick Ripley <nick.ripley@datadoghq.com>
When we first implemented DIT (crypto/subtle.WithDataIndependentTiming),
we made it so that enabling DIT on a goroutine would lock that goroutine
to its current OS thread. This was done to ensure that the DIT state
(which is per-thread) would not leak to other goroutines. We also did
not make goroutines inherit the DIT state.
This change makes goroutines inherit the DIT state from their parent
at creation time. It also removes the OS thread locking when enabling
DIT on a goroutine. Instead, we now set the DIT state on the OS thread
in the scheduler whenever we switch to a goroutine that has DIT enabled,
and we unset it when switching to a goroutine that has DIT disabled.
We add a new field to G and M, ditEnabled, to track whether the G wants
DIT enabled, and whether the M currently has DIT enabled, respectively.
When the scheduler executes a goroutine, it checks these fields and
enables/disables DIT on the thread as needed.
Additionally, cgocallbackg is updated to check if DIT is enabled when
being called from C, and sets the G and M fields accordingly. This
ensures that if DIT was enabled/disabled in C, the correct state will be
reflected in the Go runtime.
The behavior as it currently stands is as follows:
- The function passed to crypto/subtle.WithDataIndependentTiming
will have DIT enabled.
- Any goroutine created within that function will inherit DIT enabled
for its lifetime. Any goroutine created from subquent goroutines will
also inherit DIT enabled for their lifetimes.
- Calling into a C function within from a goroutine with DIT enabled
will have DIT enabled.
- If the C code disables DIT, the goroutine will have DIT re-enabled
when returning to Go.
- If the C code enables DIT, the goroutine will have DIT disabled
when returning to Go if it was not previously enabled.
- Calling back into Go code from C will have DIT enabled if it was
enabled when calling into C, or if the C code enabled it.
Change-Id: I8e91e6df13bb88e56e1036e0e0e5f04efd8eebd3
Reviewed-on: https://go-review.googlesource.com/c/go/+/726382
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
The enforcement is good beyond compliance if it is correct, but I am
more nervous about accidental DoS due to mismatches between how the
caller calculates a nonce and how the enforcement expects it to be
calculated.
We need to have this enforcement in FIPS 140-3 mode, but no need to blow
ourselves up when it's off.
If all goes well, this code is unreachable anyway.
Change-Id: If73ec59ebbd283b0e5506354961a87a06a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/728504
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>
Reviewed-by: David Chase <drchase@google.com>
The cpu/go-acvp repository holding trimmed ACVP test server vectors and
validated expected results was always meant to be a temporary home. It
has now been migrated to geomys/acvp-testdata where it will continue to
be maintained by Geomys along with the FIPS module.
This commit updates acvp_test.go to use the new module location.
Change-Id: I888b125356afd0b4073cb38645486c258dea3c54
Reviewed-on: https://go-review.googlesource.com/c/go/+/725620
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Auto-Submit: Daniel McCarney <daniel@binaryparadox.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
On AIX, all externally linked programs call _rt0_ppc64_aix_lib,
as seen in runtime/cgo/gcc_aix_ppc64.c. The idea is that we
only do the library initialization is isarchive is set.
However, before this CL, AIX programs would call libpreinit
before checking isarchive. The effect was that signals were
initialized twice. That caused the signal code to record that
all signals had an existing forwarding address, namely the
Go signal handler that was always installed. This caused signal
forwarding to enter an infinite loop. This caused, for example,
"go test os" to hang forever when running TestStdPipe.
Fixes#76081
Change-Id: I5555f8c5e299d45549f5ce601568dc6b3cff4ecc
Reviewed-on: https://go-review.googlesource.com/c/go/+/727820
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Each type must be representable by a finite amount of Go source code
after replacing all alias type names, value names, and embedded
interfaces (per #56103) with the RHS from their respective declarations
("expansion"); otherwise the type is invalid.
Furthermore, each type must have a finite size.
Checking for finite source after expansion is handled in decl.go.
Checking for finite size is handled in validtype.go and is delayed to
the end of type checking (unless used in unsafe.Sizeof, in which case
it is computed eagerly).
We can only construct values of valid types. Thus, while a type is
pending (on the object path and thus not yet valid), it cannot construct
a value of its own type (directly or indirectly).
This change enforces the indirect case by validating each type at value
observance (and hence upholding the invariant that values of only valid
types are created). Validation is cached on Named types to avoid
duplicate work.
As an example, consider:
type A [unsafe.Sizeof(B{})]int
type B A
Clearly, since there are no aliases, A and B have finite source. At the
site of B{}, B will be checked for finite size, recursing down the
values of B, at which point A is seen. Since A is on the object path,
there is a cycle preventing B from being proven valid before B{},
violating our invariant.
Note that this change also works for generic types.
Fixes#75918Fixes#76478
Change-Id: I76d493b5da9571780fed4b3c76803750ec184818
Reviewed-on: https://go-review.googlesource.com/c/go/+/726580
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>
This commit is a REVERSE MERGE.
It merges dev.simd back into its parent branch, master.
This marks the end of development on dev.simd.
Merge List:
+ 2025-12-08 c456ab7a30 [dev.simd] all: merge master (a33bbf1) into dev.simd
+ 2025-12-08 1d8711e126 [dev.simd] internal/buildcfg: don't enable SIMD experiment by default
+ 2025-12-08 f38e968aba [dev.simd] cmd/compile: zero only low 128-bit of X15
+ 2025-12-08 144cf17d2c [dev.simd] simd, cmd/compile: move "simd" to "simd/archsimd"
+ 2025-12-08 3417b48b17 [dev.simd] simd: add carryless multiply
+ 2025-12-05 f51ee08905 [dev.simd] simd: replace checking loops with call to slice-checker
+ 2025-12-03 2b91d96941 [dev.simd] internal/buildcfg: turn GOEXPERIMENT=simd back on
Change-Id: Ife3f2ca4f6d8ce131335c0f868358db6a6a1a534
Merge List:
+ 2025-12-08 a33bbf1988 weak: fix weak pointer test to correctly iterate over weak pointers after GC
+ 2025-12-08 a88a96330f cmd/cgo: use doc link for cgo.Handle
+ 2025-12-08 276cc4d3db cmd/link: fix AIX builds after recent linker changes
+ 2025-12-08 f2d96272cb runtime/trace: update TestSubscribers to dump traces
+ 2025-12-08 4837bcc92c internal/trace: skip tests for alloc/free experiment by default
+ 2025-12-08 b5f6816cea cmd/link: generate DWARF for moduledata
+ 2025-12-08 44a39c9dac runtime: only run TestNotInGoMetricCallback when building with cgo
+ 2025-12-08 3a6a034cd6 runtime: disable TestNotInGoMetricCallback on FreeBSD + race
+ 2025-12-08 4122d3e9ea runtime: use atomic C types with atomic C functions
+ 2025-12-08 34397865b1 runtime: deflake TestProfBufWakeup
+ 2025-12-08 d4972f6295 runtime: mark getfp as nosplit
+ 2025-12-05 0d0d5c9a82 test/codegen: test negation with add/sub on riscv64
+ 2025-12-05 2e509e61ef cmd/go: convert some more tests to script tests
+ 2025-12-05 c270e71835 cmd/go/internal/vet: skip -fix on pkgs from vendor or non-main mod
+ 2025-12-05 745349712e runtime: don't count nGsyscallNoP for extra Ms in C
+ 2025-12-05 f3d572d96a cmd/go: fix race applying fixes in fix and vet -fix modes
+ 2025-12-05 76345533f7 runtime: expand Pinner documentation
+ 2025-12-05 b133524c0f cmd/go/testdata/script: skip vet_cache in short mode
+ 2025-12-05 96e142ba2b runtime: skip TestArenaCollision if we run out of hints
+ 2025-12-05 fe4952f116 runtime: relax threadsSlack in TestReadMetricsSched
+ 2025-12-05 8947f092a8 runtime: skip mayMoreStackMove in goroutine leak tests
+ 2025-12-05 44cb82449e runtime/race: set missing argument frame for ppc64x atomic And/Or wrappers
+ 2025-12-05 435e61c801 runtime: reject any goroutine leak test failure that failed to execute
+ 2025-12-05 54e5540014 runtime: print output in case of segfault in goroutine leak tests
+ 2025-12-05 9616c33295 runtime: don't specify GOEXPERIMENT=greenteagc in goroutine leak tests
+ 2025-12-05 2244bd7eeb crypto/subtle: add speculation barrier after DIT
+ 2025-12-05 f84f8d86be cmd/compile: fix mis-infer bounds in slice len/cap calculations
+ 2025-12-05 a70addd3b3 all: fix some comment issues
+ 2025-12-05 93b49f773d internal/runtime/maps: clarify probeSeq doc comment
+ 2025-12-04 91267f0a70 all: update vendored x/tools
+ 2025-12-04 a753a9ed54 cmd/internal/fuzztest: move fuzz tests out of cmd/go test suite
+ 2025-12-04 1681c3b67f crypto: use rand.IsDefaultReader instead of comparing to boring.RandReader
+ 2025-12-04 7b67b68a0d cmd/compile: use isUnsignedPowerOfTwo rather than isPowerOfTwo for unsigneds
+ 2025-12-03 2b62144069 all: REVERSE MERGE dev.simd (9ac524a) into master
Change-Id: Ia0cdf06cdde89b6a4db30ed15ed8e0bcbac6ae30
This change fixes a bug in the weak pointer test where the loop was
attempting to iterate over a nil slice (bt) instead of the weak
pointer slice (wt).
After setting bt to nil and running GC, the test should iterate over
the weak pointers to verify they've been cleared, not attempt to
iterate over the now-nil strong references.
Change-Id: Ic0425f59da132257770ed87d1bcea5d2c0a54e07
Reviewed-on: https://go-review.googlesource.com/c/go/+/723600
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Sean Liao <sean@liao.dev>
This updates XCOFF-specific code for the recent addition
of funcdata to pclntab.
Because XCOFF puts separate symbols into separate csects,
each with their own alignment, it's important to tell the
external linker the expected alignment of each part of pclntab.
Otherwise the offsets within pclntab may change as the external
linker aligns symbols. This CL sets the correct alignment for
each pclntab child symbol, and sets pclntab's alignment to the
max of that of its children.
Tested on the GCC compile farm.
Fixes#76486
Change-Id: I77d8a90c4b4b79d80ca11ede8d9a2aa9cc89f53f
Reviewed-on: https://go-review.googlesource.com/c/go/+/725603
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
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>
Also removes a few leftover TODOs and scraps of commented-out code
from simd development.
Updated etetest.sh to make it behave whether amd64 implies the
experiment, or not.
Fixes#76473.
Change-Id: I6d9792214d7f514cb90c21b101dbf7d07c1d0e55
Reviewed-on: https://go-review.googlesource.com/c/go/+/728220
TryBot-Bypass: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
If CI infrastructure is oversubscribed, the profile buffer reader can be
blocked long enough for the status in the traceback to be something like
"[syscall, 3 minutes]", rather than the "[syscall]" we are looking for.
Tweak the regexp to look for the expected state at the beginning of the
status in the brackets.
While we're here, clarify the possible "race" in the test, which has
more to do with failing to catch a buggy implementation rather than
failing for a correct implementation. Ideally if the implementation is
buggy, we should see the t.Errorf at least some of the time, even if we
don't see it in every run.
Change-Id: Iebd5229d338dc3f973349cea6dd84c506a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/727660
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
In #76435, it turns out that the new metric
/sched/goroutines/not-in-go:goroutines counts C threads that have called
into Go before (on Linux) as not-in-go goroutines. The reason for this
is that the M is still attached to the C thread on Linux as an
optimization, so we don't go through all the trouble of detaching the M
and, of course, decrementing nGsyscallNoP.
There's an easy fix to this accounting issue. The flag on the M,
isExtraInC, says whether a thread with an extra M attached no longer has
any Go on its (logical) stack. When we take the P from an M in this
state, we simply just don't increment nGsyscallNoP. When it calls back
into Go, we similarly skip the decrement to nGsyscallNoP.
This is more efficient than alternatives, like always updating
nGsyscallNoP in cgocallbackg, since that would add a new
read-modify-write atomic onto that fast path. It does mean we count
threads in C with a P still attached as not-in-go, but this transient in
most real programs, assuming the thread indeed does not call back into
Go any time soon.
Fixes#76435.
Change-Id: Id05563bacbe35d3fae17d67fb5ed45fa43fa0548
Reviewed-on: https://go-review.googlesource.com/c/go/+/726964
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Previously, the cmd/fix tool, which is analogous to a compiler
in a "go fix" or "go vet -fix" build, applied its fixes directly
to source files during the build. However, this led to races
since the edits may in some cases occur concurrently with other
build steps that are still reading those source file.
This change separates the computation of the fixes, which
happens during the build, and applying the fixes, which happens
in a phase after the build.
The unitchecker now accepts a FixArchive file name (see CL 726940).
If it is non-empty, the unitchecker will write the fixed files
into an archive instead of updating them directly.
The vet build sets this option, then reads the produced zip
files in the second phase. The files are saved in the cache;
some care is required to sequence the various cache operations
so that a cache hit has all-or-nothing semantics.
The tweak to vet_basic.txt is a sign that there was a latent
bug, inadvertently fixed by this change: because the old approach
relied on side effects of cmd/fix to mutate files, rather than
the current pure-functional approach of computing fixes which
are then applied as a second pass, a cache hit would cause some
edits not to be applied. Now they are applied.
Fixesgolang/go#71859
Change-Id: Ib8e70644ec246dcdb20a90794c11ea6fd420247d
Reviewed-on: https://go-review.googlesource.com/c/go/+/727000
Auto-Submit: Alan Donovan <adonovan@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@google.com>
This change expands the Pinner documentation based on a few points of
feedback.
- We need a note that the Pinner has a finalizer.
- We need a note that the Pinner is safe to reuse.
I also added a note that the zero value is ready to use, and expanded
upon the use-cases of a Pinner.
Fixes#76431.
Change-Id: I312385557e67a815db05def02c1b1d7dcaa9d764
Reviewed-on: https://go-review.googlesource.com/c/go/+/726641
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
This seems failure mode seems to have become more common on Windows. I
suspect the randomized heap base address has something to do with it,
but I'm not 100% sure.
What's definitely certain is that we're running out of hints, since
we're seeing failures that mheap_.arenaHints is nil and GetNextArenaHint
doesn't actually check that.
At the very least we can check that and skip. We know that in this case
there's not that much we can do.
Fixes#76566.
Change-Id: I8ccc8994806b6c95e3157eb296b09705637564b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/726527
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
runtime.GC is called in the test and may spin up GOMAXPROCS
(proportional to the initial count) new threads. We need to be robust to
this, and it happens relatively frequently on some platforms.
We didn't notice this earlier since the heap is so miniscule that
runtime.GC essentially finished instantly without all the threads
getting spun up.
Fixes#76613.
Change-Id: I2af02cb090d5c1c952e4db53ad35895b6f23f638
Reviewed-on: https://go-review.googlesource.com/c/go/+/726642
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
mayMoreStackMove may introduce more scheduler chaos because of all the
stack movement (not as much as mayMoreStackPreempt) so let's disable the
tests here too, since we have evidence that they can produce false
negatives under this configuration. Though we're not 100% sure why this
is happening yet, let's at least stop the flow of flaky failures.
For #75729.
Change-Id: I16d13dba9a61fbd47563b21cbf188e4754f58213
Reviewed-on: https://go-review.googlesource.com/c/go/+/726526
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
The ppc64x TSAN wrappers for atomic And/Or did not initialize R6 with the Go argument frame before calling racecallatomic. Since racecallatomic expects R6 to point to the argument list and dereferences it unconditionally, this led to a nil-pointer dereference under -race.
Other atomic TSAN wrappers (Load/Store/Add/Swap/CAS) already set up R6 in the expected way. This change aligns the And/Or wrappers with the rest by adding the missing R6 initialisation.
This keeps the behavior consistent across all atomic operations on ppc64x.
Fixes#76051.
Change-Id: Iaf578449a6171a0c6f7c33ec6f64c1251297ae6d
Cq-Include-Trybots: luci.golang.try:gotip-linux-ppc64_power10,gotip-linux-ppc64_power8,gotip-linux-ppc64le_power8,gotip-linux-ppc64le_power9,gotip-linux-ppc64le_power10
Reviewed-on: https://go-review.googlesource.com/c/go/+/718560
Reviewed-by: Mark Freeman <markfreeman@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Paul Murphy <paumurph@redhat.com>
The probeSeq doc comment describes the probe sequence as triangular and
gives the formula for terms in the sequence. This formula isn't actually
used in the code, though. List the first few terms of the sequence
explicitly so the connection between the description and the code is
more clear.
Change-Id: I6a6a69648bc94e15df436815c16128ebef3c6eb8
Reviewed-on: https://go-review.googlesource.com/c/go/+/726820
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Several crypto functions accepting a rand parameter skip calling
boringcrypto when the rand is not boring.RandReader.
The new crypto/internal/rand package currently defines its own Reader
that wraps boring.RandReader. That will unintentionally bypass
boringcrypto when used with the aforementioned functions.
Fixes#76672
Change-Id: Ie0c1345530c734a23815f9593590b5d32604f54d
Reviewed-on: https://go-review.googlesource.com/c/go/+/726220
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
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>
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>
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>
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>
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>
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>
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>
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.
goos: linux
goarch: amd64
pkg: runtime
cpu: Intel(R) Xeon(R) CPU @ 2.80GHz
│ old-1bb1f2bf0c │ freegc-8ba7421-ps16 │
│ sec/op │ sec/op vs base │
Append64Bytes/count=1-4 31.09n ± 2% 31.69n ± 1% +1.95% (n=150)
Append64Bytes/count=2-4 73.31n ± 1% 70.27n ± 0% -4.15% (n=150)
Append64Bytes/count=3-4 142.7n ± 1% 124.6n ± 1% -12.68% (n=150)
Append64Bytes/count=4-4 149.6n ± 1% 127.7n ± 0% -14.64% (n=150)
Append64Bytes/count=5-4 277.1n ± 1% 213.6n ± 0% -22.90% (n=150)
Append64Bytes/count=6-4 280.7n ± 1% 216.5n ± 1% -22.87% (n=150)
Append64Bytes/count=10-4 544.3n ± 1% 386.6n ± 0% -28.97% (n=150)
Append64Bytes/count=20-4 1058.5n ± 1% 715.6n ± 1% -32.39% (n=150)
Append64Bytes/count=50-4 2.121µ ± 1% 1.404µ ± 1% -33.83% (n=150)
Append64Bytes/count=100-4 4.152µ ± 1% 2.736µ ± 1% -34.11% (n=150)
Append64Bytes/count=200-4 7.753µ ± 1% 4.882µ ± 1% -37.03% (n=150)
Append64Bytes/count=400-4 15.163µ ± 2% 9.273µ ± 1% -38.84% (n=150)
geomean 601.8n 455.0n -24.39%
│ old-1bb1f2bf0c │ freegc-8ba7421-ps16 │
│ B/op │ B/op vs base │
Append64Bytes/count=1-4 64.00 ± 0% 64.00 ± 0% ~ (n=150)
Append64Bytes/count=2-4 192.0 ± 0% 128.0 ± 0% -33.33% (n=150)
Append64Bytes/count=3-4 448.0 ± 0% 256.0 ± 0% -42.86% (n=150)
Append64Bytes/count=4-4 448.0 ± 0% 256.0 ± 0% -42.86% (n=150)
Append64Bytes/count=5-4 960.0 ± 0% 512.0 ± 0% -46.67% (n=150)
Append64Bytes/count=6-4 960.0 ± 0% 512.0 ± 0% -46.67% (n=150)
Append64Bytes/count=10-4 1.938Ki ± 0% 1.000Ki ± 0% -48.39% (n=150)
Append64Bytes/count=20-4 3.938Ki ± 0% 2.001Ki ± 0% -49.18% (n=150)
Append64Bytes/count=50-4 7.938Ki ± 0% 4.005Ki ± 0% -49.54% (n=150)
Append64Bytes/count=100-4 15.938Ki ± 0% 8.021Ki ± 0% -49.67% (n=150)
Append64Bytes/count=200-4 31.94Ki ± 0% 16.08Ki ± 0% -49.64% (n=150)
Append64Bytes/count=400-4 63.94Ki ± 0% 32.33Ki ± 0% -49.44% (n=150)
geomean 1.991Ki 1.124Ki -43.54%
│ old-1bb1f2bf0c │ freegc-8ba7421-ps16 │
│ allocs/op │ allocs/op vs base │
Append64Bytes/count=1-4 1.000 ± 0% 1.000 ± 0% ~ (n=150)
Append64Bytes/count=2-4 2.000 ± 0% 1.000 ± 0% -50.00% (n=150)
Append64Bytes/count=3-4 3.000 ± 0% 1.000 ± 0% -66.67% (n=150)
Append64Bytes/count=4-4 3.000 ± 0% 1.000 ± 0% -66.67% (n=150)
Append64Bytes/count=5-4 4.000 ± 0% 1.000 ± 0% -75.00% (n=150)
Append64Bytes/count=6-4 4.000 ± 0% 1.000 ± 0% -75.00% (n=150)
Append64Bytes/count=10-4 5.000 ± 0% 1.000 ± 0% -80.00% (n=150)
Append64Bytes/count=20-4 6.000 ± 0% 1.000 ± 0% -83.33% (n=150)
Append64Bytes/count=50-4 7.000 ± 0% 1.000 ± 0% -85.71% (n=150)
Append64Bytes/count=100-4 8.000 ± 0% 1.000 ± 0% -87.50% (n=150)
Append64Bytes/count=200-4 9.000 ± 0% 1.000 ± 0% -88.89% (n=150)
Append64Bytes/count=400-4 10.000 ± 0% 1.000 ± 0% -90.00% (n=150)
geomean 4.331 1.000 -76.91%
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.
goos: linux
goarch: amd64
pkg: runtime
cpu: Intel(R) Xeon(R) CPU @ 2.80GHz
│ old-1bb1f2bf0c │ freegc-8ba7421-ps16 │
│ sec/op │ sec/op vs base │
AppendInt/count=1-4 2.978n ± 0% 2.969n ± 0% -0.30% (p=0.000 n=150)
AppendInt/count=4-4 4.292n ± 3% 4.163n ± 3% ~ (p=0.528 n=150)
AppendInt/count=5-4 33.50n ± 0% 34.93n ± 0% +4.25% (p=0.000 n=150)
AppendInt/count=10-4 76.21n ± 1% 75.67n ± 0% -0.72% (p=0.000 n=150)
AppendInt/count=20-4 150.6n ± 1% 133.0n ± 0% -11.65% (n=150)
AppendInt/count=50-4 284.1n ± 1% 225.6n ± 0% -20.59% (n=150)
AppendInt/count=100-4 544.2n ± 1% 392.4n ± 1% -27.89% (n=150)
AppendInt/count=200-4 1051.5n ± 1% 702.3n ± 0% -33.21% (n=150)
AppendInt/count=400-4 2.041µ ± 1% 1.312µ ± 1% -35.70% (n=150)
AppendInt/count=1000-4 5.224µ ± 2% 2.851µ ± 1% -45.43% (n=150)
AppendInt/count=2000-4 11.770µ ± 1% 6.010µ ± 1% -48.94% (n=150)
AppendInt/count=3000-4 17.747µ ± 2% 8.264µ ± 1% -53.44% (n=150)
geomean 331.8n 246.4n -25.72%
│ old-1bb1f2bf0c │ freegc-8ba7421-ps16 │
│ B/op │ B/op vs base │
AppendInt/count=1-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=150)
AppendInt/count=4-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=150)
AppendInt/count=5-4 64.00 ± 0% 64.00 ± 0% ~ (p=1.000 n=150)
AppendInt/count=10-4 192.0 ± 0% 128.0 ± 0% -33.33% (n=150)
AppendInt/count=20-4 448.0 ± 0% 256.0 ± 0% -42.86% (n=150)
AppendInt/count=50-4 960.0 ± 0% 512.0 ± 0% -46.67% (n=150)
AppendInt/count=100-4 1.938Ki ± 0% 1.000Ki ± 0% -48.39% (n=150)
AppendInt/count=200-4 3.938Ki ± 0% 2.001Ki ± 0% -49.18% (n=150)
AppendInt/count=400-4 7.938Ki ± 0% 4.005Ki ± 0% -49.54% (n=150)
AppendInt/count=1000-4 24.56Ki ± 0% 10.05Ki ± 0% -59.07% (n=150)
AppendInt/count=2000-4 58.56Ki ± 0% 20.31Ki ± 0% -65.32% (n=150)
AppendInt/count=3000-4 85.19Ki ± 0% 27.30Ki ± 0% -67.95% (n=150)
geomean ² -42.81%
│ old-1bb1f2bf0c │ freegc-8ba7421-ps16 │
│ allocs/op │ allocs/op vs base │
AppendInt/count=1-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=150)
AppendInt/count=4-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=150)
AppendInt/count=5-4 1.000 ± 0% 1.000 ± 0% ~ (p=1.000 n=150)
AppendInt/count=10-4 2.000 ± 0% 1.000 ± 0% -50.00% (n=150)
AppendInt/count=20-4 3.000 ± 0% 1.000 ± 0% -66.67% (n=150)
AppendInt/count=50-4 4.000 ± 0% 1.000 ± 0% -75.00% (n=150)
AppendInt/count=100-4 5.000 ± 0% 1.000 ± 0% -80.00% (n=150)
AppendInt/count=200-4 6.000 ± 0% 1.000 ± 0% -83.33% (n=150)
AppendInt/count=400-4 7.000 ± 0% 1.000 ± 0% -85.71% (n=150)
AppendInt/count=1000-4 9.000 ± 0% 1.000 ± 0% -88.89% (n=150)
AppendInt/count=2000-4 11.000 ± 0% 1.000 ± 0% -90.91% (n=150)
AppendInt/count=3000-4 12.000 ± 0% 1.000 ± 0% -91.67% (n=150)
geomean ² -72.76% ²
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>
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#76383Fixes#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>
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>
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>
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>
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>
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>
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>
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>
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.
goos: windows
goarch: amd64
pkg: crypto/cipher
cpu: AMD Ryzen 7 5800H with Radeon Graphics
│ B/s │ B/s vs base
AESCTR/128/50-16 1.377Gi ± 0% 1.384Gi ± 0% +0.51% (p=0.028 n=20)
AESCTR/128/1K-16 6.164Gi ± 0% 6.892Gi ± 1% +11.81% (p=0.000 n=20)
AESCTR/128/8K-16 7.372Gi ± 0% 8.768Gi ± 1% +18.95% (p=0.000 n=20)
AESCTR/192/50-16 1.289Gi ± 0% 1.279Gi ± 0% -0.75% (p=0.001 n=20)
AESCTR/192/1K-16 5.734Gi ± 0% 6.011Gi ± 0% +4.83% (p=0.000 n=20)
AESCTR/192/8K-16 6.889Gi ± 1% 7.437Gi ± 0% +7.96% (p=0.000 n=20)
AESCTR/256/50-16 1.170Gi ± 0% 1.163Gi ± 0% -0.54% (p=0.005 n=20)
AESCTR/256/1K-16 5.235Gi ± 0% 5.391Gi ± 0% +2.98% (p=0.000 n=20)
AESCTR/256/8K-16 6.361Gi ± 0% 6.676Gi ± 0% +4.94% (p=0.000 n=20)
geomean 3.681Gi 3.882Gi +5.46%
The slight slowdown on 50-byte workloads is unrelated to this change,
because such workloads never use ctrBlocks8Asm.
Updates #76061
Change-Id: Idfd628ac8bb282d9c73c6adf048eb12274a41379
GitHub-Last-Rev: 5aadd39351
GitHub-Pull-Request: golang/go#76059
Reviewed-on: https://go-review.googlesource.com/c/go/+/714361
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: AHMAD ابو وليد <mizommz@gmail.com>
Reviewed-by: 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>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
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.
Code size difference (for arm64 linux):
Executable Old .text New .text Change
-------------------------------------------------------
asm 1970420 1969668 -0.04%
cgo 1741220 1740212 -0.06%
compile 8956756 8959428 +0.03%
cover 1879332 1878772 -0.03%
link 2574116 2572660 -0.06%
preprofile 867124 866820 -0.04%
vet 2890404 2888596 -0.06%
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>
This commit continues the injection of the global Fetcher_ variable into
the various function calls that make use of it. The purpose is to
prepare for the eventual removal of the global Fetcher_ variable and
eliminate global state within the modfetch package.
[git-generate]
cd src/cmd/go/internal/modload
rf '
inject modfetch.Fetcher_ commitRequirements
mv readModGraph.fetcher_ readModGraph.f
'
cd ../modfetch
sed -i '
s/for _, f := range fetcher_.workspaceGoSumFiles {/for _, fn := range fetcher_.workspaceGoSumFiles {/
s/fetcher_.sumState.w\[f\] = make(map\[module.Version\]\[\]string)/fetcher_.sumState.w[fn] = make(map[module.Version][]string)/
s/_, err := readGoSumFile(fetcher_.sumState.w\[f\], f)/_, err := readGoSumFile(fetcher_.sumState.w[fn], fn)/
' fetch.go
rf '
mv GoMod.fetcher_ GoMod.f
mv GoMod Fetcher.GoMod
mv readDiskGoMod.fetcher_ readDiskGoMod.f
mv readDiskGoMod Fetcher.readDiskGoMod
mv initGoSum.fetcher_ initGoSum.f
mv initGoSum Fetcher.initGoSum
mv HaveSum.fetcher_ HaveSum.f
mv checkGoMod.fetcher_ checkGoMod.f
mv checkModSum.fetcher_ checkModSum.f
mv WriteGoSum.fetcher_ WriteGoSum.f
mv WriteGoSum Fetcher.WriteGoSum
mv Lookup.fetcher_ Lookup.f
mv Lookup Fetcher.Lookup
'
Change-Id: Ifbe7d6b90b93fd65a7443434035921e6b42dea1c
Reviewed-on: https://go-review.googlesource.com/c/go/+/724241
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@google.com>
This commit begins the injection of the global Fetcher_ variable into
the various function calls that make use of it. The purpose is to
prepare for the eventual removal of the global Fetcher_ variable and
eliminate global state.
[git-generate]
cd src/cmd/go/internal/modfetch
rf '
inject Fetcher_ TidyGoSum
mv haveModSumLocked.fetcher_ haveModSumLocked.f
mv addModSumLocked.fetcher_ addModSumLocked.f
mv tidyGoSum.fetcher_ tidyGoSum.f
mv sumInWorkspaceModulesLocked.fetcher_ sumInWorkspaceModulesLocked.f
'
Change-Id: Iecf736f17d6e63c856355284d09b7982dc9e16b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/724240
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
First, this adds a GCM mode for QUIC, and a generic TLS 1.3/QUIC-like
XOR'd counter mode. QUIC constructs nonces exactly like TLS 1.3, but the
counter does not reset to zero on a key update, so the mask must be
provided explicitly (or we will panic well before running out of
counters because the wrong value is XOR'd out). See the analysis at
https://github.com/quic-go/quic-go/issues/5077#issuecomment-3570352683
for the details of QUIC and FIPS 140-3 compliance (including a
workaround for the key update issue).
Second, this coalesces all the compliance modes around two schemes:
fixed || counter, and fixed XOR counter. The former is used in TLS 1.2
and SSH, and the latter is used in TLS 1.3 and QUIC.
This would not be a backwards compatible change if these were public
APIs, but we only need different versions of the FIPS 140-3 module to be
source-compatible with the standard library, and the callers of these
NewGCMFor* functions only care that the return value implements
cipher.AEAD, at least for now.
This exposes no new public APIs, but lets us get started validating
these functions in v2.0.0 of the FIPS 140-3 module.
Updates #73110
Change-Id: I3d86cf8a3c4a96caf361c29f0db5f9706a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/723760
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The compressor type is fairly large: 656616 bytes on amd64.
Before this patch, it had fields of slice and interface type
near the end of the struct. As those types always contain pointers,
the ptrBytes value in the type descriptor was quite large.
That forces the garbage collector to do extra work scanning for pointers,
and wastes a bit of executable space recording the gcmask for the type.
This patch moves the arrays to the end of the type,
fixing those minor issues.
Change-Id: I849a75a19cc61137c8797a1ea5a4c97e0f69b4db
Reviewed-on: https://go-review.googlesource.com/c/go/+/707596
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Mark Freeman <markfreeman@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
Consider a hypothetical SumCSHAKE256 function:
func SumCSHAKE256(N, S, data []byte, length int) []byte {
out := make([]byte, 64)
return sumCSHAKE256(out, N, S, data, length)
}
func sumCSHAKE256(out, N, S, data []byte, length int) []byte {
if len(out) < length {
out = make([]byte, length)
} else {
out = out[:length]
}
h := sha3.NewCSHAKE256(N, S)
h.Write(data)
h.Read(out)
return out
}
Currently this has 4 allocations:
- one for out (unless stack allocated),
- one for the SHAKE result of crypto/internal/fips140/sha3.newCShake,
- one for the initBlock allocation in crypto/internal/fips140/sha3.newCShake,
- one for the result of crypto/internal/fips140/sha3.bytepad.
We eliminate the SHAKE allocation by outlining the SHAKE allocation in
crypto/internal/fips140/sha3.NewCSHAKE128 and NewCSHAKE256. As
crypto/sha3.NewCSHAKE128 and NewCSHAKE256 immediately de-reference this
result, this allocation is eliminated.
We eliminate the bytepad allocation by instead writing the various
values directly with SHAKE.Write. Values passed to Write don't escape
and, with the exception of data (which is initBlock), all our Writes are
of fixed size allocations. We can't simply modify bytepad to return a
fixed size byte-slice as the length of data is not constant nor does it
have a reasonable upper bound.
We're stuck with the initBlock allocation because of the API (Reset and
the various marshallers), but we still net a substantial improvement.
benchstat output using the following benchmark:
func BenchmarkSumCSHAKE256(b *testing.B) {
N := []byte("N")
S := []byte("S")
data := []byte("testdata")
b.SetBytes(64)
for b.Loop() {
SumCSHAKE256(N, S, data, 64)
}
}
name old time/op new time/op delta
SumCSHAKE256-12 1.09µs ±20% 0.79µs ± 1% -27.41% (p=0.000 n=10+9)
name old speed new speed delta
SumCSHAKE256-12 59.8MB/s ±18% 81.0MB/s ± 1% +35.33% (p=0.000 n=10+9)
name old alloc/op new alloc/op delta
SumCSHAKE256-12 536B ± 0% 88B ± 0% -83.58% (p=0.000 n=10+10)
name old allocs/op new allocs/op delta
SumCSHAKE256-12 4.00 ± 0% 2.00 ± 0% -50.00% (p=0.000 n=10+10)
Updates #69982
Change-Id: If426ea8127c58f5ef062cf74712ec70fd26a7372
Reviewed-on: https://go-review.googlesource.com/c/go/+/636255
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Check for invalid encodings and keys more systematically in
ParseRawPrivateKey/PrivateKey.Bytes,
ParseUncompressedPublicKey/PublicKey.Bytes, and
fips140/ecdsa.NewPrivateKey/NewPublicKey.
Also, use these functions throughout the codebase.
This should not change any observable behavior, because there were
multiple layers of checks and every path would hit at least one.
Change-Id: I6a6a46566c95de871a5a37996835a0e51495f1d8
Reviewed-on: https://go-review.googlesource.com/c/go/+/724000
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Previously, we implemented ~quadratic name constraint checking, wherein
we would check every SAN against every respective constraint in the
chain. This is the technique _basically everyone_ implements, because
it's easy, but it requires also capping the total number of constraint
checking operations to prevent denial of service.
Instead, this change implements a log-linear checking technique, as
originally described by davidben@google.com with some minor
modifications. The comment at the top of crypto/x509/constraints.go
describes this technique in detail.
This technique is faster than the existing quadratic approach in all but
one specific case, where there are a large number of constraints but
only a single name, since our previous algorithm resolves to linear in
that case.
Change-Id: Icb761f5f9898c04e266c0d0c2b07ab2637f03418
Reviewed-on: https://go-review.googlesource.com/c/go/+/711421
Reviewed-by: Nicholas Husin <nsh@golang.org>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Roland Shoemaker <roland@golang.org>
Reviewed-by: Nicholas Husin <husin@google.com>
This commit adds fields to the ClientHelloInfo and ConnectionState
structures to represent hello retry request state information.
ClientHelloInfo gains a new HelloRetryRequest bool field that indicates
if the client hello was sent in response to a TLS 1.3 hello retry
request message previously emitted by the server.
ConnectionState gains a new HelloRetryRequest bool field that indicates
(depending on the connection role) whether the client received a TLS 1.3
hello retry request message from the server, or whether the server sent
such a message to a client.
Fixes#74425
Change-Id: Ic1a5290b8a4ba1568da1d2c2cf9f148150955fa5
Reviewed-on: https://go-review.googlesource.com/c/go/+/717440
Reviewed-by: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Daniel McCarney <daniel@binaryparadox.net>
This change renames the type State to Fetcher to better reflect its
purpose. The global variable ModuleFetchState is also renamed to
Fetcher_, which will continue to be gradually eliminated as with all
global state in the modfetch package.
[git-generate]
cd src/cmd/go/internal/modfetch
rf '
mv State Fetcher
mv ModuleFetchState Fetcher_
mv NewState NewFetcher
mv Fetcher.GoSumFile GoSumFile
mv GoSumFile.s GoSumFile.f
mv GoSumFile Fetcher.GoSumFile
mv Fetcher.SetGoSumFile SetGoSumFile
mv SetGoSumFile.s SetGoSumFile.f
mv SetGoSumFile Fetcher.SetGoSumFile
mv Fetcher.AddWorkspaceGoSumFile AddWorkspaceGoSumFile
mv AddWorkspaceGoSumFile.s AddWorkspaceGoSumFile.f
mv AddWorkspaceGoSumFile Fetcher.AddWorkspaceGoSumFile
'
rf '
add NewFetcher:+0 f := new(Fetcher) \
f.lookupCache = new(par.Cache[lookupCacheKey, Repo]) \
f.downloadCache = new(par.ErrCache[module.Version, string]) \
return f
'
rf 'rm NewFetcher:+5,8'
cd ../modload
rf '
mv State.modfetchState State.fetcher
'
Change-Id: I7cb6c945ea0f1d2119e1615064f041e88c81c689
Reviewed-on: https://go-review.googlesource.com/c/go/+/721740
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Mark Freeman <markfreeman@google.com>
This commit unexports critical State fields and provides setter
methods to update their values.
[git-generate]
cd src/cmd/go/internal/modfetch
rf '
add fetch.go:490 var jitsu int = 0 // rf marker
mv State.GoSumFile State.GoSumFile_
mv State.WorkspaceGoSumFiles State.WorkspaceGoSumFiles_
add jitsu \
func (s *State) GoSumFile() string { \
return ""
} \
\
func (s *State) SetGoSumFile(str string) { \
} \
\
func (s *State) AddWorkspaceGoSumFile(file string) { \
s.WorkspaceGoSumFiles_ = append(s.WorkspaceGoSumFiles_, file) \
}
\
ex {
var s *State
var x string
s.GoSumFile_ = x -> s.SetGoSumFile(x)
}
rm jitsu
'
cd ../modload
sed -i '
s/modfetch.ModuleFetchState.WorkspaceGoSumFiles_ = append(modfetch.ModuleFetchState.WorkspaceGoSumFiles_, sumFile)/modfetch.ModuleFetchState.AddWorkspaceGoSumFile(sumFile)/
' init.go
for dir in modcmd modload ; do
cd ../${dir}
rf '
ex {
import "cmd/go/internal/modfetch"
var s *modfetch.State
var x string
s.GoSumFile_ = x -> s.SetGoSumFile(x)
}
'
done
cd ../modfetch
rf '
mv State.GoSumFile_ State.goSumFile
mv State.WorkspaceGoSumFiles_ State.workspaceGoSumFiles
add State.GoSumFile: return s.goSumFile
rm State.GoSumFile://+1
add State.SetGoSumFile: s.goSumFile = str
'
Change-Id: Iff694aad7ad1cc62d2096c210dbaa3cce2b4061d
Reviewed-on: https://go-review.googlesource.com/c/go/+/720840
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Mark Freeman <markfreeman@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Copy LabelSet to an internal package as label.Set, and include (escaped)
labels within goroutine stack dumps.
Labels are added to the goroutine header as quoted key:value pairs, so
the line may get long if there are a lot of labels.
To handle escaping, we add a printescaped function to the
runtime and hook it up to the print function in the compiler with a new
runtime.quoted type that's a sibling to runtime.hex. (in fact, we
leverage some of the machinery from printhex to generate escape
sequences).
The escaping can be improved for printable runes outside basic ASCII
(particularly for languages using non-latin stripts). Additionally,
invalid UTF-8 can be improved.
So we can experiment with the output format make this opt-in via a
a new tracebacklabels GODEBUG var.
Updates #23458
Updates #76349
Change-Id: I08e78a40c55839a809236fff593ef2090c13c036
Reviewed-on: https://go-review.googlesource.com/c/go/+/694119
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Check to see if a context is canceled at all
before checking for the cancellaion cause.
If we can't find a cause, use the original error.
Avoids a data race where we look for a cause,
find none (because the context is not canceled),
the context is canceled,
and we then return ctx.Err() (even though there is now a cause).
Fixes#73390
Change-Id: I97f44aef25c6b02871d987970abfb4c215c5c80e
Reviewed-on: https://go-review.googlesource.com/c/go/+/679835
Reviewed-by: Sean Liao <sean@liao.dev>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Turns out we spend a few percent of the trace event writing path in just
zero-initializing the stack space for pcBuf. We don't need zero
initialization, since we're going to write over whatever we actually
use. Use m.profStack instead, which is already sized correctly.
A side-effect of this change is that trace stacks now obey the GODEBUG
profstackdepth where they previously ignored it. The name clearly
doesn't match, but this is a positive: there's no reason the maximum
stack depth shouldn't apply to every diagnostic.
Change-Id: Ia654d3d708f15cbb2e1d95af196ae10b07a65df2
Reviewed-on: https://go-review.googlesource.com/c/go/+/723062
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>
Merge List:
+ 2025-11-24 02d1f3a06b runtime: respect GOTRACEBACK for user-triggered runtime panics
+ 2025-11-24 a593ca9d65 runtime/cgo: add support for `any` param and return type
+ 2025-11-24 89552911b3 cmd/compile, internal/buildcfg: enable regABI on s390x, and add s390x
+ 2025-11-24 2fe0ba8d52 internal/bytealg: port bytealg functions to reg ABI on s390x
+ 2025-11-24 4529c8fba6 runtime: port memmove, memclr to register ABI on s390x
+ 2025-11-24 58a48a3e3b internal/runtime/syscall: Syscall changes for s390x regabi
+ 2025-11-24 2a185fae7e reflect, runtime: add reflect support for regabi on s390x
+ 2025-11-24 e92d2964fa runtime: mark race functions on s390x as ABIInternal
+ 2025-11-24 41af98eb83 runtime: add runtime changes for register ABI on s390x
+ 2025-11-24 85e6080089 cmd/internal/obj: set morestack arg spilling and regabi prologue on s390x
+ 2025-11-24 24697419c5 cmd/compile: update s390x CALL* ops
+ 2025-11-24 81242d034c cmd/compile/internal/s390x: add initial spill support
+ 2025-11-24 73b6aa0fec cmd/compile/internal: add register ABI information for s390x
+ 2025-11-24 1036f6f485 internal/abi: define s390x ABI constants
+ 2025-11-24 2e5d12a277 cmd/compile: document register-based ABI for s390x
Change-Id: I57b4ae6f9b65d99958b9fe5974205770e18f7788
The documentation for GOTRACEBACK says that "single" is the default
where the stack trace for only a single routine is printed except
that it prints all stack traces if:
there is no current goroutine or
the failure is internal to the run-time.
In the runtime, there are two types of panics:
throwTypeUser and throwTypeRuntime.
The latter more clearly corresponds to a
"failure [that] is internal to the run-time",
while the former corresponds to a
problem trigger due to a user mistake.
Thus, a user-triggered panic (e.g., concurrent map access)
should not result in a dump of all stack traces.
Fixes#68019
Change-Id: I9b02f82535ddb9fd666f7158e2e4ee10f235646a
Reviewed-on: https://go-review.googlesource.com/c/go/+/649535
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
So the simd package does not exist, instead of existing as an
empty package, if the goexperiment is not enabled. Unfortunately
the simd package developers have to run
GOEXPERIMENT=simd go generate, especially if one is not on an
AMD64 machine. But that command is still simple enough, not too
bad.
Change-Id: I632ce92ecb72e208212e294d8b3448b43fd01eef
Reviewed-on: https://go-review.googlesource.com/c/go/+/723802
Reviewed-by: Junyang Shao <shaojunyang@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
go/doc/comment/std.go has a list of top-level package prefixes in
the standard library. This list can vary depending on goexperiment,
but the file is static. E.g.
GOEXPERIMENT=arenas go test -run=TestStd go/doc/comment
would fail.
Don't include experimental packages, as they are not (yet)
generally available. We could have a per-experiment list of
package prefixes. But given that experimental packages are not
intended to be used widely (yet), it is probably not worth the
complexity.
Change-Id: Ib5bc060297cbae29c01fee458aaaa29600b81e98
Reviewed-on: https://go-review.googlesource.com/c/go/+/723840
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
This reverts CL 719520.
Reason for revert: Naming is confusing. Also, this has a semantic merge
conflict with CL 722040. Let's revert, fix the naming and conflict, and
do it again.
Change-Id: I0dc0c7c58470d63d48a4f69adb38c18f95db0beb
Reviewed-on: https://go-review.googlesource.com/c/go/+/723220
Reviewed-by: Junyang Shao <shaojunyang@google.com>
TryBot-Bypass: David Chase <drchase@google.com>
In several places the integer log2 is calculated using loops or similar
mechanisms. math/bits.Len* provide a simpler and more efficient
mechanisms for this.
Annoyingly, every usage has slightly different ideas of what "log2"
means and how non-positive inputs should be handled. I verified the
replacements in each case by comparing the result for inputs from 0
to 1<<16.
Change-Id: Ie962a74674802da363e0038d34c06979ccb41cf3
Reviewed-on: https://go-review.googlesource.com/c/go/+/721880
Reviewed-by: Mark Freeman <markfreeman@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
This commit updates the default go directive when initializing a new
module.
The current logic is to use the latest version supported by the
toolchain. This behavior is simple, predictable, and importantly, it
can work while completely offline (i.e., no internet connection
required).
This commit changes the default version to the following behavior:
* If the current toolchain version is a stable version of Go 1.N.M,
default to go 1.(N-1).0
* If the current toolchain version is a pre-release version of Go
1.N (Release Candidate M) or a development version of Go 1.N, default
to go 1.(N-2).0
This behavior maintains the property of being able to work offline.
Fixes#74748.
Change-Id: I81f62eef29f1dd51060067c8075f61e7bcf57c20
Reviewed-on: https://go-review.googlesource.com/c/go/+/720480
Commit-Queue: Ian Alexander <jitsu@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Bypass: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
Rework these tests such that they are built on all architectures and
actually executed when run on riscv64. This increases the likelihood
of catching code generation issues, especially those that impact
relocations. Also ensure that the generated assembly includes the
instruction sequence that is expected for the large branch/call/jump.
Change-Id: I15c40a439dd1d0d4ed189ab81697e93d82c4ef4d
Reviewed-on: https://go-review.googlesource.com/c/go/+/721621
Reviewed-by: Mark Ryan <markdryan@rivosinc.com>
Reviewed-by: Mark Freeman <markfreeman@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
The runtime tracer currently uses a per-M seqlock to indicate whether a
thread is writing to a local trace buffer. The seqlock is updated with
two atomic adds, read-modify-write operations. These are quite
expensive, even though they're completely uncontended.
We can make these operations slightly cheaper by using an atomic store.
The key insight here is that only one thread ever writes to the value at
a time, so only the "write" of the read-modify-write actually matters.
At that point, it doesn't really matter that we have a monotonically
increasing counter. This is made clearer by the fact that nothing other
than basic checks make sure the counter is monotonically increasing:
everything only depends on whether the counter is even or odd.
At that point, all we really need is a flag: an atomic.Bool, which we
can update with an atomic Store, a write-only instruction.
Change-Id: I0cfe39b34c7634554c34c53c0f0e196d125bbc4a
Reviewed-on: https://go-review.googlesource.com/c/go/+/721840
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
When git is recent enough (beyond 2.29), always set the --object-format
flag.
This fixes repo cloning when users have set the git configuration
init.defaultObjectFormat to sha256.
Git is planning[1] to switch the default hash function to sha256 with
the 3.0 release sometime in late 2026. (that may slip, but it's still
worth being ahead of the curve)
This change moves the version-check function from cl/698835 into
codehost/git.go so we can use it to condition setting
--object-format=sha1.
Adjust the regexp parsing git version output to handle more cases.
[1]: https://lore.kernel.org/lkml/xmqqikikk1hr.fsf@gitster.g/T/#u
Updates #68359
Change-Id: I7d59eb4e116b8afb47d3d1ca068d75eb5047d5c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/720500
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Mark Freeman <markfreeman@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
The CPU profiler reader goroutine has a hard-coded 100ms sleep between
reads of the CPU profile sample buffer. This is done because waking up
the CPU profile reader is not signal-safe on some platforms. As a
consequence, stopping the profiler takes 200ms (one iteration to read
the last samples and one to see the "eof"), and on many-core systems the
reader does not wake up frequently enought to keep up with incoming
data.
This CL removes the sleep where it is safe to do so, following a
suggestion by Austin Clements in the comments on CL 445375. We let the
reader fully block, and wake up the reader when the buffer is over
half-full.
Fixes#63043
Updates #56029
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-linux-arm64-longtest,gotip-linux-386-longtest
Change-Id: I9f7e7e9918a4a6f16e80f6aaf33103126568a81f
Reviewed-on: https://go-review.googlesource.com/c/go/+/610815
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Mark Freeman <markfreeman@google.com>
The profBuf.wakeupExtra method wakes up the profile reader if it's
sleeping, either when the buffer is closed or when there is a pending
overflow entry. Unlike in profBuf.write, profBuf.wakeupExtra does not
clear the profReaderSleeping bit before doing the wakeup. As a result,
if there are two writes to a full buffer before the sleeping reader has
time to wake up, we'll see two consecutive calls to notewakeup, which is
a fatal error. This CL updates profBuf.wakeupExtra to clear the sleeping
bit before doing the wakeup.
This CL adds a unit test that demonstrates the problem. This is
theoretically possible to trigger for real programs as well, but it's
more difficult. The profBufWordCount is large enough that it takes
several CPU-seconds to fill up the buffer. So we'd need to run on a
system with lots of cores to have a chance of running into this failure,
and the reader would need to fully go to sleep before a large burst of
CPU activity.
Change-Id: I59b4fa86a12f6236890b82cd353a95706a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/722940
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Mark Freeman <markfreeman@google.com>
This CL adds a new generator to internal/runtime/gc/scan that generates expander
kernels in Go SIMD. This CL also includes a Go SIMD scan kernel and a
Go SIMD filter kernel.
This CL also includes the plumbing, it will use the Go SIMD kernels if
goexperiment.simd is on.
Benchmark results:
...
ScanSpanPacked/cache=tiny/pages=1/sizeclass=26/pct=80-88 354.8n ± 1% 272.4n ± 0% -23.22% (p=0.002 n=6)
ScanSpanPacked/cache=tiny/pages=1/sizeclass=26/pct=90-88 375.7n ± 0% 287.1n ± 0% -23.58% (p=0.002 n=6)
ScanSpanPacked/cache=tiny/pages=1/sizeclass=26/pct=100-88 450.0n ± 1% 327.4n ± 0% -27.24% (p=0.002 n=6)
geomean 246.5n 199.4n -19.10%
Throughput +25%.
Change-Id: Ib85e01b7de18181db9e7b6026863209a993aa85f
Reviewed-on: https://go-review.googlesource.com/c/go/+/719520
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Clients receiving an HTTP 301 Moved Permanently may conservatively
change the method of a POST request to GET.
The newer HTTP 307 Temporary Redirect and 308 Permanent Redirect
explicitly allows retrying POST requests after the redirect.
These should be safe for ServeMux as this internal redirect is generated
before user provided handlers are called.
As ServeMux is making the redirect for the user without explicit
direction, and clients may cache Permanent Redirects indefinitely,
Temporary Redirect is used in case the user adds a handler for a path,
that was previously redirected but no longer should.
Fixes#50243Fixes#60769
Change-Id: I6c0b735bab03bb7b50f05457b3b8a8ba813badb2
Reviewed-on: https://go-review.googlesource.com/c/go/+/720820
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Mark Freeman <markfreeman@google.com>
This commit updates the BoringSSL module version used for the acvptool,
as well as the module version used for the static test data used by our
CI process to avoid interacting with a live ACVP server.
Two important upstream changes of note:
1. NIST changed the ML-KEM format slightly, and the BoringSSL acvptool
was updated in turn. We need to update the go-acvp data version to
one where I've regenerated the corresponding vector/expected files to
match these changes. Otherwise, we see an error from an empty dk
value.
2. The upstream BoringSSL acvptool switched to no longer truncating MAC
output in the subprocess handler for HMAC tests. Instead of relying on
this, we switch our capabilities to describe the output length we
return natively. In turn, we need to update the go-acvp data version
to vectors generated with the updated capabilities. Otherwise, we see
an error from the acvptool that our module wrapper returned a result
of the wrong length.
Change-Id: I1def172585ced0aaf1611d82f2e2802ca1500390
Reviewed-on: https://go-review.googlesource.com/c/go/+/719780
Auto-Submit: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Mark Freeman <markfreeman@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
This special case was added in CL 310171 for test/run.go use, as the
comment still says, but run.go (cmd/internal/testdir/testdir_test.go
by now) stopped using this in CL 310732. There don't seem to be any
other internal or external uses of this special case, so delete it.
Doing this kind of a cleanup can become harder as more time passes,
so try it as early as now and see how it goes.
Change-Id: Ib52aac51ef05166f7349cfc7d63b860a8ece7ec0
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/720620
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This moves the packed-immediate methods to package-private,
and adds exported versions with four parameters.
Rename PermuteConstant to PermuteScalars
Rename VPSHUFB Permute to PermuteOrZero
Rename Permute2 to ConcatPermute
Comments were repaired/enhanced.
Modified the generator to support an additional tag
"hideMaskMethods : true" to suppress method, intrinsic,
generic, and generic translation generation for said
mask-modified versions of such methods (this is already
true for exported methods).
Change-Id: I91e208c1fff1f28ebce4edb4e73d26003715018c
Reviewed-on: https://go-review.googlesource.com/c/go/+/721342
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Within ReverseProxy, we are currently sending a clone of our inbound
request (from client) as our outbound request (to upstream). However,
the clone of the request has a shallow copy of the request body. As a
result, when the outbound request body is closed, the inbound request
body (i.e. the outbound request body of the client) will also be closed.
This causes an unfortunate effect where we would infinitely hang when a
client sends a request with a 100-continue header via a ReverseProxy,
but the ReverseProxy fails to make a connection to the upstream server.
When this happens, the ReverseProxy's outbound request body would be
closed, which in turns also closes the client's request body.
Internally, when we close a request body, we would try to consume and
discard the content. Since the client has yet to actually send the body
content (due to 100-continue header) though, an infinite hang occurs.
To prevent this, we make sure that closing an outbound request body from
a ReverseProxy is a noop.
For #75933
Change-Id: I52dc7247f689f35a6e93d1f32b2d003d90e9d2c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/722160
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>
TestTraceSTW / TestTraceGCSTW currently tracks the location (M/P) of the
target goroutines until it reaches the "start" log message, assuming the
actual STW comes immediately afterwards.
On 386 with TestTraceGCSTW, it actually tends to take >10ms after the
start log before the STW actually occurs. This is enough time for sysmon
to preempt the target goroutines and migration them to another location.
Fix this by continuing tracking all the way until the STW itself occurs.
We still keep the start log message so we can ignore any STW (if any)
before we expect.
Cq-Include-Trybots: luci.golang.try:gotip-linux-386-longtest,gotip-linux-amd64-longtest
Change-Id: I6a6a636cf2dcb18d8b33ac4ad88333cabff2eabb
Reviewed-on: https://go-review.googlesource.com/c/go/+/722520
Reviewed-by: 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>
This is especially useful when combined with the nesting semantics of
context.Cause, and with errgroup's use of CancelCauseFunc.
For example, with the following code
ctx, stop := signal.NotifyContext(context.Background(), os.Interrupt)
defer stop()
serveGroup, ctx := errgroup.WithContext(ctx)
calling context.Cause(ctx) after serveGroup.Wait() will return either
"interrupt signal received" (if that happens first) or the error from
serveGroup.
Change-Id: Ie181f5f84269f6e39defdad2d5fd8ead6a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/721700
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Mark Freeman <markfreeman@google.com>
Reviewed-by: Sean Liao <sean@liao.dev>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Commit-Queue: Junyang Shao <shaojunyang@google.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Conflicts:
- src/cmd/compile/internal/typecheck/builtin.go
Merge List:
+ 2025-11-20 ca37d24e0b net/http: drop unused "broken" field from persistConn
+ 2025-11-20 4b740af56a cmd/internal/obj/x86: handle global reference in From3 in dynlink mode
+ 2025-11-20 790384c6c2 spec: adjust rule for type parameter on RHS of alias declaration
+ 2025-11-20 a49b0302d0 net/http: correctly close fake net.Conns
+ 2025-11-20 32f5aadd2f cmd/compile: stack allocate backing stores during append
+ 2025-11-20 a18aff8057 runtime: select GC mark workers during start-the-world
+ 2025-11-20 829779f4fe runtime: split findRunnableGCWorker in two
+ 2025-11-20 ab59569099 go/version: use "custom" as an example of a version suffix
+ 2025-11-19 c4bb9653ba cmd/compile: Implement LoweredZeroLoop with LSX Instruction on loong64
+ 2025-11-19 7f2ae21fb4 cmd/internal/obj/loong64: add MULW.D.W[U] instructions
+ 2025-11-19 a2946f2385 crypto: add Encapsulator and Decapsulator interfaces
+ 2025-11-19 6b83bd7146 crypto/ecdh: add KeyExchanger interface
+ 2025-11-19 4fef9f8b55 go/types, types2: fix object path for grouped declaration statements
+ 2025-11-19 33529db142 spec: escape double-ampersands
+ 2025-11-19 dc42565a20 cmd/compile: fix control flow for unsigned divisions proof relations
+ 2025-11-19 e64023dcbf cmd/compile: cleanup useless if statement in prove
+ 2025-11-19 2239520d1c test: go fmt prove.go tests
+ 2025-11-19 489d3dafb7 math: switch s390x math.Pow to generic implementation
+ 2025-11-18 8c41a482f9 runtime: add dlog.hexdump
+ 2025-11-18 e912618bd2 runtime: add hexdumper
+ 2025-11-18 2cf9d4b62f Revert "net/http: do not discard body content when closing it within request handlers"
+ 2025-11-18 4d0658bb08 cmd/compile: prefer fixed registers for values
+ 2025-11-18 ba634ca5c7 cmd/compile: fold boolean NOT into branches
+ 2025-11-18 8806d53c10 cmd/link: align sections, not symbols after DWARF compress
+ 2025-11-18 c93766007d runtime: do not print recovered when double panic with the same value
+ 2025-11-18 9859b43643 cmd/asm,cmd/compile,cmd/internal/obj/riscv: use compressed instructions on riscv64
+ 2025-11-17 b9ef0633f6 cmd/internal/sys,internal/goarch,runtime: enable the use of compressed instructions on riscv64
+ 2025-11-17 a087dea869 debug/elf: sync new loong64 relocation types up to LoongArch ELF psABI v20250521
+ 2025-11-17 e1a12c781f cmd/compile: use 32x32->64 multiplies on arm64
+ 2025-11-17 6caab99026 runtime: relax TestMemoryLimit on darwin a bit more
+ 2025-11-17 eda2e8c683 runtime: clear frame pointer at thread entry points
+ 2025-11-17 6919858338 runtime: rename findrunnable references to findRunnable
+ 2025-11-17 8e734ec954 go/ast: fix BasicLit.End position for raw strings containing \r
+ 2025-11-17 592775ec7d crypto/mlkem: avoid a few unnecessary inverse NTT calls
+ 2025-11-17 590cf18daf crypto/mlkem/mlkemtest: add derandomized Encapsulate768/1024
+ 2025-11-17 c12c337099 cmd/compile: teach prove about subtract idioms
+ 2025-11-17 bc15963813 cmd/compile: clean up prove pass
+ 2025-11-17 1297fae708 go/token: add (*File).End method
+ 2025-11-17 65c09eafdf runtime: hoist invariant code out of heapBitsSmallForAddrInline
+ 2025-11-17 594129b80c internal/runtime/maps: update doc for table.Clear
+ 2025-11-15 c58d075e9a crypto/rsa: deprecate PKCS#1 v1.5 encryption
+ 2025-11-14 d55ecea9e5 runtime: usleep before stealing runnext only if not in syscall
+ 2025-11-14 410ef44f00 cmd: update x/tools to 59ff18c
+ 2025-11-14 50128a2154 runtime: support runtime.freegc in size-specialized mallocs for noscan objects
+ 2025-11-14 c3708350a4 cmd/go: tests: rename git-min-vers->git-sha256
+ 2025-11-14 aea881230d std: fix printf("%q", int) mistakes
+ 2025-11-14 120f1874ef runtime: add more precise test of assist credit handling for runtime.freegc
+ 2025-11-14 fecfcaa4f6 runtime: add runtime.freegc to reduce GC work
+ 2025-11-14 5a347b775e runtime: set GOEXPERIMENT=runtimefreegc to disabled by default
+ 2025-11-14 1a03d0db3f runtime: skip tests for GOEXPERIMENT=arenas that do not handle clobberfree=1
+ 2025-11-14 cb0d9980f5 net/http: do not discard body content when closing it within request handlers
+ 2025-11-14 03ed43988f cmd/compile: allow multi-field structs to be stored directly in interfaces
+ 2025-11-14 1bb1f2bf0c runtime: put AddCleanup cleanup arguments in their own allocation
+ 2025-11-14 9fd2e44439 runtime: add AddCleanup benchmark
+ 2025-11-14 80c91eedbb runtime: ensure weak handles end up in their own allocation
+ 2025-11-14 7a8d0b5d53 runtime: add debug mode to extend _Grunning-without-P windows
+ 2025-11-14 710abf74da internal/runtime/cgobench: add Go function call benchmark for comparison
+ 2025-11-14 b24aec598b doc, cmd/internal/obj/riscv: document the riscv64 assembler
+ 2025-11-14 a0e738c657 cmd/compile/internal: remove incorrect riscv64 SLTI rule
+ 2025-11-14 2cdcc4150b cmd/compile: fold negation into multiplication
+ 2025-11-14 b57962b7c7 bytes: fix panic in bytes.Buffer.Peek
+ 2025-11-14 0a569528ea cmd/compile: optimize comparisons with single bit difference
+ 2025-11-14 1e5e6663e9 cmd/compile: remove unnecessary casts and types from riscv64 rules
+ 2025-11-14 ddd8558e61 go/types, types2: swap object.color for Checker.objPathIdx
+ 2025-11-14 9daaab305c cmd/link/internal/ld: make runtime.buildVersion with experiments valid
+ 2025-11-13 d50a571ddf test: fix tests to work with sizespecializedmalloc turned off
+ 2025-11-13 704f841eab cmd/trace: annotation proc start/stop with thread and proc always
+ 2025-11-13 17a02b9106 net/http: remove unused isLitOrSingle and isNotToken
+ 2025-11-13 ff61991aed cmd/go: fix flaky TestScript/mod_get_direct
+ 2025-11-13 129d0cb543 net/http/cgi: accept INCLUDED as protocol for server side includes
+ 2025-11-13 77c5130100 go/types: minor simplification
+ 2025-11-13 7601cd3880 go/types: generate cycles.go
+ 2025-11-13 7a372affd9 go/types, types2: rename definedType to declaredType and clarify docs
Change-Id: Ibaa9bdb982364892f80e511c1bb12661fcd5fb86
In dynlink mode, we rewrite reference to a global variable to
a load from the GOT. Currently this code does not handle the case
that the global reference is in From3 of a Prog. Most instructions
don't expect a memory operand in From3, but some do, like
VGF2P8AFFINEQB. Handle this case.
Change-Id: Ibb6773606e6967bcc629d9ef5dac6e050f4008ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/722181
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Per discussion on issue #75885, a type parameter on the RHS of an alias
declaration must not be declared in the same declaration (but it may be
declared by an enclosing function). This relaxes the spec slightly and
allows for (pre-existing) test cases.
Add a corresponding check to the type checker (there was no check for
type parameters on the RHS of alias declarations at all, before).
Fixes#75884.
Fixes#75885.
Change-Id: I1e5675978e6423d626c068829d4bf5e90035ea82
Reviewed-on: https://go-review.googlesource.com/c/go/+/721820
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Mark Freeman <markfreeman@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
We can already stack allocate the backing store during append if the
resulting backing store doesn't escape. See CL 664299.
This CL enables us to often stack allocate the backing store during
append *even if* the result escapes. Typically, for code like:
func f(n int) []int {
var r []int
for i := range n {
r = append(r, i)
}
return r
}
the backing store for r escapes, but only by returning it.
Could we operate with r on the stack for most of its lifeime,
and only move it to the heap at the return point?
The current implementation of append will need to do an allocation
each time it calls growslice. This will happen on the 1st, 2nd, 4th,
8th, etc. append calls. The allocations done by all but the
last growslice call will then immediately be garbage.
We'd like to avoid doing some of those intermediate allocations
if possible. We rewrite the above code by introducing a move2heap
operation:
func f(n int) []int {
var r []int
for i := range n {
r = append(r, i)
}
r = move2heap(r)
return r
}
Using the move2heap runtime function, which does:
move2heap(r):
If r is already backed by heap storage, return r.
Otherwise, copy r to the heap and return the copy.
Now we can treat the backing store of r allocated at the
append site as not escaping. Previous stack allocation
optimizations now apply, which can use a fixed-size
stack-allocated backing store for r when appending.
See the description in cmd/compile/internal/slice/slice.go
for how we ensure that this optimization is safe.
Change-Id: I81f36e58bade2241d07f67967d8d547fff5302b8
Reviewed-on: https://go-review.googlesource.com/c/go/+/707755
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
When the GC starts today, procresize and startTheWorldWithSema don't
consider the additional Ps required to run the mark workers. procresize
and startTheWorldWithSema resume only the Ps necessary to run the normal
user goroutines.
Once those Ps start, findRunnable and findRunnableGCWorker determine
that a GC worker is necessary and run the worker instead, calling wakep
to wake another P to run the original user goroutine.
This is unfortunate because it disrupts the intentional placement of Ps
on Ms that procresize does. It also has the unfortunate side effect of
slightly delaying start-the-world time, as it takes several sequential
wakeps to get all Ps started.
To address this, procresize explicitly assigns GC mark workers to Ps
before starting the world. The assignment occurs _after_ selecting
runnable Ps, so that we prefer to select Ps that were previously idle.
Note that if fewer than 25% of Ps are idle then we won't be able to
assign all dedicated workers, and some of the Ps intended for user
goroutines will convert to dedicated workers once they reach
findRunnableGCWorker.
Also note that stack scanning temporarily suspends the goroutine. Resume
occurs through ready, which will move the goroutine to the local runq of
the P that did the scan. Thus there is still a source of migration at
some point during the GC.
For #65694.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest
Change-Id: I6a6a636c51f39f4f4bc716aa87de68f6ebe163a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/721002
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
The first part, assignWaitingGCWorker selects a mark worker (if any) and
assigns it to the P. The second part, findRunnableGCWorker, is
responsible for actually marking the worker as runnable and updating the
CPU limiter.
The advantage of this split is that assignWaitingGCWorker is safe to do
during STW, which will allow the next CL to make selections during
procresize.
This change is a semantic no-op in preparation for the next CL.
For #65694.
Change-Id: I6a6a636c8beb212185829946cfa1e49f706ac31a
Reviewed-on: https://go-review.googlesource.com/c/go/+/721001
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Currently, we have a simple hexdumpWords facility for debugging. It's
useful but pretty limited.
This CL adds a much more configurable and capable "hexdumper". It can
be configured for any word size (including bytes), handles unaligned
data, includes an ASCII dump, and accepts data in multiple slices. It
also has a much nicer "mark" facility for annotating the hexdump that
isn't limited to a single character per word.
We use this to improve our existing hexdumps, particularly the new
mark facility. The next CL will integrate hexdumps into debuglog,
which will make use of several other new capabilities.
Also this adds an actual test.
The output looks like:
7 6 5 4 3 2 1 0 f e d c b a 9 8 0123456789abcdef
000000c00006ef70: 03000000 00000000 ........
000000c00006ef80: 00000000 0053da80 000000c0 000bc380 ..S.............
^ <testing.tRunner.func2+0x0>
000000c00006ef90: 00000000 0053dac0 000000c0 000bc380 ..S.............
^ <testing.tRunner.func1+0x0>
000000c00006efa0: 000000c0 0006ef90 000000c0 0006ef80 ................
000000c00006efb0: 000000c0 0006efd0 00000000 0053eb65 ........e.S.....
^ <testing.(*T).Run.gowrap1+0x25>
000000c00006efc0: 000000c0 000bc380 00000000 009aaae8 ................
000000c00006efd0: 00000000 00000000 00000000 00496b01 .........kI.....
^ <runtime.goexit+0x1>
000000c00006efe0: 00000000 00000000 00000000 00000000 ................
000000c00006eff0: 00000000 00000000 ........
The header gives column labels, indicating the order of bytes within
the following words. The addresses on the left are always 16-byte
aligned so it's easy to combine that address with the column header to
determine the full address of a byte. Annotations are no longer
interleaved with the data, so the data stays in nicely aligned
columns. The annotations are also now much more flexible, including
support for multiple annotations on the same word (not shown).
Change-Id: I27e83800a1f6a7bdd3cc2c59614661a810a57d4d
Reviewed-on: https://go-review.googlesource.com/c/go/+/681375
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Austin Clements <austin@google.com>
For this code:
func f() (int, int) {
return 0, 0
}
We currently generate on arm64:
MOVD ZR, R0
MOVD R0, R1
This CL changes that to
MOVD ZR, R0
MOVD ZR, R1
Probably not a big performance difference, but it makes the generated
code clearer.
A followup-ish CL from 633075 when the zero fixed register was exposed
to the register allocator.
Change-Id: I869a92817dcbbca46c900999fab538e76e10ed05
Reviewed-on: https://go-review.googlesource.com/c/go/+/721440
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
After DWARF compression, we recompute the symbol and section
addresses. On Windows, we need to align the sections to
PEFILEALIGN. But the code actually apply the alignment to every
symbol. This works mostly fine as after compression a section
usually contains a single symbol (the compressed data). But if the
compression is not beneficial, it leaves with the original set of
symbols, which could be more than one. Applying alignment to every
symbol causing the section size too big, no longer matching the
size we computed before compression.
Fixes#76022.
Change-Id: I2246045955405997c77e54001bbb83f9ccd1ee7c
Reviewed-on: https://go-review.googlesource.com/c/go/+/721340
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
This CL addressed some naming changes decided in API audit.
Before After
SHA1Msg1 SHA1Message1, Remove signed
SHA1Msg2 SHA1Message2, Remove signed
SHA1NextE SHA1NextE, Remove signed
SHA1Round4 SHA1FourRounds, Remove signed
SHA256Msg1 SHA256Message1, Remove signed
SHA256Msg2 SHA256Message2, Remove signed
SHA256Rounds2 SHA256TwoRounds, Remove signed
Change-Id: If2cead113f37a9044bc5c65e78fa9d124e318005
Reviewed-on: https://go-review.googlesource.com/c/go/+/721003
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Make use of compressed instructions on riscv64 - add a compress
pass to the end of the assembler, which replaces non-compressed
instructions with compressed alternatives if possible.
Provide a `compressinstructions` compiler and assembler debug
flag, such that the compression pass can be disabled via
`-asmflags=all=-d=compressinstructions=0` and
`-gcflags=all=-d=compressinstructions=0`. Note that this does
not prevent the explicit use of compressed instructions via
assembly.
Note that this does not make use of compressed control transfer
instructions - this will be implemented in later changes.
Reduces the text size of a hello world binary by ~121KB
and reduces the text size of the go binary on riscv64 by ~1.21MB
(between 8-10% in both cases).
Updates #71105
Cq-Include-Trybots: luci.golang.try:gotip-linux-riscv64
Change-Id: I24258353688554042c2a836deed4830cc673e985
Reviewed-on: https://go-review.googlesource.com/c/go/+/523478
Reviewed-by: Mark Ryan <markdryan@rivosinc.com>
Reviewed-by: Mark Freeman <markfreeman@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Enable the use of compressed instructions on riscv64 by reducing
the PC quantum to two bytes and reducing the minimum instruction
length to two bytes. Change gostartcall on riscv64 to land at
two times the PC quantum into goexit, so that we retain four byte
alignment and revise the NOP instructions in goexit to ensure that
they are never compressed. Additionally, adjust PCALIGN so that it
correctly handles two byte offsets.
Fixes#47560
Updates #71105
Cq-Include-Trybots: luci.golang.try:gotip-linux-riscv64
Change-Id: I4329a8fbfcb4de636aadaeadabb826bc22698640
Reviewed-on: https://go-review.googlesource.com/c/go/+/523477
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Reviewed-by: Mark Freeman <markfreeman@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Mark Ryan <markdryan@rivosinc.com>
There are a few places in the runtime where new threads enter Go code
with a possibly invalid frame pointer. mstart is the entry point for new
Ms, and rt0_go is the entrypoint for the program. As we try to introduce
frame pointer unwinding in more places (e.g. for heap profiling in CL
540476 or for execution trace events on the system stack in CL 593835),
we see these functions on the stack. We need to ensure that they have
valid frame pointers. These functions are both considered the "top"
(first) frame frame of the call stack, so this CL sets the frame pointer
register to 0 in these functions.
Updates #63630
Change-Id: I6a6a6964a9ebc6f68ba23d2616e5fb6f19677f97
Reviewed-on: https://go-review.googlesource.com/c/go/+/721020
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
This CL causes the parser to record in a new field, BasicLit.EndPos,
the actual end position of each literal token, and to use it in
BasicLit.End. Previously, the End was computed heuristically as
Pos + len(Value). This heuristic is incorrect for a multiline
raw string literal on Windows, since the scanner normalizes
\r\n to \n.
Unfortunately the actual end position is not returned by the
Scanner.Scan method, so the scanner and parser conspire
using a global variable in the go/internal/scannerhook
package to communicate.
+ test, api change, relnote
Fixes#76031
Change-Id: I57c18a44e85f7403d470ba23d41dcdcc5a9432c2
Reviewed-on: https://go-review.googlesource.com/c/go/+/720060
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The first two instructions in heapBitsSmallForAddrInline are
invariant for a given span and object and are called in
a loop within ScanObjectsSmall which figures as a hot routine
in profiles of some benchmark runs within sweet benchmark suite
(x/benchmarks/sweet), Ideally it would have been great if the
compiler hoisted this code out of the loop, Moving it out of
inner loop manually gives gains (moving it entirely out of
nested loop does not improve performance, in some cases it
even regresses it perhaps due to the early loop exit).
Tested with AMD64, ARM64, PPC64LE and S390x
Fixes#76212
Change-Id: I49c3c826b9d7bf3125ffc42c8c174cce0ecc4cbf
Reviewed-on: https://go-review.googlesource.com/c/go/+/718680
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
In the scheduler's steal path, we usleep(3) before stealing a _Prunning
P's runnext slot. Before CL 646198, we would not call usleep(3) if the P
was in _Psyscall. After CL 646198, Ps with Gs in syscalls stay in
_Prunning until stolen, meaning we might unnecessarily usleep(3) where
we didn't before. This probably isn't a huge deal in most cases, but can
cause some apparent slowdowns in microbenchmarks that frequently take
the steal path while there are syscalling goroutines.
Change-Id: I5bf3df10fe61cf8d7f0e9fe9522102de66faf344
Reviewed-on: https://go-review.googlesource.com/c/go/+/720441
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
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 smallNoScanStub stub in malloc_stubs.go to reuse
heap objects that have been freed by runtime.freegc calls, and generates
the corresponding size-specialized code in malloc_generated.go.
This CL only adds support in the specialized mallocs for noscan
heap objects (objects without pointers). A later CL handles objects
with pointers.
While we are here, we leave a couple of breadcrumbs in mkmalloc.go on
how to do the generation.
Updates #74299
Change-Id: I2657622601a27211554ee862fce057e101767a70
Reviewed-on: https://go-review.googlesource.com/c/go/+/715761
Reviewed-by: Junyang Shao <shaojunyang@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
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 adds a better test of assist credit handling when heap objects
are being reused after a runtime.freegc call.
The main approach is bracketing alloc/free pairs with measurements
of the assist credit before and after, and hoping to see a net zero
change in the assist credit.
However, validating the desired behavior is perhaps a bit subtle.
To help stabilize the measurements, we do acquirem in the test code
to avoid being preempted during the measurements to reduce other code's
ability to adjust the assist credit while we are measuring, and
we also reduce GOMAXPROCS to 1.
This test currently does fail if we deliberately introduce bugs
in the runtime.freegc implementation such as if we:
- never adjust the assist credit when reusing an object, or
- always adjust the assist credit when reusing an object, or
- deliberately mishandle internal fragmentation.
The two main cases of current interest for testing runtime.freegc
are when over the course of our bracketed measurements gcBlackenEnable
is either true or false. The test attempts to exercise both of those
case by running the GC continually in the background (which we can see
seems effective based on logging and by how our deliberate bugs fail).
This passes ~10K test executions locally via stress.
A small note to the future: a previous incarnation of this test (circa
patchset 11 of this CL) did not do acquirem but had an approach of
ignoring certain measurements, which also was able to pass ~10K runs
via stress. The current version in this CL is simpler, but
recording the existence of the prior version here in case it is
useful in the future. (Hopefully not.)
Updates #74299
Change-Id: I46c7e0295d125f5884fee0cc3d3d31aedc7e5ff4
Reviewed-on: https://go-review.googlesource.com/c/go/+/717520
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
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 adds runtime.freegc:
func freegc(ptr unsafe.Pointer, uintptr size, noscan bool)
Memory freed via runtime.freegc is made immediately reusable for
the next allocation in the same size class, without waiting for a
GC cycle, and hence can dramatically reduce pressure on the GC. A sample
microbenchmark included below shows strings.Builder operating roughly
2x faster.
An experimental modification to reflect to use runtime.freegc
and then using that reflect with json/v2 gave reported memory
allocation reductions of -43.7%, -32.9%, -21.9%, -22.0%, -1.0%
for the 5 official real-world unmarshalling benchmarks from
go-json-experiment/jsonbench by the authors of json/v2, covering
the CanadaGeometry through TwitterStatus datasets.
Note: there is no intent to modify the standard library to have
explicit calls to runtime.freegc, and of course such an ability
would never be exposed to end-user code.
Later CLs in this stack teach the compiler how to automatically
insert runtime.freegc calls when it can prove it is safe to do so.
(The reflect modification and other experimental changes to
the standard library were just that -- experiments. It was
very helpful while initially developing runtime.freegc to see
more complex uses and closer-to-real-world benchmark results
prior to updating the compiler.)
This CL only addresses noscan span classes (heap objects without
pointers), such as the backing memory for a []byte or string. A
follow-on CL adds support for heap objects with pointers.
If we update strings.Builder to explicitly call runtime.freegc on its
internal buf after a resize operation (but without freeing the usually
final incarnation of buf that will be returned to the user as a string),
we can see some nice benchmark results on the existing strings
benchmarks that call Builder.Write N times and then call Builder.String.
Here, the (uncommon) case of a single Builder.Write is not helped (given
it never resizes after first alloc if there is only one Write), but the
impact grows such that it is up to ~2x faster as there are more resize
operations due to more strings.Builder.Write calls:
│ disabled.out │ new-free-20.txt │
│ sec/op │ sec/op vs base │
BuildString_Builder/1Write_36Bytes_NoGrow-4 55.82n ± 2% 55.86n ± 2% ~ (p=0.794 n=20)
BuildString_Builder/2Write_36Bytes_NoGrow-4 125.2n ± 2% 115.4n ± 1% -7.86% (p=0.000 n=20)
BuildString_Builder/3Write_36Bytes_NoGrow-4 224.0n ± 1% 188.2n ± 2% -16.00% (p=0.000 n=20)
BuildString_Builder/5Write_36Bytes_NoGrow-4 239.1n ± 9% 205.1n ± 1% -14.20% (p=0.000 n=20)
BuildString_Builder/8Write_36Bytes_NoGrow-4 422.8n ± 3% 325.4n ± 1% -23.04% (p=0.000 n=20)
BuildString_Builder/10Write_36Bytes_NoGrow-4 436.9n ± 2% 342.3n ± 1% -21.64% (p=0.000 n=20)
BuildString_Builder/100Write_36Bytes_NoGrow-4 4.403µ ± 1% 2.381µ ± 2% -45.91% (p=0.000 n=20)
BuildString_Builder/1000Write_36Bytes_NoGrow-4 48.28µ ± 2% 21.38µ ± 2% -55.71% (p=0.000 n=20)
See the design document for more discussion of the strings.Builder case.
For testing, we add tests that attempt to exercise different aspects
of the underlying freegc and mallocgc behavior on the reuse path.
Validating the assist credit manipulations turned out to be subtle,
so a test for that is added in the next CL. There are also
invariant checks added, controlled by consts (primarily the
doubleCheckReusable const currently).
This CL also adds support in runtime.freegc for GODEBUG=clobberfree=1
to immediately overwrite freed memory with 0xdeadbeef, which
can help a higher-level test fail faster in the event of a bug,
and also the GC specifically looks for that pattern and throws
a fatal error if it unexpectedly finds it.
A later CL (currently experimental) adds GODEBUG=clobberfree=2,
which uses mprotect (or VirtualProtect on Windows) to set
freed memory to fault if read or written, until the runtime
later unprotects the memory on the mallocgc reuse path.
For the cases where a normal allocation is happening without any reuse,
some initial microbenchmarks suggest the impact of these changes could
be small to negligible (at least with GOAMD64=v3):
goos: linux
goarch: amd64
pkg: runtime
cpu: AMD EPYC 7B13
│ base-512M-v3.bench │ ps16-512M-goamd64-v3.bench │
│ sec/op │ sec/op vs base │
Malloc8-16 11.01n ± 1% 10.94n ± 1% -0.68% (p=0.038 n=20)
Malloc16-16 17.15n ± 1% 17.05n ± 0% -0.55% (p=0.007 n=20)
Malloc32-16 18.65n ± 1% 18.42n ± 0% -1.26% (p=0.000 n=20)
MallocTypeInfo8-16 18.63n ± 0% 18.36n ± 0% -1.45% (p=0.000 n=20)
MallocTypeInfo16-16 22.32n ± 0% 22.65n ± 0% +1.50% (p=0.000 n=20)
MallocTypeInfo32-16 23.37n ± 0% 23.89n ± 0% +2.23% (p=0.000 n=20)
geomean 18.02n 18.01n -0.05%
These last benchmark results include the runtime updates to support
span classes with pointers (which was originally part of this CL,
but later split out for ease of review).
Updates #74299
Change-Id: Icceaa0f79f85c70cd1a718f9a4e7f0cf3d77803c
Reviewed-on: https://go-review.googlesource.com/c/go/+/673695
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
When run with GODEBUG=clobberfree=1, three out of seven of the top-level
tests in runtime/arena_test.go fail with a SIGSEGV inside the
clobberfree function where it is overwriting freed memory
with 0xdeadbeef.
This is not a new problem. For example, this crashes in Go 1.20:
GODEBUG=clobberfree=1 go test runtime -run=TestUserArena
It would be nice for all.bash to pass with GODEBUG=clobberfree=1,
including it is useful for testing the automatic reclaiming of
dead memory via runtime.freegc in #74299.
Given the GOEXPERIMENT=arenas in #51317 is not planned to move forward
(and is hopefully slated to be replace by regions before too long),
for now we just skip those three tests in order to get all.bash
passing with GODEBUG=clobberfree=1.
Updates #74299
Change-Id: I384d96791157b30c73457d582a45dd74c5607ee0
Reviewed-on: https://go-review.googlesource.com/c/go/+/715080
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
(*body).Close() internally tries to discard the content of a request
body up to 256 KB. We rely on this behavior to allow connection re-use,
by calling (*body).Close() when our request handler exits.
Unfortunately, this causes an unfortunate side-effect where we would
prematurely try to discard a body content when (*body).Close() is called
from within a request handler.
There should not be a good reason for (*body).Close() to do this when
called from within a request handler. As such, this CL modifies
(*body).Close() to not discard body contents when called from within a
request handler. Note that when a request handler exits, it will still
try to discard the body content for connection re-use.
For #75933
Change-Id: I71d2431a540579184066dd35d3da49d6c85c3daf
Reviewed-on: https://go-review.googlesource.com/c/go/+/720380
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Nicholas Husin <husin@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Currently, AddCleanup just creates a simple closure that calls
`cleanup(arg)` as the actual cleanup function tracked internally.
However, the argument ends up getting its own allocation. If it's tiny,
then it can also end up sharing a tiny allocation slot with the object
we're adding the cleanup to. Since the closure is a GC root, we can end
up with cleanups that never fire.
This change refactors the AddCleanup machinery to make the storage for
the argument separate and explicit. With that in place, it explicitly
allocates 16 bytes of storage for tiny arguments to side-step the tiny
allocator.
One would think this would cause an increase in memory use and more
bytes allocated, but that's actually wrong! It turns out that the
current "simple closure" actually creates _two_ closures. By making the
argument passing explicit, we eliminate one layer of closures, so this
actually results in a slightly faster AddCleanup overall and 16 bytes
less memory allocated.
goos: linux
goarch: amd64
pkg: runtime
cpu: AMD EPYC 7B13
│ before.bench │ after.bench │
│ sec/op │ sec/op vs base │
AddCleanupAndStop-64 124.5n ± 2% 103.7n ± 2% -16.71% (p=0.002 n=6)
│ before.bench │ after.bench │
│ B/op │ B/op vs base │
AddCleanupAndStop-64 48.00 ± 0% 32.00 ± 0% -33.33% (p=0.002 n=6)
│ before.bench │ after.bench │
│ allocs/op │ allocs/op vs base │
AddCleanupAndStop-64 3.000 ± 0% 2.000 ± 0% -33.33% (p=0.002 n=6)
This change does, however, does add 16 bytes of overhead to the cleanup
special itself, and makes each cleanup block entry 24 bytes instead of 8
bytes. This means the overall memory overhead delta with this change is
neutral, and we just have a faster cleanup. (Cleanup block entries are
transient, so I suspect any increase in memory overhead there is
negligible.)
Together with CL 719960, fixes#76007.
Change-Id: I81bf3e44339e71c016c30d80bb4ee151c8263d5c
Reviewed-on: https://go-review.googlesource.com/c/go/+/720321
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently weak handles are atomic.Uintptr values that may end up in
a tiny block which can cause all sorts of surprising leaks. See #76007
for one example.
This change pads out the underlying allocation of the atomic.Uintptr to
16 bytes to ensure we bypass the tiny allocator, and it gets its own
block. This wastes 8 bytes per weak handle. We could potentially do
better by using the 8 byte noscan size class, but this can be a
follow-up change.
For #76007.
Change-Id: I3ab74dda9bf312ea0007f167093052de28134944
Reviewed-on: https://go-review.googlesource.com/c/go/+/719960
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The rule
(SLTI [x] (ORI [y] _)) && y >= 0 && int64(y) >= int64(x) => (MOVDconst [0])
is incorrect as it only generates correct code if the unknown value
being compared is >= 0. If the unknown value is < 0 the rule will
incorrectly produce a constant value of 0, whereas the code optimized
away by the rule would have produced a value of 1.
A new test that causes the faulty rule to generate incorrect code
is also added to ensure that the error does not return.
Change-Id: I69224e0776596f1b9538acf9dacf9009d305f966
Reviewed-on: https://go-review.googlesource.com/c/go/+/720220
Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Joel Sing <joel@sing.id.au>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
The type checker assigns types to objects. An object can be in
1 of 3 states, which are mapped to colors. This is stored as a
field on the object.
- white : type not known, awaiting processing
- grey : type pending, in processing
- black : type known, done processing
With the addition of Checker.objPathIdx, which maps objects to
a path index, presence in the map could signal grey coloring.
White and black coloring can be signaled by presence of
object.typ (a simple nil check).
This change removes the object.color field and its associated
methods, replacing it with an equivalent use of Checker.objPathIdx.
Checker.objPathIdx is integrated into the existing push and pop
methods, while slightly simplifying their signatures.
Note that the concept of object coloring remains the same - we
are merely changing and simplifying the mechanism which represents
the colors.
Change-Id: I91fb5e9a59dcb34c08ffc5b4ebc3f20a400094b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/715840
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Mark Freeman <markfreeman@google.com>
Conflicts:
- src/cmd/compile/internal/ir/symtab.go
- src/cmd/compile/internal/ssa/prove.go
- src/cmd/compile/internal/ssa/rewriteAMD64.go
- src/cmd/compile/internal/ssagen/intrinsics.go
- src/cmd/compile/internal/typecheck/builtin.go
- src/internal/buildcfg/exp.go
- src/internal/strconv/ftoa.go
- test/codegen/stack.go
Manually resolved some conflicts:
- Use internal/strconv for simd.String, remove internal/ftoa
- prove.go is just copied from the one on the main branch. We
have cherry-picked the changes to prove.go to main branch, so
our copy is identical to an old version of the one on the main
branch. There are CLs landed after our cherry-picks. Just copy
it over to adopt the new code.
Merge List:
+ 2025-11-13 57362e9814 go/types, types2: check for direct cycles as a separate phase
+ 2025-11-13 099e0027bd cmd/go/internal/modfetch: consolidate global vars
+ 2025-11-13 028375323f cmd/go/internal/modfetch/codehost: fix flaky TestReadZip
+ 2025-11-13 4ebf295b0b runtime: prefer to restart Ps on the same M after STW
+ 2025-11-13 625d8e9b9c runtime/pprof: fix goroutine leak profile tests for noopt
+ 2025-11-13 4684a26c26 spec: remove cycle restriction for type parameters
+ 2025-11-13 0f9c8fb29d cmd/asm,cmd/internal/obj/riscv: add support for riscv compressed instructions
+ 2025-11-13 a15d036ce2 cmd/internal/obj/riscv: implement better bit pattern encoding
+ 2025-11-12 abb241a789 cmd/internal/obj/loong64: add {,X}VS{ADD,SUB}.{B/H/W/V}{,U} instructions support
+ 2025-11-12 0929d21978 cmd/go: keep objects alive while stopping cleanups
+ 2025-11-12 f03d06ec1a runtime: fix list test memory management for mayMoreStack
+ 2025-11-12 48127f656b crypto/internal/fips140/sha3: remove outdated TODO
+ 2025-11-12 c3d1d42764 sync/atomic: amend comments for Value.{Swap,CompareAndSwap}
+ 2025-11-12 e0807ba470 cmd/compile: don't clear ptrmask in fillptrmask
+ 2025-11-12 66318d2b4b internal/abi: correctly describe result in Name.Name doc comment
+ 2025-11-12 34aef89366 cmd/compile: use FCLASSD for subnormal checks on riscv64
+ 2025-11-12 0c28789bd7 net/url: disallow raw IPv6 addresses in host
+ 2025-11-12 4e761b9a18 cmd/compile: optimize liveness in stackalloc
+ 2025-11-12 956909ff84 crypto/x509: move BetterTLS suite from crypto/tls
+ 2025-11-12 6525f46707 cmd/link: change shdr and phdr from arrays to slices
+ 2025-11-12 d3aeba1670 runtime: switch p.gcFractionalMarkTime to atomic.Int64
+ 2025-11-12 8873e8bea2 runtime,runtime/pprof: clean up goroutine leak profile writing
+ 2025-11-12 b8b84b789e cmd/go: clarify the -o testflag is only for copying the binary
+ 2025-11-12 c761b26b56 mime: parse media types that contain braces
+ 2025-11-12 65858a146e os/exec: include Cmd.Start in the list of methods that run Cmd
+ 2025-11-11 4bfc3a9d14 std,cmd: go fix -any std cmd
+ 2025-11-11 2263d4aabd runtime: doubly-linked sched.midle list
+ 2025-11-11 046dce0e54 runtime: use new list type for spanSPMCs
+ 2025-11-11 5f11275457 runtime: reusable intrusive doubly-linked list
+ 2025-11-11 951cf0501b internal/trace/testtrace: fix flag name typos
+ 2025-11-11 2750f95291 cmd/go: implement accurate pseudo-versions for Mercurial
+ 2025-11-11 b709a3e8b4 cmd/go/internal/vcweb: cache hg servers
+ 2025-11-11 426ef30ecf cmd/go: implement -reuse for Mercurial repos
+ 2025-11-10 5241d114f5 spec: more precise prose for special case of append
+ 2025-11-10 cdf64106f6 go/types, types2: first argument to append must never be be nil
+ 2025-11-10 a0eb4548cf .gitignore: ignore go test artifacts
+ 2025-11-10 bf58e7845e internal/trace: add "command" to convert text traces to raw
+ 2025-11-10 052c192a4c runtime: fix lock rank for work.spanSPMCs.lock
+ 2025-11-10 bc5ffe5c79 internal/runtime/sys,math/bits: eliminate bounds checks on len8tab
+ 2025-11-10 32f8d6486f runtime: document that tracefpunwindoff applies to some profilers
+ 2025-11-10 1c1c1942ba cmd/go: remove redundant AVX regex in security flag checks
+ 2025-11-10 3b3d6b9e5d cmd/internal/obj/arm64: shorten constant integer loads
+ 2025-11-10 5f4b5f1a19 runtime/msan: use different msan routine for copying
+ 2025-11-10 0fe6c8e8c8 runtime: tweak wording for comment of mcache.flushGen
+ 2025-11-10 95a0e5adc1 sync: don't call Done when f() panics in WaitGroup.Go
+ 2025-11-08 e8ed85d6c2 cmd/go: update goSum if necessary
+ 2025-11-08 b76103c08e cmd/go: output missing GoDebug entries
+ 2025-11-07 47a63a331d cmd/go: rewrite hgrepo1 test repo to be deterministic
+ 2025-11-07 7995751d3a cmd/go: copy git reuse and support repos to hg
+ 2025-11-07 66c7ca7fb3 cmd/go: improve TestScript/reuse_git
+ 2025-11-07 de84ac55c6 cmd/link: clean up some comments to Go standards
+ 2025-11-07 5cd1b73772 runtime: correctly print panics before fatal-ing on defer
+ 2025-11-07 91ca80f970 runtime/cgo: improve error messages after pointer panic
+ 2025-11-07 d36e88f21f runtime: tweak wording for doc
+ 2025-11-06 ad3ccd92e4 cmd/link: move pclntab out of relro section
+ 2025-11-06 43b91e7abd iter: fix a tiny doc comment bug
+ 2025-11-06 48c7fa13c6 Revert "runtime: remove the pc field of _defer struct"
+ 2025-11-05 8111104a21 cmd/internal/obj/loong64: add {,X}VSHUF.{B/H/W/V} instructions support
+ 2025-11-05 2e2072561c cmd/internal/obj/loong64: add {,X}VEXTRINS.{B,H,W,V} instruction support
+ 2025-11-05 01c29d1f0b internal/chacha8rand: replace VORV with instruction VMOVQ on loong64
+ 2025-11-05 f01a1841fd cmd/compile: fix error message on loong64
+ 2025-11-05 8cf7a0b4c9 cmd/link: support weak binding on darwin
+ 2025-11-05 2dd7e94e16 cmd/go: use go.dev instead of golang.org in flag errors
+ 2025-11-05 28f1ad5782 cmd/go: fix TestScript/govcs
+ 2025-11-05 daa220a1c9 cmd/go: silence TLS handshake errors during test
+ 2025-11-05 3ae9e95002 cmd/go: fix TestCgoPkgConfig on darwin with pkg-config installed
+ 2025-11-05 a494a26bc2 cmd/go: fix TestScript/vet_flags
+ 2025-11-05 a8fb94969c cmd/go: fix TestScript/tool_build_as_needed
+ 2025-11-05 04f05219c4 cmd/cgo: skip escape checks if call site has no argument
+ 2025-11-04 9f3a108ee0 os: ignore O_TRUNC errors on named pipes and terminal devices on Windows
+ 2025-11-04 0e1bd8b5f1 cmd/link, runtime: don't store text start in pcHeader
+ 2025-11-04 7347b54727 cmd/link: don't generate .gosymtab section
+ 2025-11-04 6914dd11c0 cmd/link: add and use new SymKind SFirstUnallocated
+ 2025-11-04 f5f14262d0 cmd/link: remove misleading comment
+ 2025-11-04 61de3a9dae cmd/link: remove unused SFILEPATH symbol kind
+ 2025-11-04 8e2bd267b5 cmd/link: add comments for SymKind values
+ 2025-11-04 16705b962e cmd/compile: faster liveness analysis in regalloc
+ 2025-11-04 a5fe6791d7 internal/syscall/windows: fix ReOpenFile sentinel error value
+ 2025-11-04 a7d174ccaa cmd/compile/internal/ssa: simplify riscv64 FCLASSD rewrite rules
+ 2025-11-04 856238615d runtime: amend doc for setPinned
+ 2025-11-04 c7ccbddf22 cmd/compile/internal/ssa: more aggressive on dead auto elim
+ 2025-11-04 75b2bb1d1a cmd/cgo: drop pre-1.18 support
+ 2025-11-04 dd839f1d00 internal/strconv: handle %f with fixedFtoa when possible
+ 2025-11-04 6e165b4d17 cmd/compile: implement Avg64u, Hmul64, Hmul64u for wasm
+ 2025-11-04 9f6590f333 encoding/pem: don't reslice in failure modes
+ 2025-11-03 34fec512ce internal/strconv: extract fixed-precision ftoa from ftoaryu.go
+ 2025-11-03 162ba6cc40 internal/strconv: add tests and benchmarks for ftoaFixed
+ 2025-11-03 9795c7ba22 internal/strconv: fix pow10 off-by-one in exponent result
+ 2025-11-03 ad5e941a45 cmd/internal/obj/loong64: using {xv,v}slli.d to perform copying between vector registers
+ 2025-11-03 dadbac0c9e cmd/internal/obj/loong64: add VPERMI.W, XVPERMI.{W,V,Q} instruction support
+ 2025-11-03 e2c6a2024c runtime: avoid append in printint, printuint
+ 2025-11-03 c93cc603cd runtime: allow Stack to traceback goroutines in syscall _Grunning window
+ 2025-11-03 b5353fd90a runtime: don't panic in castogscanstatus
+ 2025-11-03 43491f8d52 cmd/cgo: use the export'ed file/line in error messages
+ 2025-11-03 aa94fdf0cc cmd/go: link to go.dev/doc/godebug for removed GODEBUG settings
+ 2025-11-03 4d2b03d2fc crypto/tls: add BetterTLS test coverage
+ 2025-11-03 0c4444e13d cmd/internal/obj: support arm64 FMOVQ large offset encoding
+ 2025-11-03 85bec791a0 cmd/go/testdata/script: loosen list_empty_importpath for freebsd
+ 2025-11-03 17b57078ab internal/runtime/cgobench: add cgo callback benchmark
+ 2025-11-03 5f8fdb720c cmd/go: move functions to methods
+ 2025-11-03 0a95856b95 cmd/go: eliminate additional global variable
+ 2025-11-03 f93186fb44 cmd/go/internal/telemetrystats: count cgo usage
+ 2025-11-03 eaf28a27fd runtime: update outdated comments for deferprocStack
+ 2025-11-03 e12d8a90bf all: remove extra space in the comments
+ 2025-11-03 c5559344ac internal/profile: optimize Parse allocs
+ 2025-11-03 5132158ac2 bytes: add Buffer.Peek
+ 2025-11-03 361d51a6b5 runtime: remove the pc field of _defer struct
+ 2025-11-03 00ee1860ce crypto/internal/constanttime: expose intrinsics to the FIPS 140-3 packages
+ 2025-11-02 388c41c412 cmd/go: skip git sha256 tests if git < 2.29
+ 2025-11-01 385dc33250 runtime: prevent time.Timer.Reset(0) from deadlocking testing/synctest tests
+ 2025-10-31 99b724f454 cmd/go: document purego convention
+ 2025-10-31 27937289dc runtime: avoid zeroing scavenged memory
+ 2025-10-30 89dee70484 runtime: prioritize panic output over racefini
+ 2025-10-30 8683bb846d runtime: optimistically CAS atomicstatus directly in enter/exitsyscall
+ 2025-10-30 5b8e850340 runtime: don't track scheduling latency for _Grunning <-> _Gsyscall
+ 2025-10-30 251814e580 runtime: document tracer invariants explicitly
+ 2025-10-30 7244e9221f runtime: eliminate _Psyscall
+ 2025-10-30 5ef19c0d0c strconv: delete divmod1e9
+ 2025-10-30 d32b1f02c3 runtime: delete timediv
+ 2025-10-30 cbbd385cb8 strconv: remove arch-specific decision in formatBase10
+ 2025-10-30 6aca04a73a reflect: correct internal docs for uncommonType
+ 2025-10-30 235b4e729d cmd/compile/internal/ssa: model right shift more precisely
+ 2025-10-30 d44db293f9 go/token: fix a typo in a comment
+ 2025-10-30 cdc6b559ca strconv: remove hand-written divide on 32-bit systems
+ 2025-10-30 1e5bb416d8 cmd/compile: implement bits.Mul64 on 32-bit systems
+ 2025-10-30 38317c44e7 crypto/internal/fips140/aes: fix CTR generator
+ 2025-10-29 3be9a0e014 go/types, types: proceed with correct (invalid) type in case of a selector error
+ 2025-10-29 d2c5fa0814 strconv: remove &0xFF trick in formatBase10
+ 2025-10-29 9bbda7c99d cmd/compile: make prove understand div, mod better
+ 2025-10-29 915c1839fe test/codegen: simplify asmcheck pattern matching
+ 2025-10-29 32ee3f3f73 runtime: tweak example code for gorecover
+ 2025-10-29 da3fb90b23 crypto/internal/fips140/bigmod: fix extendedGCD comment
+ 2025-10-29 9035f7aea5 runtime: use internal/strconv
+ 2025-10-29 49c1da474d internal/itoa, internal/runtime/strconv: delete
+ 2025-10-29 b2a346bbd1 strconv: move all but Quote to internal/strconv
+ 2025-10-28 041f564b3e internal/runtime/gc/scan: avoid memory destination on VPCOMPRESSQ
+ 2025-10-28 81afd3a59b cmd/compile: extend ppc64 MADDLD to match const ADDconst & MULLDconst
+ 2025-10-28 ea50d61b66 cmd/compile: name change isDirect -> isDirectAndComparable
+ 2025-10-28 bd4dc413cd cmd/compile: don't optimize away a panicing interface comparison
+ 2025-10-28 30c047d0d0 cmd/compile: extend loong MOV*idx rules to match ADDshiftLLV
+ 2025-10-28 46e5e2b09a runtime: define PanicBounds in funcdata.h
+ 2025-10-28 3da0356685 crypto/internal/fips140test: collect 300M entropy samples for ESV
+ 2025-10-28 d5953185d5 runtime: amend comments a bit
+ 2025-10-28 12c8d14d94 errors: document that the target of Is must be comparable
+ 2025-10-28 1f4d14e493 go/types, types2: pull up package-level object sort to a separate phase
+ 2025-10-28 b8aa1ee442 go/types, types2: reduce locks held at once in resolveUnderlying
+ 2025-10-28 24af441437 cmd/compile: rewrite proved multiplies by 0 or 1 into CondSelect
+ 2025-10-28 2d33a456c6 cmd/compile: move branchelim supported arches to Config
+ 2025-10-27 2c91c33e88 crypto/subtle,cmd/compile: add intrinsics for ConstantTimeSelect and *Eq
+ 2025-10-27 73d7635fae cmd/compile: add generic rules to remove bool → int → bool roundtrips
+ 2025-10-27 1662d55247 cmd/compile: do not Zext bools to 64bits in amd64 CMOV generation rules
+ 2025-10-27 b8468d8c4e cmd/compile: introduce bytesizeToConst to cleanup switches in prove
+ 2025-10-27 9e25c2f6de cmd/link: internal linking support for windows/arm64
+ 2025-10-27 ff2ebf69c4 internal/runtime/gc/scan: correct size class size check
+ 2025-10-27 9a77aa4f08 cmd/compile: add position info to sccp debug messages
+ 2025-10-27 77dc138030 cmd/compile: teach prove about unsigned rounding-up divide
+ 2025-10-27 a0f33b2887 cmd/compile: change !l.nonzero() into l.maybezero()
+ 2025-10-27 5453b788fd cmd/compile: optimize Add64carry with unused carries into plain Add64
+ 2025-10-27 2ce5aab79e cmd/compile: remove 68857 ModU flowLimit workaround in prove
+ 2025-10-27 a50de4bda7 cmd/compile: remove 68857 min & max flowLimit workaround in prove
+ 2025-10-27 53be78630a cmd/compile: use topo-sort in prove to correctly learn facts while walking once
+ 2025-10-27 dec2b4c83d runtime: avoid bound check in freebsd binuptime
+ 2025-10-27 916e682d51 cmd/internal/obj, cmd/asm: reclassify the offset of memory access operations on loong64
+ 2025-10-27 2835b994fb cmd/go: remove global loader state variable
+ 2025-10-27 139f89226f cmd/go: use local state for telemetry
+ 2025-10-27 8239156571 cmd/go: use tagged switch
+ 2025-10-27 d741483a1f cmd/go: increase stmt threshold on amd64
+ 2025-10-27 a6929cf4a7 cmd/go: removed unused code in toolchain.Exec
+ 2025-10-27 180c07e2c1 go/types, types2: clarify docs for resolveUnderlying
+ 2025-10-27 d8a32f3d4b go/types, types2: wrap Named.fromRHS into Named.rhs
+ 2025-10-27 b2af92270f go/types, types2: verify stateMask transitions in debug mode
+ 2025-10-27 92decdcbaa net/url: further speed up escape and unescape
+ 2025-10-27 5f4ec3541f runtime: remove unused cgoCheckUsingType function
+ 2025-10-27 189f2c08cc time: rewrite IsZero method to use wall and ext fields
+ 2025-10-27 f619b4a00d cmd/go: reorder parameters so that context is first
+ 2025-10-27 f527994c61 sync: update comments for Once.done
+ 2025-10-26 5dcaf9a01b runtime: add GOEXPERIMENT=runtimefree
+ 2025-10-26 d7a52f9369 cmd/compile: use MOV(D|F) with const for Const(64|32)F on riscv64
+ 2025-10-26 6f04a92be3 internal/chacha8rand: provide vector implementation for riscv64
+ 2025-10-26 54e3adc533 cmd/go: use local loader state in test
+ 2025-10-26 ca379b1c56 cmd/go: remove loaderstate dependency
+ 2025-10-26 83a44bde64 cmd/go: remove unused loader state
+ 2025-10-26 7e7cd9de68 cmd/go: remove temporary rf cleanup script
+ 2025-10-26 53ad68de4b cmd/compile: allow unaligned load/store on Wasm
+ 2025-10-25 12ec09f434 cmd/go: use local state object in work.runBuild and work.runInstall
+ 2025-10-24 643f80a11f runtime: add ppc and s390 to 32 build constraints for gccgo
+ 2025-10-24 0afbeb5102 runtime: add ppc and s390 to linux 32 bits syscall build constraints for gccgo
+ 2025-10-24 7b506d106f cmd/go: use local state object in `generate.runGenerate`
+ 2025-10-24 26a8a21d7f cmd/go: use local state object in `env.runEnv`
+ 2025-10-24 f2dd3d7e31 cmd/go: use local state object in `vet.runVet`
+ 2025-10-24 784700439a cmd/go: use local state object in pkg `workcmd`
+ 2025-10-24 69673e9be2 cmd/go: use local state object in `tool.runTool`
+ 2025-10-24 2e12c5db11 cmd/go: use local state object in `test.runTest`
+ 2025-10-24 fe345ff2ae cmd/go: use local state object in `modget.runGet`
+ 2025-10-24 d312e27e8b cmd/go: use local state object in pkg `modcmd`
+ 2025-10-24 ea9cf26aa1 cmd/go: use local state object in `list.runList`
+ 2025-10-24 9926e1124e cmd/go: use local state object in `bug.runBug`
+ 2025-10-24 2c4fd7b2cd cmd/go: use local state object in `run.runRun`
+ 2025-10-24 ade9f33e1f cmd/go: add loaderstate as field on `mvsReqs`
+ 2025-10-24 ccf4192a31 cmd/go: make ImportMissingError work with local state
+ 2025-10-24 f5403f15f0 debug/pe: check for zdebug_gdb_scripts section in testDWARF
+ 2025-10-24 a26f860fa4 runtime: use 32-bit hash for maps on Wasm
+ 2025-10-24 747fe2efed encoding/json/v2: fix typo in documentation about errors.AsType
+ 2025-10-24 94f47fc03f cmd/link: remove pointless assignment in SetSymAlign
+ 2025-10-24 e6cff69051 crypto/x509: move constraint checking after chain building
+ 2025-10-24 f5f69a3de9 encoding/json/jsontext: avoid pinning application data in pools
+ 2025-10-24 a6a59f0762 encoding/json/v2: use slices.Sort directly
+ 2025-10-24 0d3dab9b1d crypto/x509: simplify candidate chain filtering
+ 2025-10-24 29046398bb cmd/go: refactor injection of modload.LoaderState
+ 2025-10-24 c18fa69e52 cmd/go: make ErrNoModRoot work with local state
+ 2025-10-24 296ecc918d cmd/go: add modload.State parameter to AllowedFunc
+ 2025-10-24 c445a61e52 cmd/go: add loaderstate as field on `QueryMatchesMainModulesError`
+ 2025-10-24 6ac40051d3 cmd/go: remove module loader state from ccompile
+ 2025-10-24 6a5a452528 cmd/go: inject vendor dir into builder struct
+ 2025-10-23 dfac972233 crypto/pbkdf2: add missing error return value in example
+ 2025-10-23 47bf8f073e unique: fix inconsistent panic prefix in canonmap cleanup path
+ 2025-10-23 03bd43e8bb go/types, types2: rename Named.resolve to unpack
+ 2025-10-23 9fcdc814b2 go/types, types2: rename loaded namedState to lazyLoaded
+ 2025-10-23 8401512a9b go/types, types2: rename complete namedState to hasMethods
+ 2025-10-23 cf826bfcb4 go/types, types2: set t.underlying exactly once in resolveUnderlying
+ 2025-10-23 c4e910895b net/url: speed up escape and unescape
+ 2025-10-23 3f6ac3a10f go/build: use slices.Equal
+ 2025-10-23 839da71f89 encoding/pem: properly calculate end indexes
+ 2025-10-23 39ed968832 cmd: update golang.org/x/arch for riscv64 disassembler
+ 2025-10-23 ca448191c9 all: replace Split in loops with more efficient SplitSeq
+ 2025-10-23 107fcb70de internal/goroot: replace HasPrefix+TrimPrefix with CutPrefix
+ 2025-10-23 8378276d66 strconv: optimize int-to-decimal and use consistently
+ 2025-10-23 e5688d0bdd cmd/internal/obj/riscv: simplify validation and encoding of raw instructions
+ 2025-10-22 77fc27972a doc/next: improve new(expr) release note
+ 2025-10-22 d94a8c56ad runtime: cleanup pagetrace
+ 2025-10-22 02728a2846 crypto/internal/fips140test: add entropy SHA2-384 testing
+ 2025-10-22 f92e01c117 runtime/cgo: fix cgoCheckArg description
+ 2025-10-22 50586182ab runtime: use backoff and ISB instruction to reduce contention in (*lfstack).pop and (*spanSet).pop on arm64
+ 2025-10-22 1ff59f3dd3 strconv: clean up powers-of-10 table, tests
+ 2025-10-22 7c9fa4d5e9 cmd/go: check if build output should overwrite files with renames
+ 2025-10-22 557b4d6e0f comment: change slice to string in function comment/help
+ 2025-10-22 d09a8c8ef4 go/types, types2: simplify locking in Named.resolveUnderlying
+ 2025-10-22 5a42af7f6c go/types, types2: in resolveUnderlying, only compute path when needed
+ 2025-10-22 4bdb55b5b8 go/types, types2: rename Named.under to Named.resolveUnderlying
+ 2025-10-21 29d43df8ab go/build, cmd/go: use ast.ParseDirective for go:embed
+ 2025-10-21 4e695dd634 go/ast: add ParseDirective for parsing directive comments
+ 2025-10-21 06e57e60a7 go/types, types2: only report version errors if new(expr) is ok otherwise
+ 2025-10-21 6c3d0d259f path/filepath: reword documentation for Rel
+ 2025-10-21 39fd61ddb0 go/types, types2: guard Named.underlying with Named.mu
+ 2025-10-21 4a0115c886 runtime,syscall: implement and use syscalln on darwin
+ 2025-10-21 261c561f5a all: gofmt -w
+ 2025-10-21 c9c78c06ef strconv: embed testdata in test
+ 2025-10-21 8f74f9daf4 sync: re-enable race even when panicking
+ 2025-10-21 8a6c64f4fe syscall: use rawSyscall6 to call ptrace in forkAndExecInChild
+ 2025-10-21 4620db72d2 runtime: use timer_settime64 on 32-bit Linux
+ 2025-10-21 b31dc77cea os: support deleting read-only files in RemoveAll on older Windows versions
+ 2025-10-21 46cc532900 cmd/compile/internal/ssa: fix typo in comment
+ 2025-10-21 2163a58021 crypto/internal/fips140/entropy: increase AllocsPerRun iterations
+ 2025-10-21 306eacbc11 cmd/go/testdata/script: disable list_empty_importpath test on Windows
+ 2025-10-21 a5a249d6a6 all: eliminate unnecessary type conversions
+ 2025-10-21 694182d77b cmd/internal/obj/ppc64: improve large prologue generation
+ 2025-10-21 b0dcb95542 cmd/compile: leave the horses alone
+ 2025-10-21 9a5a1202f4 runtime: clean dead architectures from go:build constraint
+ 2025-10-21 8539691d0c crypto/internal/fips140/entropy: move to crypto/internal/entropy/v1.0.0
+ 2025-10-20 99cf4d671c runtime: save lasx and lsx registers in loong64 async preemption
+ 2025-10-20 79ae97fe9b runtime: make procyieldAsm no longer loop infinitely if passed 0
+ 2025-10-20 f838faffe2 runtime: wrap procyield assembly and check for 0
+ 2025-10-20 ee4d2c312d runtime/trace: dump test traces on validation failure
+ 2025-10-20 7b81a1e107 net/url: reduce allocs in Encode
+ 2025-10-20 e425176843 cmd/asm: fix typo in comment
+ 2025-10-20 dc9a3e2a65 runtime: fix generation skew with trace reentrancy
+ 2025-10-20 df33c17091 runtime: add _Gdeadextra status
+ 2025-10-20 7503856d40 cmd/go: inject loaderstate into matcher function
+ 2025-10-20 d57c3fd743 cmd/go: inject State parameter into `work.runInstall`
+ 2025-10-20 e94a5008f6 cmd/go: inject State parameter into `work.runBuild`
+ 2025-10-20 d9e6f95450 cmd/go: inject State parameter into `workcmd.runSync`
+ 2025-10-20 9769a61e64 cmd/go: inject State parameter into `modget.runGet`
+ 2025-10-20 f859799ccf cmd/go: inject State parameter into `modcmd.runVerify`
+ 2025-10-20 0f820aca29 cmd/go: inject State parameter into `modcmd.runVendor`
+ 2025-10-20 92aa3e9e98 cmd/go: inject State parameter into `modcmd.runInit`
+ 2025-10-20 e176dff41c cmd/go: inject State parameter into `modcmd.runDownload`
+ 2025-10-20 e7c66a58d5 cmd/go: inject State parameter into `toolchain.Select`
+ 2025-10-20 4dc3dd9a86 cmd/go: add loaderstate to Switcher
+ 2025-10-20 bcf7da1595 cmd/go: convert functions to methods
+ 2025-10-20 0d3044f965 cmd/go: make Reset work with any State instance
+ 2025-10-20 386d81151d cmd/go: make setState work with any State instance
+ 2025-10-20 a420aa221e cmd/go: inject State parameter into `tool.runTool`
+ 2025-10-20 441e7194a4 cmd/go: inject State parameter into `test.runTest`
+ 2025-10-20 35e8309be2 cmd/go: inject State parameter into `list.runList`
+ 2025-10-20 29a81624f7 cmd/go: inject state parameter into `fmtcmd.runFmt`
+ 2025-10-20 f7eaea02fd cmd/go: inject state parameter into `clean.runClean`
+ 2025-10-20 58a8fdb6cf cmd/go: inject State parameter into `bug.runBug`
+ 2025-10-20 8d0bef7ffe runtime: add linkname documentation and guidance
+ 2025-10-20 3e43f48cb6 encoding/asn1: use reflect.TypeAssert to improve performance
+ 2025-10-20 4ad5585c2c runtime: fix _rt0_ppc64x_lib on aix
+ 2025-10-17 a5f55a441e cmd/fix: add modernize and inline analyzers
+ 2025-10-17 80876f4b42 cmd/go/internal/vet: tweak help doc
+ 2025-10-17 b5aefe07e5 all: remove unnecessary loop variable copies in tests
+ 2025-10-17 5137c473b6 go/types, types2: remove references to under function in comments
+ 2025-10-17 dbbb1bfc91 all: correct name for comments
+ 2025-10-17 0983090171 encoding/pem: properly decode strange PEM data
+ 2025-10-17 36863d6194 runtime: unify riscv64 library entry point
+ 2025-10-16 0c14000f87 go/types, types2: remove under(Type) in favor of Type.Underlying()
+ 2025-10-16 1099436f1b go/types, types2: change and enforce lifecycle of Named.fromRHS and Named.underlying fields
+ 2025-10-16 41f5659347 go/types, types2: remove superfluous unalias call (minor cleanup)
+ 2025-10-16 e7351c03c8 runtime: use DC ZVA instead of its encoding in WORD in arm64 memclr
+ 2025-10-16 6cbe0920c4 cmd: update to x/tools@7d9453cc
+ 2025-10-15 45eee553e2 cmd/internal/obj: move ARM64RegisterExtension from cmd/asm/internal/arch
+ 2025-10-15 27f9a6705c runtime: increase repeat count for alloc test
+ 2025-10-15 b68cebd809 net/http/httptest: record failed ResponseWriter writes
+ 2025-10-15 f1fed742eb cmd: fix three printf problems reported by newest vet
+ 2025-10-15 0984dcd757 cmd/compile: fix an error in comments
+ 2025-10-15 31f82877e8 go/types, types2: fix misleading internal comment
+ 2025-10-15 6346349f56 cmd/compile: replace angle brackets with square
+ 2025-10-15 284379cdfc cmd/compile: remove rematerializable values from live set across calls
+ 2025-10-15 519ae514ab cmd/compile: eliminate bound check for slices of the same length
+ 2025-10-15 b5a29cca48 cmd/distpack: add fix tool to inventory
+ 2025-10-15 bb5eb51715 runtime/pprof: fix errors in pprof_test
+ 2025-10-15 5c9a26c7f8 cmd/compile: use arm64 neon in LoweredMemmove/LoweredMemmoveLoop
+ 2025-10-15 61d1ff61ad cmd/compile: use block starting position for phi line number
+ 2025-10-15 5b29875c8e cmd/go: inject State parameter into `run.runRun`
+ 2025-10-15 5113496805 runtime/pprof: skip flaky test TestProfilerStackDepth/heap for now
+ 2025-10-15 36086e85f8 cmd/go: create temporary cleanup script
+ 2025-10-14 7056c71d32 cmd/compile: disable use of new saturating float-to-int conversions
+ 2025-10-14 6d5b13793f Revert "cmd/compile: make 386 float-to-int conversions match amd64"
+ 2025-10-14 bb2a14252b Revert "runtime: adjust softfloat corner cases to match amd64/arm64"
+ 2025-10-14 3bc9d9fa83 Revert "cmd/compile: make wasm match other platforms for FP->int32/64 conversions"
+ 2025-10-14 ee5af46172 encoding/json: avoid misleading errors under goexperiment.jsonv2
+ 2025-10-14 11d3d2f77d cmd/internal/obj/arm64: add support for PAC instructions
+ 2025-10-14 4dbf1a5a4c cmd/compile/internal/devirtualize: do not track assignments to non-PAUTO
+ 2025-10-14 0ddb5ed465 cmd/compile/internal/devirtualize: use FatalfAt instead of Fatalf where possible
+ 2025-10-14 0a239bcc99 Revert "net/url: disallow raw IPv6 addresses in host"
+ 2025-10-14 5a9ef44bc0 cmd/compile/internal/devirtualize: fix OCONVNOP assertion
+ 2025-10-14 3765758b96 go/types, types2: minor cleanup (remove TODO)
+ 2025-10-14 f6b9d56aff crypto/internal/fips140/entropy: fix benign race
+ 2025-10-14 60f6d2f623 crypto/internal/fips140/entropy: support SHA-384 sizes for ACVP tests
+ 2025-10-13 6fd8e88d07 encoding/json/v2: restrict presence of default options
+ 2025-10-13 1abc6b0204 go/types, types2: permit type cycles through type parameter lists
+ 2025-10-13 9fdd6904da strconv: add tests that Java once mishandled
+ 2025-10-13 9b8742f2e7 cmd/compile: don't depend on arch-dependent conversions in the compiler
+ 2025-10-13 0e64ee1286 encoding/json/v2: report EOF for top-level values in UnmarshalDecode
+ 2025-10-13 6bcd97d9f4 all: replace calls to errors.As with errors.AsType
+ 2025-10-11 1cd71689f2 crypto/x509: rework fix for CVE-2025-58187
+ 2025-10-11 8aa1efa223 cmd/link: in TestFallocate, only check number of blocks on Darwin
+ 2025-10-10 b497a29d25 encoding/json: fix regression in quoted numbers under goexperiment.jsonv2
+ 2025-10-10 48bb7a6114 cmd/compile: repair bisection behavior for float-to-unsigned conversion
+ 2025-10-10 e8a53538b4 runtime: fail TestGoroutineLeakProfile on data race
+ 2025-10-10 e3be2d1b2b net/url: disallow raw IPv6 addresses in host
+ 2025-10-10 aced4c79a2 net/http: strip request body headers on POST to GET redirects
+ 2025-10-10 584a89fe74 all: omit unnecessary reassignment
+ 2025-10-10 69e8279632 net/http: set cookie host to Request.Host when available
+ 2025-10-10 6f4c63ba63 cmd/go: unify "go fix" and "go vet"
+ 2025-10-10 955a5a0dc5 runtime: support arm64 Neon in async preemption
+ 2025-10-10 5368e77429 net/http: run TestRequestWriteTransport with fake time to avoid flakes
+ 2025-10-09 c53cb642de internal/buildcfg: enable greenteagc experiment for loong64
+ 2025-10-09 954fdcc51a cmd/compile: declare no output register for loong64 LoweredAtomic{And,Or}32 ops
+ 2025-10-09 19a30ea3f2 cmd/compile: call generated size-specialized malloc functions directly
+ 2025-10-09 80f3bb5516 reflect: remove timeout in TestChanOfGC
+ 2025-10-09 9db7e30bb4 net/url: allow IP-literals with IPv4-mapped IPv6 addresses
+ 2025-10-09 8d810286b3 cmd/compile: make wasm match other platforms for FP->int32/64 conversions
+ 2025-10-09 b9f3accdcf runtime: adjust softfloat corner cases to match amd64/arm64
+ 2025-10-09 78d75b3799 cmd/compile: make 386 float-to-int conversions match amd64
+ 2025-10-09 0e466a8d1d cmd/compile: modify float-to-[u]int so that amd64 and arm64 match
+ 2025-10-08 4837fbe414 net/http/httptest: check whether response bodies are allowed
+ 2025-10-08 ee163197a8 path/filepath: return cleaned path from Rel
+ 2025-10-08 de9da0de30 cmd/compile/internal/devirtualize: improve concrete type analysis
+ 2025-10-08 ae094a1397 crypto/internal/fips140test: make entropy file pair names match
+ 2025-10-08 941e5917c1 runtime: cleanup comments from asm_ppc64x.s improvements
+ 2025-10-08 d945600d06 cmd/gofmt: change -d to exit 1 if diffs exist
+ 2025-10-08 d4830c6130 cmd/internal/obj: fix Link.Diag printf errors
+ 2025-10-08 e1ca1de123 net/http: format pprof.go
+ 2025-10-08 e5d004c7a8 net/http: update HTTP/2 documentation to reference new config features
+ 2025-10-08 97fd6bdecc cmd/compile: fuse NaN checks with other comparisons
+ 2025-10-07 78b43037dc cmd/go: refactor usage of `workFilePath`
+ 2025-10-07 bb1ca7ae81 cmd/go, testing: add TB.ArtifactDir and -artifacts flag
+ 2025-10-07 1623927730 cmd/go: refactor usage of `requirements`
+ 2025-10-07 a1661e776f Revert "crypto/internal/fips140/subtle: add assembly implementation of xorBytes for mips64x"
+ 2025-10-07 cb81270113 Revert "crypto/internal/fips140/subtle: add assembly implementation of xorBytes for mipsx"
+ 2025-10-07 f2d0d05d28 cmd/go: refactor usage of `MainModules`
+ 2025-10-07 f7a68d3804 archive/tar: set a limit on the size of GNU sparse file 1.0 regions
+ 2025-10-07 463165699d net/mail: avoid quadratic behavior in mail address parsing
+ 2025-10-07 5ede095649 net/textproto: avoid quadratic complexity in Reader.ReadResponse
+ 2025-10-07 5ce8cd16f3 encoding/pem: make Decode complexity linear
+ 2025-10-07 f6f4e8b3ef net/url: enforce stricter parsing of bracketed IPv6 hostnames
+ 2025-10-07 7dd54e1fd7 runtime: make work.spanSPMCs.all doubly-linked
+ 2025-10-07 3ee761739b runtime: free spanQueue on P destroy
+ 2025-10-07 8709a41d5e encoding/asn1: prevent memory exhaustion when parsing using internal/saferio
+ 2025-10-07 9b9d02c5a0 net/http: add httpcookiemaxnum GODEBUG option to limit number of cookies parsed
+ 2025-10-07 3fc4c79fdb crypto/x509: improve domain name verification
+ 2025-10-07 6e4007e8cf crypto/x509: mitigate DoS vector when intermediate certificate contains DSA public key
+ 2025-10-07 6f7926589d cmd/go: refactor usage of `modRoots`
+ 2025-10-07 11d5484190 runtime: fix self-deadlock on sbrk platforms
+ 2025-10-07 2e52060084 cmd/go: refactor usage of `RootMode`
+ 2025-10-07 f86ddb54b5 cmd/go: refactor usage of `ForceUseModules`
+ 2025-10-07 c938051dd0 Revert "cmd/compile: redo arm64 LR/FP save and restore"
+ 2025-10-07 6469954203 runtime: assert p.destroy runs with GC not running
+ 2025-10-06 4c0fd3a2b4 internal/goexperiment: remove the synctest GOEXPERIMENT
+ 2025-10-06 c1e6e49d5d fmt: reduce Errorf("x") allocations to match errors.New("x")
+ 2025-10-06 7fbf54bfeb internal/buildcfg: enable greenteagc experiment by default
+ 2025-10-06 7bfeb43509 cmd/go: refactor usage of `initialized`
+ 2025-10-06 1d62e92567 test/codegen: make sure assignment results are used.
+ 2025-10-06 4fca79833f runtime: delete redundant code in the page allocator
+ 2025-10-06 719dfcf8a8 cmd/compile: redo arm64 LR/FP save and restore
+ 2025-10-06 f3312124c2 runtime: remove batching from spanSPMC free
+ 2025-10-06 24416458c2 cmd/go: export type State
+ 2025-10-06 c2fb15164b testing/synctest: remove Run
+ 2025-10-06 ac2ec82172 runtime: bump thread count slack for TestReadMetricsSched
+ 2025-10-06 e74b224b7c crypto/tls: streamline BoGo testing w/ -bogo-local-dir
+ 2025-10-06 3a05e7b032 spec: close tag
+ 2025-10-03 2a71af11fc net/url: improve URL docs
+ 2025-10-03 ee5369b003 cmd/link: add LIBRARY statement only with -buildmode=cshared
+ 2025-10-03 1bca4c1673 cmd/compile: improve slicemask removal
+ 2025-10-03 38b26f29f1 cmd/compile: remove stores to unread parameters
+ 2025-10-03 003b5ce1bc cmd/compile: fix SIMD const rematerialization condition
+ 2025-10-03 d91148c7a8 cmd/compile: enhance prove to infer bounds in slice len/cap calculations
+ 2025-10-03 20c9377e47 cmd/compile: enhance the chunked indexing case to include reslicing
+ 2025-10-03 ad3db2562e cmd/compile: handle rematerialized op for incompatible reg constraint
+ 2025-10-03 18cd4a1fc7 cmd/compile: use the right type for spill slot
+ 2025-10-03 1caa95acfa cmd/compile: enhance prove to deal with double-offset IsInBounds checks
+ 2025-10-03 ec70d19023 cmd/compile: rewrite to elide Slicemask from len==c>0 slicing
+ 2025-10-03 10e7968849 cmd/compile: accounts rematerialize ops's output reginfo
+ 2025-10-03 ab043953cb cmd/compile: minor tweak for race detector
+ 2025-10-03 ebb72bef44 cmd/compile: don't treat devel compiler as a released compiler
+ 2025-10-03 c54dc1418b runtime: support valgrind (but not asan) in specialized malloc functions
+ 2025-10-03 a7917eed70 internal/buildcfg: enable specializedmalloc experiment
+ 2025-10-03 630799c6c9 crypto/tls: add flag to render HTML BoGo report
Change-Id: I6bf904c523a77ee7d3dea9c8ae72292f8a5f2ba5
Use our local git server instead of cloud.google.com/go,
which may go down or otherwise reject our traffic.
I built and installed git 2.23.0 and confirmed that this
updated test still fails if CL 196961 is rolled back.
So the test is still accurate at detecting the problem.
Change-Id: I58011f6cc62af2f21fbbcc526ba5401f4186eeaf
Reviewed-on: https://go-review.googlesource.com/c/go/+/720322
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@google.com>
A direct cycle is the most basic form of cycle, where no type literal or
predeclared type is reached. It is formed by a series of only TypeNames.
To illustrate, type T T is a direct cycle, but type T [1]T and type T *T
are not. Likewise, the below is also a direct cycle:
type A B
type B C
type C = A
Direct cycles are handled explicitly as part of resolveUnderlying, since
they are the only cycle which can prevent reaching an underlying type.
If we move this check to an earlier compiler phase, we can simplify
resolveUnderlying.
This is the first of (hopefully) several cycle kinds to be moved into a
preliminary phase, with the goal of simplifying the main type-checking
pass. For that reason, the bulk of the logic is placed in cycles.go.
CL based on an earlier version by Mark Freeman.
Change-Id: I3044c383278deb6acb8767c498d8cb68099ba8ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/717343
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: 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>
This commit conslidates global variables represeting the current
modfetch state into a single variable in preparation for injection via
the rsc.io/rf tool.
This commit is part of the larger effort to eliminate global module
loader state.
[git-generate]
cd src/cmd/go/internal/modfetch
rf '
add State func NewState() *State {\
s := new(State)\
s.lookupCache = new(par.Cache[lookupCacheKey, Repo])\
s.downloadCache = new(par.ErrCache[module.Version, string])\
return s\
}
add State var ModuleFetchState *State = NewState()
mv State.goSumFile State.GoSumFile
add State:/^[[:space:]]*GoSumFile /-0 // path to go.sum; set by package modload
ex {
GoSumFile -> ModuleFetchState.GoSumFile
}
mv State.workspaceGoSumFiles State.WorkspaceGoSumFiles
add State:/^[[:space:]]*WorkspaceGoSumFiles /-0 // path to module go.sums in workspace; set by package modload
ex {
WorkspaceGoSumFiles -> ModuleFetchState.WorkspaceGoSumFiles
}
add State:/^[[:space:]]*lookupCache /-0 // The Lookup cache is used cache the work done by Lookup.\
// It is important that the global functions of this package that access it do not\
// do so after they return.
add State:/^[[:space:]]*downloadCache /-0 // The downloadCache is used to cache the operation of downloading a module to disk\
// (if it'\\\''s not already downloaded) and getting the directory it was downloaded to.\
// It is important that downloadCache must not be accessed by any of the exported\
// functions of this package after they return, because it can be modified by the\
// non-thread-safe SetState function.
add State:/^[[:space:]]*downloadCache.*$/ // version → directory;
ex {
lookupCache -> ModuleFetchState.lookupCache
downloadCache -> ModuleFetchState.downloadCache
}
rm 'lookupCache'
rm 'downloadCache'
'
for dir in modload ; do
cd ../${dir}
rf '
ex {
import "cmd/go/internal/modfetch"
modfetch.GoSumFile -> modfetch.ModuleFetchState.GoSumFile
modfetch.WorkspaceGoSumFiles -> modfetch.ModuleFetchState.WorkspaceGoSumFiles
}
'
done
cd ../modfetch
rf '
rm GoSumFile
rm WorkspaceGoSumFiles
'
Change-Id: Iaa0f8a40192127457a539120eb94337940cb8d4a
Reviewed-on: https://go-review.googlesource.com/c/go/+/719700
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
In normal use by the go command, ReadZip always happens after Stat,
which makes sure that the relevant revision has been fetched to
local disk. But TestReadZip calls ReadZip directly, and ReadZip was not
ensuring that fetch had happened.
This made 'go test' pass (because other earlier tests had done Stat of
the hg test repo) but 'go test -run=ReadZip' fail by itself.
And on big enough machines, the tests that were doing the Stat
were running in parallel with ReadZip, causing non-deterministic
failures depending on whether the Stat completed before ReadZip started.
Fix the race by calling Stat directly in ReadZip, like we already do in ReadFile.
Fixes longtest builder flake.
Change-Id: Ib42f64876b7ef51d8148c616539b412b42f8b24e
Reviewed-on: https://go-review.googlesource.com/c/go/+/720280
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Today, Ps jump around arbitrarily across STW. Instead, try to keep the P
on the previous M it ran on. In the future, we'll likely want to try to
expand this beyond STW to create a more general affinity for specific
Ms.
For this to be useful, the Ps need to have runnable Gs. Today, STW
preemption goes through goschedImpl, which places the G on the global
run queue. If that was the only G then the P won't have runnable
goroutines anymore.
It makes more sense to keep the G with its P across STW anyway, so add a
special case to goschedImpl for that.
On my machine, this CL reduces the error rate in TestTraceSTW from 99.8%
to 1.9%.
As a nearly 2% error rate shows, there are still cases where this best
effort scheduling doesn't work. The most obvious is that while
procresize assigns Ps back to their original M, startTheWorldWithSema
calls wakep to start a spinning M. The spinning M may steal a goroutine
from another P if that P is too slow to start.
For #65694.
Change-Id: I6a6a636c0969c587d039b68bc68ea16c74ff1fc9
Reviewed-on: https://go-review.googlesource.com/c/go/+/714801
Reviewed-by: 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>
The goroutine leak profile tests currently rely on a function being
inlined, which results in a slightly different representation in the
pprof proto. This function is not inlined on the noopt builder.
Disable inlining of the one function which could be inlined to align but
the regular and noopt builder versions of this test. We're not
interested in testing the inlining functionality of profiles with this
test, we care about certain stack frames appearing in a certain order.
This also simplifies a bunch of the checking in the test.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-noopt
Change-Id: I28902cc4c9fae32d1e3fa41b93b00c3be4d6074a
Reviewed-on: https://go-review.googlesource.com/c/go/+/720100
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>
Add support for compressed instructions in the RISC-V assembler. This
implements instruction validation and encoding for all instructions in
the "C" extension.
It is worth noting that the validation and encoding of these instructions
is far more convoluted then the typical instruction validation and
encoding. While the current model has been followed for now, it would be
worth revisiting this in the future and potentially switching to a table
based or even per-instruction implementation.
Additionally, the current instruction encoding is lacking some of the bits
needed for compressed instructions - this is solved by compressedEncoding,
which provides the missing information. This will also be addressed in the
future, likely by changing the instruction encoding format.
Updates #71105
Change-Id: I0f9359d63f93ebbdc6e708e79429b2d61eae220d
Reviewed-on: https://go-review.googlesource.com/c/go/+/713020
Reviewed-by: Mark Ryan <markdryan@rivosinc.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com>
There are two places in cmd/go where cleanups are stopped before they
fire, and where the objects the cleanups are attached to may be dead
while we call Stop. This is essentially a race between Stop and the
cleanup being called. This can be fine, but these cleanups are used as
a way to check some invariants, so just panic if they're executed. As a
result, if they fire erroneously, they'll take down the whole process,
even if no invariant was actually violated.
The runtime.Cleanup.Stop documentation explains that users of Stop need
to hold the object alive across the call to Stop if they want to be sure
that Stop succeeds, so do that here by adding an explicit
runtime.KeepAlive call.
Kudos to Michael Pratt for finding the issue.
Fixes#74780.
Change-Id: I22e6f4642ac68f727ca3781f5d39a85015047925
Reviewed-on: https://go-review.googlesource.com/c/go/+/719961
Auto-Submit: Michael Knyszek <mknyszek@google.com>
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>
The NIH tests simply failed to allocate the nodes outside the heap at
all. The Manual tests failed to keep the nodes alive, allowing the GC to
collect them.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest
Change-Id: I6a6a636c434bb703d6888383d32dbf95fb0a15ea
Reviewed-on: https://go-review.googlesource.com/c/go/+/719962
TryBot-Bypass: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
It is only ever called with a newly allocated slice.
This clearing code dates back to the C version of the compiler,
in which the function started like this:
static void
gengcmask(Type *t, uint8 gcmask[16])
{
...
memset(gcmask, 0, 16);
if(!haspointers(t))
return;
That memset was required for C, but not for Go.
Change-Id: I6fceb99b2dc8682685dca2e4289fcd58e2e5a0e0
Reviewed-on: https://go-review.googlesource.com/c/go/+/718340
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
The stackalloc code needs to run a liveness pass to build the
interference graph between stack slots. Because the values that we need
liveness over is so sparse, we can optimize the analysis by using a path
exploration algorithm rather than a iterative dataflow one
In local testing, this cuts 74.05 ms of CPU time off a build of cmd/compile.
Change-Id: I765ace87d5e8aae177e65eb63da482e3d698bea7
Reviewed-on: https://go-review.googlesource.com/c/go/+/718540
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Move the BetterTLS test suite from crypto/tls to crypto/x509. Despite
the name, the test suites we care about are actually related to X.509
path building and name constraint checking. As such it makes more sense
to include these in the crypto/x509 package, so we are more likely to
catch breaking behaviors during local testing.
Change-Id: I5237903dcc9d9f60d6c7070db3c996ceb643b04c
Reviewed-on: https://go-review.googlesource.com/c/go/+/719120
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Auto-Submit: Roland Shoemaker <roland@golang.org>
Cleaned up goroutine leak profile extraction:
- removed the acquisition of goroutineProfile semaphore
- inlined the call to saveg when recording stacks instead of using
doRecordGoroutineProfile, which had side-effects over
goroutineProfile fields.
Added regression tests for goroutine leak profiling frontend for binary
and debug=1 profile formats.
Added stress tests for concurrent goroutine and goroutine leak profile requests.
Change-Id: I55c1bcef11e9a7fb7699b4c5a2353e594d3e7173
GitHub-Last-Rev: 5e9eb3b1d8
GitHub-Pull-Request: golang/go#76045
Reviewed-on: https://go-review.googlesource.com/c/go/+/714580
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
This CL generates optimizations for masked variant of AVX512
instructions for patterns:
x.Op(y).Merge(z, mask) => OpMasked(z, x, y mask), where OpMasked is
resultInArg0.
Change-Id: Ife7ccc9ddbf76ae921a085bd6a42b965da9bc179
Reviewed-on: https://go-review.googlesource.com/c/go/+/718160
Reviewed-by: David Chase <drchase@google.com>
TryBot-Bypass: Junyang Shao <shaojunyang@google.com>
This will be used by CL 714801 to remove Ms from the middle of the list.
We could simply convert schedlink to the doubly-linked list, bringing
along all other uses of schedlink.
However, CL 714801 removes Ms from the middle of the midle list. It
would be an easy mistake to make to accidentally remove an M from
schedlink, assuming that it is on the midle list when it is actually on
a completely different list. Using separate a list node makes this
impossible.
For #65694.
Change-Id: I6a6a636c223d925fdc30c0c648460cbf5c2af4d6
Reviewed-on: https://go-review.googlesource.com/c/go/+/714800
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
When we added -reuse in CL 411398, we only handled Git repos.
This was partly because we were focused on Git traffic,
partly because Git is the dominant module VCS, and
partly because I couldn't see how to retrieve the metadata needed
in other version control systems.
This CL adds -reuse support for Mercurial, the second
most popular VCS for modules, now that I see how to
implement it. Although the Mercurial command line does
not have sufficient information, the Mercurial Python API does,
so we ship and invoke a Mercurial extension written in Python
that can compute a hash of the remote repo without downloading
it entirely, as well as resolve a remote name to a hash or check
the continued existence of a hash. Then we can avoid
downloading the repo at all if it hasn't changed since the last check
or if the specific reference we need still resolves or exists.
Fixes#75119.
Change-Id: Ia47d89b15c1091c44efef9d325270fc400a412c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/718382
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The current implementation followed the spec faithfully for
the special case for append. Per the spec:
As a special case, append also accepts a first argument assignable to
type []byte with a second argument of string type followed by ... .
As it happens, nil is assignable to []byte, so append(nil, ""...)
didn't get an error message but a subsequent assertion failed.
This CL ensures that the first argument to append is never nil and
always a slice. We should make the spec more precise (separate CL).
Fixes#76220.
Change-Id: I581d11827a75afbb257077814beea813d4fe2441
Reviewed-on: https://go-review.googlesource.com/c/go/+/718860
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Brett Howell <devbrett90@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently this lock is treated like a leaf lock, but it's not one. It
can acquire the globalAlloc lock via fixalloc and persistentalloc.
This means we need to figure out where it can be acquired. In general,
it can be acquired by any write barrier, which is already incredibly
broad. AFAICT, it can't be acquired directly otherwise, except when
destroying a spanSPMC during procresize, in which case we'll be holding
sched.lock.
Fixes#75916.
Change-Id: I2da1f5b82c750bf4e8d6a8a562046b9a17fd44be
Reviewed-on: https://go-review.googlesource.com/c/go/+/717500
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Large integer constants can take up to 4 instructions to encode.
We can encode some large constants with a single instruction, namely
those which are bit patterns (repetitions of certain runs of 0s and 1s).
Often the constants we want to encode are *close* to those bit patterns,
but don't exactly match. For those, we can use 2 instructions, one to
load the close-by bit pattern and one to fix up any mismatches.
The constants we use to strength reduce divides often fit this pattern.
For unsigned divides by 1 through 15, this CL applies to the constant
for N=3,5,6,10,12,15.
Triggers 17 times in hello world.
Change-Id: I623abf32961fb3e74d0a163f6822f0647cd94499
Reviewed-on: https://go-review.googlesource.com/c/go/+/717900
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@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
__msan_memmove records the fact that we're copying memory, and
actually does the copy. Use instead __msan_copy_shadow, which
records the fact that we're copying memory, but doesn't actually
do the copy itself.
We're doing the copy ourselves, so we don't need msan to do it also.
More importantly, msan doing the copy clobbers the target before
we issue the write barrier, which causes pointers to get lost.
Fixes#76138
Change-Id: I17aea739f9444de21fac2bbfd81e48534a39481d
Reviewed-on: https://go-review.googlesource.com/c/go/+/719020
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: t hepudds <thepudds1460@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Radu Berinde <radu@cockroachlabs.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The reuse_hg.txt is reuse_git.txt with a skip at the top
and a global substitute of git->hg and fetch->pull.
The prefixtagtests.txt and tagtests.txt are straight
copies of the git equivalents.
This is to set up a readable diff in the followup CL
that turns it into a reuse test for hg.
For #75119.
Change-Id: I50c7f5559ee6479f8328ed54c14eafcc7f1ecc1f
Reviewed-on: https://go-review.googlesource.com/c/go/+/718381
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This CL improves the error messages after panics due to the
sharing of an unpinned Go pointer (or a pointer to an unpinned Go
pointer) between Go and C.
This occurs when it is:
1. returned from Go to C (through cgoCheckResult)
2. passed as argument to a C function (through cgoCheckPointer).
An unpinned Go pointer refers to a memory location that might be moved or
freed by the garbage collector.
Therefore:
- change the signature of cgoCheckArg (it does the real work behind
cgoCheckResult and cgoCheckPointer)
- change the signature of cgoCheckUnknownPointer (called by cgoCheckArg
for checking unexpected pointers)
- introduce cgoFormatErr (it is called by cgoCheckArg and
cgoCheckUnknownPointer to format panic error messages)
- update the cgo pointer tests (add new tests, and a field errTextRegexp
to the struct ptrTest)
- remove a loop variable in TestPointerChecks (similar to CL 711640).
1. cgoCheckResult
When an unpinned Go pointer (or a pointer to an unpinned Go pointer) is
returned from Go to C,
1 package main
2
3 /*
4 #include <stdio.h>
5
6 extern void* GoFoo();
7
8 static void CFoo() { GoFoo();}
9 */
10 import (
11 "C"
12 )
13
14 //export GoFoo
15 func GoFoo() map[int]int {
16 return map[int]int{0: 1,}
17 }
18
19 func main() {
20 C.CFoo();
21 }
This error shows up at runtime:
panic: runtime error: cgo result is unpinned Go pointer or points to unpinned Go pointer
goroutine 1 [running]:
main._Cfunc_CFoo()
_cgo_gotypes.go:46 +0x3a
main.main()
/mnt/tmp/parse.go:20 +0xf
exit status 2
GoFoo is the faulty Go function; it is not mentioned in the error message.
Moreover the error does not say which kind of pointer caused the panic; for
instance, a Go map.
Retrieve name and file/line of the Go function, as well as the kind of
pointer; use them in the error message:
panic: runtime error: /mnt/tmp/parse.go:15: result of Go function GoFoo called from cgo is unpinned Go map or points to unpinned Go map
goroutine 1 [running]:
main._Cfunc_CFoo()
_cgo_gotypes.go:46 +0x3a
main.main()
/mnt/tmp/parse.go:20 +0xf
exit status 2
2. cgoCheckPointer
When a pointer to an unpinned Go pointer is passed to a C function,
1 package main
2
3 /*
4 #include <stdio.h>
5 void foo(void *bar) {}
6 */
7 import "C"
8 import "unsafe"
9
10 func main() {
11 m := map[int]int{0: 1,}
12 C.foo(unsafe.Pointer(&m))
13 }
This error shows up at runtime:
panic: runtime error: cgo argument has Go pointer to unpinned Go pointer
goroutine 1 [running]:
main.main.func1(...)
/mnt/tmp/cgomap.go:12
main.main()
/mnt/tmp/cgomap.go:12 +0x91
exit status 2
Retrieve kind of pointer; use it in the error message.
panic: runtime error: argument of cgo function has Go pointer to unpinned Go map
goroutine 1 [running]:
main.main.func1(...)
/mnt/tmp/cgomap.go:12
main.main()
/mnt/tmp/cgomap.go:12 +0x9b
exit status 2
Link: https://pkg.go.dev/cmd/cgo#hdr-Passing_pointers
Suggested-by: Ian Lance Taylor <iant@golang.org>
Fixes#75856
Change-Id: Ia72f01df016feeae0cddb2558ced51a1b07e4486
GitHub-Last-Rev: 76257c7dd7
GitHub-Pull-Request: golang/go#75894
Reviewed-on: https://go-review.googlesource.com/c/go/+/711801
Reviewed-by: Funda Secgin <fundasecgin73@gmail.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
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>
The .gopclntab section should not have any relocations.
Move it out of relro to regular rodata.
Note that this is tested by tests like TestNoTextrel in
cmd/cgo/internal/testshared.
The existing test TestMachoSectionsReadOnly looks for sections in a
Mach-O file that are read-only after relocations are applied
(this is marked by a segment with a flags field set to 0x10).
We remove the __gopclntab section, as that section is now read-only
at all times, not only after relocating.
For #76038
Change-Id: I7f837e423bf1e802509277f5dc7fdd1ed0228e32
Reviewed-on: https://go-review.googlesource.com/c/go/+/718065
Reviewed-by: Russ Cox <rsc@golang.org>
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>
Symbols loaded from host files can have the N_WEAK_REF bit set,
which is used to instruct the loader to not fail if that symbol
can't be resolved.
The Go internal linker should honor this information by setting the
BIND_SYMBOL_FLAGS_WEAK_IMPORT flag in the corresponding bind table
entry.
Fixes#76023
Cq-Include-Trybots: luci.golang.try:gotip-darwin-amd64-longtest,gotip-darwin-amd64_12,gotip-darwin-arm64_12,gotip-darwin-arm64_15,gotip-darwin-arm64-longtest,gotip-darwin-amd64_14
Change-Id: Id2cef247ec7a9cb08455844f3c30ff874772bb7b
Reviewed-on: https://go-review.googlesource.com/c/go/+/713760
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Most darwin systems don't have pkg-config installed and skip this test.
(And it doesn't run in all.bash because it is skipped during -short.)
But for those systems that have pkg-config and run the non-short tests,
it fails because the code was not writing out the bar.pc on darwin and
then expecting pkg-config to be able to tell us about the bar package.
Change the code to write out the bar entry always.
Fixes one failing case in 'go test cmd/go' on my Mac.
Change-Id: Ibc4e9826a652ce2e7c609b905b159ccf2d5a6444
Reviewed-on: https://go-review.googlesource.com/c/go/+/718182
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This test assumes that changing GOOS/GOARCH results in an
unrunnable binary, but that's not true if the user has
go_GOOS_GOARCH_exec programs in their path (like I do).
This test was timing out waiting to create a gomote to run
a windows/amd64 binary.
Rewrite the test not to assume that alternate GOOS/GOARCH
binaries are unrunnable.
Fixes one failing case in 'go test cmd/go' on my Mac.
Change-Id: Ib5f721f91e10d285820efb5995a3a9bc29833214
Reviewed-on: https://go-review.googlesource.com/c/go/+/718180
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
Instead of iterating until dataflow stabilization, fill in values known to be
live at the beginning of loop headers. This reduces the number of passes
over the CFG from the depth of the loopnest to just 2.
In a test instrumented version of this change, run against
cmd/compile/internal/ssa, it brought the time spent in liveness analysis
down to 150.52ms from 225.49ms on my machine.
Change-Id: Ic72762eedfd1f10b1ba74c430ed62ab4ebd3ec5c
Reviewed-on: https://go-review.googlesource.com/c/go/+/695255
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
We don't need to check that the bit patterns of the constants
match, it is sufficient to just check the constant is equal to the
given value.
While we're here also change the FCLASSD rules to use a bit pattern
for the mask. I think this improves readability, particularly as
more uses of FCLASSD get added (e.g. CL 717560).
These changes should not affect codegen.
Change-Id: I92a6338dc71e6a71e04306f67d7d86016c6e9c47
Reviewed-on: https://go-review.googlesource.com/c/go/+/717580
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Propagate "unread" across OpMoves. If the addr of this auto is only used
by an OpMove as its source arg, and the OpMove's target arg is the addr
of another auto. If the 2nd auto can be eliminated, this one can also be
eliminated.
This CL eliminates unnecessary memory copies and makes the frame smaller
in the following code snippet:
func contains(m map[string][16]int, k string) bool {
_, ok := m[k]
return ok
}
These are the benchmark results followed by the benchmark code:
goos: linux
goarch: amd64
cpu: Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz
│ old.txt │ new.txt │
│ sec/op │ sec/op vs base │
Map1Access2Ok-8 9.582n ± 2% 9.226n ± 0% -3.72% (p=0.000 n=20)
Map2Access2Ok-8 13.79n ± 1% 10.24n ± 1% -25.77% (p=0.000 n=20)
Map3Access2Ok-8 68.68n ± 1% 12.65n ± 1% -81.58% (p=0.000 n=20)
package main_test
import "testing"
var (
m1 = map[int]int{}
m2 = map[int][16]int{}
m3 = map[int][256]int{}
)
func init() {
for i := range 1000 {
m1[i] = i
m2[i] = [16]int{15:i}
m3[i] = [256]int{255:i}
}
}
func BenchmarkMap1Access2Ok(b *testing.B) {
for i := range b.N {
_, ok := m1[i%1000]
if !ok {
b.Errorf("%d not found", i)
}
}
}
func BenchmarkMap2Access2Ok(b *testing.B) {
for i := range b.N {
_, ok := m2[i%1000]
if !ok {
b.Errorf("%d not found", i)
}
}
}
func BenchmarkMap3Access2Ok(b *testing.B) {
for i := range b.N {
_, ok := m3[i%1000]
if !ok {
b.Errorf("%d not found", i)
}
}
}
Fixes#75398
Change-Id: If75e9caaa50d460efc31a94565b9ba28c8158771
Reviewed-on: https://go-review.googlesource.com/c/go/+/702875
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
The exact meaning of pow10 was not defined nor tested directly.
Define it as pow10(e) returns mant, exp where mant/2^128 * 2**exp = 10^e.
This is the most natural definition but is off-by-one from what
it had been returning. Fix the off-by-one and then adjust the
call sites to stop compensating for it.
Change-Id: I9ee475854f30be4bd0d4f4d770a6b12ec68281fe
Reviewed-on: https://go-review.googlesource.com/c/go/+/717180
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
net/http/cgi.TestCopyError calls runtime.Stack to take a stack trace of
all goroutines, and searches for a specific line in that stack trace.
It currently sometimes fails because it encounters the goroutine its
looking for in the small window where a goroutine might be in _Grunning
while in a syscall, introduced in CL 646198. In that case, the traceback
will give up, failing to print the stack TestCopyError is expecting.
This represents a general regression, since previously runtime.Stack
could never fail to take a goroutine's stack; giving up was only
possible in fatal panic cases.
Fix this the same way we fixed goroutine profiles: allow the stack trace
to proceed if the g's syscallsp != 0. This is safe in any
stop-the-world-related context, because syscallsp won't be mutated while
the goroutine fails to acquire a P, and thus fails to fully exit the
syscall context. This also means the stack below syscallsp won't be
mutated, and thus taking a traceback is also safe.
Fixes#66639.
Change-Id: Ie6f4b0661d9f8df02c9b8434e99bc95f26fe5f0d
Reviewed-on: https://go-review.googlesource.com/c/go/+/716680
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This makes the user experience better, before users would receive
an unknown godebug error message, now we explicitly mention that
it was removed and link to go.dev/doc/godebug where users can find
more information about the removal.
Additionally we keep all the removed GODEBUGs in the source, making
sure we do not reuse such GODEBUG after it is removed.
Updates #72111
Updates #75316
Change-Id: I6a6a6964cce1c100108fdba4bfba7d13cd9a893a
Reviewed-on: https://go-review.googlesource.com/c/go/+/701875
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Mateusz Poliwczak <mpoliwczak34@gmail.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
This commit adds test coverage of path building and name constraint
verification using the suite of test data provided by Netflix's
BetterTLS project.
Since the uncompressed raw JSON test data exported by BetterTLS for
external test integrations is ~31MB we use a similar approach to the
BoGo and ACVP test integrations and fetch the BetterTLS Go module, and
run its export tool on-the-fly to generate the test data in a tempdir.
As expected, all tests pass currently and this coverage is mainly
helpful in catching regressions, especially with tricky/cursed name
constraints.
Change-Id: I23d7c24232e314aece86bcbfd133b7f02c9e71b5
Reviewed-on: https://go-review.googlesource.com/c/go/+/717420
TryBot-Bypass: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Auto-Submit: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Michael Pratt <mpratt@google.com>
Support arm64 FMOVQ with large offset in immediate which is encoded
using register offset instruction in opldrr or opstrr. This will help
allowing folding immediate into new ssa ops FMOVQload and FMOVQstore.
For example: FMOVQ F0, -20000(R0) is encoded as following:
MOVD 3(PC), R27
FMOVQ F0, (R0)(R27)
RET
ffff b1e0 # constant value
Change-Id: Ib71f92f6ff4b310bda004a440b1df41ffe164523
Reviewed-on: https://go-review.googlesource.com/c/go/+/716960
Reviewed-by: Cherry Mui <cherryyz@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 Pratt <mpratt@google.com>
Intrinsifying things inside the module (crypto/internal/fips140/subtle)
is asking for trouble, as the import paths are rewritten by the
GOFIPS140 mechanism, and we might have to support multiple modules
in the future.
Importing crypto/subtle from inside a FIPS 140-3 module is not allowed,
and is basically asking for circular dependencies.
Instead, break off the intrinsics into their own package
(crypto/internal/constanttime), and keep the byte slice operations
in crypto/internal/fips140/subtle. crypto/subtle then becomes a thin
dispatch layer.
Change-Id: I6a6a6964cd5cb5ad06e9d1679201447f5a811da4
Reviewed-on: https://go-review.googlesource.com/c/go/+/716120
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Jorropo <jorropo.pgm@gmail.com>
In Go 1.23+, timer channels behave synchronously. When we have a timer
channel (i.e. !async && t.isChan) we would lock the
runtime.timer.sendLock mutex at the beginning of
runtime.timer.modify()'s execution.
Calling time.Timer.Reset(0) within a testing/synctest test,
unfortunately, causes it to hang indefinitely. This is because the
runtime.timer.sendLock mutex ends up being locked twice before it could
be unlocked:
- When calling time.Timer.Reset(), runtime.timer.modify() would lock the
mutex per usual.
- Due to the 0 argument, runtime.timer.modify() would also try to
execute the bubbled timer immediately rather than adding them to a
heap. However, in doing so, it uses runtime.timer.unlockAndRun(),
which also locks the same mutex.
This CL solves this issue by making sure that a locked
runtime.timer.sendLock mutex is unlocked first, whenever we try to
execute bubbled timer immediately in the stack.
Fixes#76052
Change-Id: I66429b9bf6971400de95dcf2d5dc9670c3135492
Reviewed-on: https://go-review.googlesource.com/c/go/+/716883
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Nicholas Husin <nsh@golang.org>
Reviewed-by: Nicholas Husin <husin@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
For some reason CL 646198 uncovered #3934 and #20018 again, but only in
race mode. It turns out that because racefini does not return, and
racefini is called early after main returns, we would not properly wait
for a concurrent panic to complete. This would result in fairly
consistent failures of TestPanicRace, which specifically looks for the
panic output to appear if main concurrently exits.
The important part of this change is that race mode will no longer have
the bug described in #3934 and #20018. A byproduct, however, is that
racefini is that we're essentially prioritizing the panic output over
racefini in this scenario. If racefini were to reveal a latent race
condition and fail, we'll prefer to surface the panic. Such a case is
probably fine, because the panic is always an crashing, unrecoverable
panic.
For #3934.
For #20018.
Change-Id: I0674a75c918563c5ec4ee1eec057dfd096fcfbc8
Reviewed-on: https://go-review.googlesource.com/c/go/+/691795
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
This change steals the performance trick from the coro implementation to
try to do the CAS directly first before calling into casgstatus, a much
more heavyweight function. We have to be careful about synctest
bubbling, but overall it's a good bit faster, and easy low-hanging
fruit.
goos: linux
goarch: amd64
pkg: internal/runtime/cgobench
cpu: AMD EPYC 7B13
│ after-2-2.out │ after-3.out │
│ sec/op │ sec/op vs base │
CgoCall-64 34.62n ± 1% 30.55n ± 1% -11.76% (p=0.002 n=6)
Change-Id: Ic38620233b55f58b8a07510666aa18648373e2e7
Reviewed-on: https://go-review.googlesource.com/c/go/+/708596
Auto-Submit: 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>
The current logic causes much more tracking than necessary, when really
_Grunning and _Gsyscall are both sort of "running" from the perspective
of tracking scheduling latency.
This makes cgo calls and syscalls a little faster in the single-threaded
case, and shows much larger improvement in the multi-threaded case
by removing updates of shared variables (though this parallel
microbenchmark is a little unrealistic, so don't ascribe too much weight
to it).
goos: linux
goarch: amd64
pkg: internal/runtime/cgobench
cpu: AMD EPYC 7B13
│ after.out │ after-2.out │
│ sec/op │ sec/op vs base │
CgoCall-64 35.83n ± 1% 34.69n ± 1% -3.20% (p=0.002 n=6)
CgoCallParallel-64 5.338n ± 1% 1.352n ± 4% -74.67% (p=0.002 n=6)
Change-Id: I2ea494dd5ebbbfb457373549986fbe2fbe318d45
Reviewed-on: https://go-review.googlesource.com/c/go/+/646275
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This change eliminates the _Psyscall state by using synchronization on
the G status _Gsyscall to make syscalls work instead. This removes an
atomic Store and an atomic CAS on the syscall path, which reduces
syscall and cgo overheads. It also simplifies the syscall paths quite a
bit.
The one danger with this change is that we have a new combination of
states that was previously impossible. There are brief windows where
it's possible to observe a goroutine in _Grunning but without a P. This
change is careful to hide this detail from the execution tracer, but it
may have unexpected effects in the rest of the runtime, making this
change somewhat risky.
goos: linux
goarch: amd64
pkg: internal/runtime/cgobench
cpu: AMD EPYC 7B13
│ before.out │ after.out │
│ sec/op │ sec/op vs base │
CgoCall-64 43.69n ± 1% 35.83n ± 1% -17.99% (p=0.002 n=6)
CgoCallParallel-64 5.306n ± 1% 5.338n ± 1% ~ (p=0.132 n=6)
Change-Id: I4551afc1eea0c1b67a0b2dd26b0d49aa47bf1fb8
Reviewed-on: https://go-review.googlesource.com/c/go/+/646198
Auto-Submit: 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>
Prove currently checks for 0 sign bit extraction (x>>63) at the
end of the pass, but it is more general and more useful
(and not really more work) to model right shift during
value range tracking. This handles sign bit extraction (both 0 and -1)
but also makes the value ranges available for proving bounds checks.
'go build -a -gcflags=-d=ssa/prove/debug=1 std'
finds 105 new things to prove.
https://gist.github.com/rsc/8ac41176e53ed9c2f1a664fc668e8336
For example, the compiler now recognizes that this code in
strconv does not need to check the second shift for being ≥ 64.
msb := xHi >> 63
retMantissa := xHi >> (msb + 38)
nor does this code in regexp:
return b < utf8.RuneSelf && specialBytes[b%16]&(1<<(b/16)) != 0
This code in math no longer has a bounds check on the first index:
if 0 <= n && n <= 308 {
return pow10postab32[uint(n)/32] * pow10tab[uint(n)%32]
}
The diff shows one "lost" proof in ycbcr.go but it's not really lost:
the expression was folded to a constant instead, and that only shows
up with debug=2. A diff of that output is at
https://gist.github.com/rsc/9139ed46c6019ae007f5a1ba4bb3250f
Change-Id: I84087311e0a303f00e2820d957a6f8b29ee22519
Reviewed-on: https://go-review.googlesource.com/c/go/+/716140
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: David Chase <drchase@google.com>
This CL implements Mul64uhilo, Hmul64, Hmul64u, and Avg64u
on 32-bit systems, with the effect that constant division of both
int64s and uint64s can now be emitted directly in all cases,
and also that bits.Mul64 can be intrinsified on 32-bit systems.
Previously, constant division of uint64s by values 0 ≤ c ≤ 0xFFFF were
implemented as uint32 divisions by c and some fixup. After expanding
those smaller constant divisions, the code for i/999 required:
(386) 7 mul, 10 add, 2 sub, 3 rotate, 3 shift (104 bytes)
(arm) 7 mul, 9 add, 3 sub, 2 shift (104 bytes)
(mips) 7 mul, 10 add, 5 sub, 6 shift, 3 sgtu (176 bytes)
For that much code, we might as well use a full 64x64->128 multiply
that can be used for all divisors, not just small ones.
Having done that, the same i/999 now generates:
(386) 4 mul, 9 add, 2 sub, 2 or, 6 shift (112 bytes)
(arm) 4 mul, 8 add, 2 sub, 2 or, 3 shift (92 bytes)
(mips) 4 mul, 11 add, 3 sub, 6 shift, 8 sgtu, 4 or (196 bytes)
The size increase on 386 is due to a few extra register spills.
The size increase on mips is due to add-with-carry being hard.
The new approach is more general, letting us delete the old special case
and guarantee that all int64 and uint64 divisions by constants are
generated directly on 32-bit systems.
This especially speeds up code making heavy use of bits.Mul64 with
a constant argument, which happens in strconv and various crypto
packages. A few examples are benchmarked below.
pkg: cmd/compile/internal/test
benchmark \ host local linux-amd64 s7 linux-386 s7:GOARCH=386
vs base vs base vs base vs base vs base
DivconstI64 ~ ~ ~ -49.66% -21.02%
ModconstI64 ~ ~ ~ -13.45% +14.52%
DivisiblePow2constI64 ~ ~ ~ +0.97% -1.32%
DivisibleconstI64 ~ ~ ~ -20.01% -48.28%
DivisibleWDivconstI64 ~ ~ -1.76% -38.59% -42.74%
DivconstU64/3 ~ ~ ~ -13.82% -4.09%
DivconstU64/5 ~ ~ ~ -14.10% -3.54%
DivconstU64/37 -2.07% -4.45% ~ -19.60% -9.55%
DivconstU64/1234567 ~ ~ ~ -61.55% -56.93%
ModconstU64 ~ ~ ~ -6.25% ~
DivisibleconstU64 ~ ~ ~ -2.78% -7.82%
DivisibleWDivconstU64 ~ ~ ~ +4.23% +2.56%
pkg: math/bits
benchmark \ host s7 linux-amd64 linux-386 s7:GOARCH=386
vs base vs base vs base vs base
Add ~ ~ ~ ~
Add32 +1.59% ~ ~ ~
Add64 ~ ~ ~ ~
Add64multiple ~ ~ ~ ~
Sub ~ ~ ~ ~
Sub32 ~ ~ ~ ~
Sub64 ~ ~ -9.20% ~
Sub64multiple ~ ~ ~ ~
Mul ~ ~ ~ ~
Mul32 ~ ~ ~ ~
Mul64 ~ ~ -41.58% -53.21%
Div ~ ~ ~ ~
Div32 ~ ~ ~ ~
Div64 ~ ~ ~ ~
pkg: strconv
benchmark \ host s7 linux-amd64 linux-386 s7:GOARCH=386
vs base vs base vs base vs base
ParseInt/Pos/7bit ~ ~ -11.08% -6.75%
ParseInt/Pos/26bit ~ ~ -13.65% -11.02%
ParseInt/Pos/31bit ~ ~ -14.65% -9.71%
ParseInt/Pos/56bit -1.80% ~ -17.97% -10.78%
ParseInt/Pos/63bit ~ ~ -13.85% -9.63%
ParseInt/Neg/7bit ~ ~ -12.14% -7.26%
ParseInt/Neg/26bit ~ ~ -14.18% -9.81%
ParseInt/Neg/31bit ~ ~ -14.51% -9.02%
ParseInt/Neg/56bit ~ ~ -15.79% -9.79%
ParseInt/Neg/63bit ~ ~ -15.68% -11.07%
AppendFloat/Decimal ~ ~ -7.25% -12.26%
AppendFloat/Float ~ ~ -15.96% -19.45%
AppendFloat/Exp ~ ~ -13.96% -17.76%
AppendFloat/NegExp ~ ~ -14.89% -20.27%
AppendFloat/LongExp ~ ~ -12.68% -17.97%
AppendFloat/Big ~ ~ -11.10% -16.64%
AppendFloat/BinaryExp ~ ~ ~ ~
AppendFloat/32Integer ~ ~ -10.05% -10.91%
AppendFloat/32ExactFraction ~ ~ -8.93% -13.00%
AppendFloat/32Point ~ ~ -10.36% -14.89%
AppendFloat/32Exp ~ ~ -9.88% -13.54%
AppendFloat/32NegExp ~ ~ -10.16% -14.26%
AppendFloat/32Shortest ~ ~ -11.39% -14.96%
AppendFloat/32Fixed8Hard ~ ~ ~ -2.31%
AppendFloat/32Fixed9Hard ~ ~ ~ -7.01%
AppendFloat/64Fixed1 ~ ~ -2.83% -8.23%
AppendFloat/64Fixed2 ~ ~ ~ -7.94%
AppendFloat/64Fixed3 ~ ~ -4.07% -7.22%
AppendFloat/64Fixed4 ~ ~ -7.24% -7.62%
AppendFloat/64Fixed12 ~ ~ -6.57% -4.82%
AppendFloat/64Fixed16 ~ ~ -4.00% -5.81%
AppendFloat/64Fixed12Hard -2.22% ~ -4.07% -6.35%
AppendFloat/64Fixed17Hard -2.12% ~ ~ -3.79%
AppendFloat/64Fixed18Hard -1.89% ~ +2.48% ~
AppendFloat/Slowpath64 -1.85% ~ -14.49% -18.21%
AppendFloat/SlowpathDenormal64 ~ ~ -13.08% -19.41%
pkg: crypto/internal/fips140/nistec/fiat
benchmark \ host s7 linux-amd64 linux-386 s7:GOARCH=386
vs base vs base vs base vs base
Mul/P224 ~ ~ -29.95% -39.60%
Mul/P384 ~ ~ -37.11% -63.33%
Mul/P521 ~ ~ -26.62% -12.42%
Square/P224 +1.46% ~ -40.62% -49.18%
Square/P384 ~ ~ -45.51% -69.68%
Square/P521 +90.37% ~ -25.26% -11.23%
(The +90% is a separate problem and not real; that much variation
can be seen on that system by running the same binary from two
different files.)
pkg: crypto/internal/fips140/edwards25519
benchmark \ host s7 linux-amd64 linux-386 s7:GOARCH=386
vs base vs base vs base vs base
EncodingDecoding ~ ~ -34.67% -35.75%
ScalarBaseMult ~ ~ -31.25% -30.29%
ScalarMult ~ ~ -33.45% -32.54%
VarTimeDoubleScalarBaseMult ~ ~ -33.78% -33.68%
Change-Id: Id3c91d42cd01def6731b755e99f8f40c6ad1bb65
Reviewed-on: https://go-review.googlesource.com/c/go/+/716061
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Fixed two issues in AVO based generator of amd64 asm code.
1. Updated golang.org/x/tools dependency to prevent build issue in Go 1.25.
> golang.org/x/tools@v0.24.0/internal/tokeninternal/tokeninternal.go:64:9:
> invalid array length -delta * delta (constant -256 of type int64)
This error was caused by changes in layout of data structures in Go. Package
golang.org/x/tools has a mirror of that struct and a static assert that it
matches the Go's struct.
2. Changed the package name from crypto/aes to crypto/internal/fips140/aes.
This fixed run time error:
> ctr_amd64_asm.go:31: could not find function "ctrBlocks1Asm"
and other errors
Now the following works as expected:
$ cd src/crypto/internal/fips140/aes/_asm/ctr/
$ go generate
The command re-generates file "src/crypto/internal/fips140/aes/ctr_amd64.s".
Fixes#75972
Change-Id: I28e4c9ebb5bf72506a524e36a0c81a1b50367a84
GitHub-Last-Rev: afc9f506e5
GitHub-Pull-Request: golang/go#75973
Reviewed-on: https://go-review.googlesource.com/c/go/+/712920
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Separate patterns in asmcheck by spaces instead of commas.
Many patterns end in comma (like "MOV [$]123,") so separating
patterns by comma is not great; they're already quoted, so spaces are fine.
Also replace all tabs in the assembly lines with spaces before matching.
Finally, replace \$ or \\$ with [$] as the matching idiom.
The effect of all these is to make the patterns look like:
// amd64:"BSFQ" "ORQ [$]256"
instead of the old:
// amd64:"BSFQ","ORQ\t\\$256"
Update all tests as well.
Change-Id: Ia39febe5d7f67ba115846422789e11b185d5c807
Reviewed-on: https://go-review.googlesource.com/c/go/+/716060
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Reviewed-by: Jorropo <jorropo.pgm@gmail.com>
We noticed some hand-translated code that used
nested functions as the translation of asm macros,
and they were too big to inline, and the resulting
performance was underwhelming. Any such closures
really need to be inlined.
Because Gerrit removed votes from a previous patch
set, and because in offline discussion we realized
that this was actually a hard-to-abuse inlining hack,
I decided to turn it up some more, and also add a
"this one goes to 11" joke. The number is utterly
unprincipled, only "simd is supposed to go fast,
and this is a natural use of closures, and we don't
want there to be issues where it doesn't go fast."
The test verifies that the inlining occurs for a
function that exceeds the current inlining threshold.
Inspection of the generated code shows that it has
the desired effect.
Change-Id: I7a8b57c07d6482e6d98cedaf9622c960f956834d
Reviewed-on: https://go-review.googlesource.com/c/go/+/715740
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Runtime doing its own number formatting dates back to
when runtime was the bottom-most Go package.
Those days are long gone. Use internal/strconv to avoid
duplicating code and also to get better floating-point
formatting:
% go1.24.6 run x.go
+1.234568e+004
% go run x.go
12345.678
%
With accurate floating point it becomes necessary to
introduce separate printers for float32 vs float64 and
for complex64 vs complex128. Otherwise float32(93.7)
prints as 93.69999694824219.
Change-Id: I25ae3f09519342dc3d1dcabf4711651423e00128
Reviewed-on: https://go-review.googlesource.com/c/go/+/716002
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
On AMD Genoa / Zen 4, VPCOMPRESSQ with a memory destination imposes a
severe performance penalty of another an order of magnitude compared to
a register destination.
We can trivially work around this penalty with a register destination
and an additional move to memory.
Benchmark results from:
$ go test -bench=BenchmarkScanSpanPacked/.*/.*/.*/.*/impl=Platform internal/runtime/gc/scan
I've only included the summarized geomean here because there are ~2500
unique test cases.
AMD Genoa (Zen 4):
cpu: AMD EPYC 9B14 96-Core Processor
│ mem │ reg │
│ sec/op │ sec/op vs base │
geomean 1.039µ 310.1n -70.16%
│ mem │ reg │
│ B/s │ B/s vs base │
geomean 2.906Gi 10.99Gi +278.27%
As expected, we see a massive performance improvement on Genoa.
AMD Turin (Zen 5):
cpu: AMD EPYC 9B45 128-Core Processor
│ mem │ reg │
│ sec/op │ sec/op vs base │
geomean 231.9n 237.3n +2.32%
│ mem │ reg │
│ B/s │ B/s vs base │
geomean 14.79Gi 14.43Gi -2.50%
On Turin there is a minor regression. This is primarily due to a fairly
large regression (~15%) in very small microbenchmark cases where the
entire memory fits in L1 cache. This regression disappears as memory
access slows down with larger memories. The latter should be more common
in real workloads.
Intel Sapphire Rapids:
cpu: Intel(R) Xeon(R) Platinum 8481C
│ mem │ reg │
│ sec/op │ sec/op vs base │
geomean 254.9n 246.8n -3.18%
│ mem │ reg │
│ B/s │ B/s vs base │
geomean 13.65Gi 14.15Gi +3.69%
On Sapphire Rapids there is a minor improvement. Here results are fairly
noisy. Most cases are a wash, but some are arbitrary 20% slower or 20%
faster for unclear reasons.
For #73581.
Change-Id: I6a6a636cfd294a0dcdc4f34c9ece1bc9a6e5e4c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/715362
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
If target is not comparable, then errors.Is(err, target) can panic.
(Put another way, if target == target panics, then Is can panic.)
Document that the target must be comparable.
For #74488
Change-Id: I694dc4c91a608b80f044f06dd1c6ac32b8e77c9c
Reviewed-on: https://go-review.googlesource.com/c/go/+/715440
Reviewed-by: Alan Donovan <adonovan@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
TryBot-Bypass: Damien Neil <dneil@google.com>
There is no need to hold locks for the entire chain of Named types in
resolveUnderlying. This change moves the locking / unlocking right to
where t.underlying is set.
This change consolidates logic into resolveUnderlying where possible
and makes minor stylistic / documentation adjustments.
Change-Id: Ic5ec5a7e9a0da8bc34954bf456e4e23a28df296d
Reviewed-on: https://go-review.googlesource.com/c/go/+/714403
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Mark Freeman <markfreeman@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Targeting crypto/subtle rather than
crypto/internal/fips140/subtle after discussion with Filippo.
goos: linux
goarch: amd64
pkg: crypto/subtle
cpu: AMD Ryzen 5 3600 6-Core Processor
│ /tmp/old.logs │ /tmp/new.logs │
│ sec/op │ sec/op vs base │
ConstantTimeSelect-12 0.5246n ± 1% 0.5217n ± 2% ~ (p=0.118 n=10)
ConstantTimeByteEq-12 1.0415n ± 1% 0.5202n ± 2% -50.05% (p=0.000 n=10)
ConstantTimeEq-12 0.7813n ± 2% 0.7819n ± 0% ~ (p=0.897 n=10)
ConstantTimeLessOrEq-12 1.0415n ± 3% 0.7813n ± 1% -24.98% (p=0.000 n=10)
geomean 0.8166n 0.6381n -21.86%
The last three will become 1 lat-cycle (0.25ns) faster once #76066 is fixed.
The Select being that fast with the old code is really impressive.
I am pretty sure this happens because my CPU has BMI1&2 support and
a fusing unit able to translate non BMI code into BMI code.
This benchmark doesn't capture the CACHE gains from the shorter assembly.
It currently compiles as:
v17 = TESTQ <flags> v31 v31 // v != 0
v20 = CMOVQNE <int> v32 v33 v17 (y[int])
It is possible to remove the `TESTQ` by compiletime fusing it with the
compare in a pattern like this:
subtle.ConstantTimeSelect(subtle.ConstantTimeLessOrEq(left, right), right, left)
Saving 2 latency-cycles (1 with #76066 fixed).
Updates #76056
Change-Id: I61a1df99e97a1506f75dae13db529f43846d8f1e
Reviewed-on: https://go-review.googlesource.com/c/go/+/715045
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Keith Randall <khr@google.com>
These new tests check a hypothesis about interactions
between CPU features and common subexpressions. Happily,
they hypothesis was not (yet) correct and the test did not
fail.
These are probably good to have in the corpus in case we
decide to tinker with the rewrite in the future, or if
someone wants to write a fuzzer and needs a little
inspiration.
Change-Id: I8ea6e1655a293c22e39bf53e4d2c5afd3dcb2510
Reviewed-on: https://go-review.googlesource.com/c/go/+/714803
Reviewed-by: Junyang Shao <shaojunyang@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Recently, we've changed the representation of Named type state from
an integer to a bit mask, which is a bit more complicated. To make
sure we uphold state invariants, we are adding a verification step
on each state transition.
This uncovered a few places where we do not uphold the transition
invariants; those are patched in this CL.
Change-Id: I76569e4326b2d362d7a1f078641029ffb3dca531
Reviewed-on: https://go-review.googlesource.com/c/go/+/714241
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>
This CL is part of a series of CLs to triangulate between the runtime,
compiler, and standard library to reduce how much work the GC must do.
An overall design document is in CL 700255.
This CL stack implements a runtime.free within the runtime, and
then uses it via automatic calls inserted by the compiler when
the compiler proves it is safe to do so. In the future, we can
also consider possibly a limited set of explicit calls from certain
low-level portions of the standard library.
When called, runtime.free allows immediate reuse of memory
without waiting for a GC cycle. The goals include less overall
CPU usage by the GC, longer times between GC cycles
(with less overall time with the write barrier enabled),
and more cache-friendly allocations for user code.
Here, we just add the GOEXPERIMENT=runtimefree flag. It currently
defaults to on, but can be disabled with GOEXPERIMENT=noruntimefree.
The actual implementation starts in CL 673695.
Updates #74299
Change-Id: I2f1f04dbdca51f4aaa735fd65bb2719c298d922e
Reviewed-on: https://go-review.googlesource.com/c/go/+/700235
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This commit modifies `runBuild` and `runInstall` to construct a new
modload.State object using the new constructor instead of the current
global `modload.LoaderState` variable.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/work
rf '
add build.go:/func runBuild\(/-0 var moduleLoaderState *modload.State
ex {
import "cmd/go/internal/modload";
modload.LoaderState -> moduleLoaderState
}
add runBuild://+0 moduleLoaderState := modload.NewState()
add runInstall://+0 moduleLoaderState := modload.NewState()
rm build.go:/var moduleLoaderState \*modload.State/
'
Change-Id: I1137e0b898a5bda8697dce8713f96f238ae8b76c
Reviewed-on: https://go-review.googlesource.com/c/go/+/711135
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Theses are not supported by the go compiler but it may helps porting to gccgo.
This is similar to reverting CL 712740 however unlike reverting:
- it fixes the build tags so that 32 & 64 bits
constraints are complement of each other
- it applies the same changes to os_linux_settime32.go and
os_linux_settime64.go since the four files are the exact same
fix of the same bug to different parts of the codebase.
It does not make sense for them to be different.
Change-Id: I08cdcb07e837a5e06ee6f04b7868a4c57b07dd56
Reviewed-on: https://go-review.googlesource.com/c/go/+/714080
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: 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>
This commit modifies `generate.runGenerate` to construct a new
modload.State object using the new constructor instead of the current
global `modload.LoaderState` variable.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/generate
rf '
add generate.go:/func runGenerate\(/-0 var moduleLoaderState *modload.State
ex {
import "cmd/go/internal/modload";
modload.LoaderState -> moduleLoaderState
}
add runGenerate://+0 moduleLoaderState := modload.NewState()
rm generate.go:/var moduleLoaderState \*modload.State/
'
Change-Id: Iea9d662ba47657aa5daa70d32117cdf52fd02b7e
Reviewed-on: https://go-review.googlesource.com/c/go/+/711132
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This commit modifies `env.runEnv` to construct a new modload.State
object using the new constructor instead of the current global
`modload.LoaderState` variable.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/envcmd
rf '
add env.go:/func runEnv\(/-0 var moduleLoaderState *modload.State
ex {
import "cmd/go/internal/modload";
modload.LoaderState -> moduleLoaderState
}
add runEnv://+0 moduleLoaderState := modload.NewState()
rm env.go:/var moduleLoaderState \*modload.State/
'
Change-Id: I1177df5d09a6ee642eade6cfa4278bb1629843a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/711131
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This commit modifies `vet.runVet` to construct a new modload.State
object using the new constructor instead of the current global
`modload.LoaderState` variable.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/vet
rf '
add vet.go:/func run\(/-0 var moduleLoaderState *modload.State
ex {
import "cmd/go/internal/modload";
modload.LoaderState -> moduleLoaderState
}
add run://+0 moduleLoaderState := modload.NewState()
rm vet.go:/var moduleLoaderState \*modload.State/
'
Change-Id: I31c7f3ea8d301b9210f5afeb632afb5b53e93e46
Reviewed-on: https://go-review.googlesource.com/c/go/+/711130
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
This commit modifies package `workcmd` to construct a new
modload.State object using the new constructor instead of the current
global `modload.LoaderState` variable.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/workcmd
rf '
inject modload.LoaderState runUse
add sync.go:/func runSync\(/-0 var moduleLoaderState *modload.State
ex {
import "cmd/go/internal/modload";
modload.LoaderState -> moduleLoaderState
}
add runSync://+0 moduleLoaderState := modload.NewState()
add runEditwork://+0 moduleLoaderState := modload.NewState()
add runInit://+0 moduleLoaderState := modload.NewState()
add runUse://+0 moduleLoaderState := modload.NewState()
add runVendor://+0 moduleLoaderState := modload.NewState()
rm sync.go:/var moduleLoaderState \*modload.State/
'
Change-Id: Iadc4ffd19d15f80a694285c86adfc01f0d26bac7
Reviewed-on: https://go-review.googlesource.com/c/go/+/711129
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This commit modifies `tool.runTool` to construct a new modload.State
object using the new constructor instead of the current global
`modload.LoaderState` variable.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/tool
rf '
add tool.go:/func runTool\(/-0 var moduleLoaderState *modload.State
ex {
import "cmd/go/internal/modload";
modload.LoaderState -> moduleLoaderState
}
add runTool://+0 moduleLoaderState := modload.NewState()
rm tool.go:/var moduleLoaderState \*modload.State/
'
Change-Id: I0aff1bc2b57d973c258510dc52fb877fa824355c
Reviewed-on: https://go-review.googlesource.com/c/go/+/711128
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
This commit modifies `test.runTest` to construct a new modload.State
object using the new constructor instead of the current global
`modload.LoaderState` variable.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/test
rf '
add test.go:/func runTest\(/-0 var moduleLoaderState *modload.State
ex {
import "cmd/go/internal/modload";
modload.LoaderState -> moduleLoaderState
}
add runTest://+0 moduleLoaderState := modload.NewState()
rm test.go:/var moduleLoaderState \*modload.State/
'
Change-Id: Ia387160f30818714ab578c5b78713e532cd394df
Reviewed-on: https://go-review.googlesource.com/c/go/+/711127
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@google.com>
This commit modifies `modget.runGet` to construct a new modload.State
object using the new constructor instead of the current global
`modload.LoaderState` variable.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/modget
rf '
add get.go:/func runGet\(/-0 var moduleLoaderState *modload.State
ex {
import "cmd/go/internal/modload";
modload.LoaderState -> moduleLoaderState
}
add runGet://+0 moduleLoaderState := modload.NewState()
rm get.go:/var moduleLoaderState \*modload.State/
'
Change-Id: I977c3f57c00b60d383ffd2c2c0d7bc90813c7988
Reviewed-on: https://go-review.googlesource.com/c/go/+/711126
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@google.com>
This commit modifies `modcmd.runDownload` to construct a new
modload.State object using the new constructor instead of the current
global `modload.LoaderState` variable.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/modcmd
rf '
add download.go:/func runDownload\(/-0 var moduleLoaderState *modload.State
ex {
import "cmd/go/internal/modload";
modload.LoaderState -> moduleLoaderState
}
add runDownload://+0 moduleLoaderState := modload.NewState()
add runEdit://+0 moduleLoaderState := modload.NewState()
add runGraph://+0 moduleLoaderState := modload.NewState()
add runInit://+0 moduleLoaderState := modload.NewState()
add runTidy://+0 moduleLoaderState := modload.NewState()
add runVendor://+0 moduleLoaderState := modload.NewState()
add runVerify://+0 moduleLoaderState := modload.NewState()
add runWhy://+0 moduleLoaderState := modload.NewState()
rm download.go:/var moduleLoaderState \*modload.State/
'
Change-Id: Id69deba173032a4d6da228eae28e38bd87176db5
Reviewed-on: https://go-review.googlesource.com/c/go/+/711125
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This commit modifies `list.runList` to construct a new modload.State
object using the new constructor instead of the current global
`modload.LoaderState` variable.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/list
rf '
add list.go:/func runList\(/-0 var moduleLoaderState *modload.State
ex {
import "cmd/go/internal/modload";
modload.LoaderState -> moduleLoaderState
}
add runList://+0 moduleLoaderState := modload.NewState()
rm list.go:/var moduleLoaderState \*modload.State/
'
Change-Id: I7f45205c1c946189eb05c6178d14ce74ae259547
Reviewed-on: https://go-review.googlesource.com/c/go/+/711124
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This commit modifies `bug.runBug` to construct a new modload.State
object using the new constructor instead of the current global
`modload.LoaderState` variable.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/bug
rf '
add bug.go:/func runBug\(/-0 var moduleLoaderState *modload.State
ex {
import "cmd/go/internal/modload";
modload.LoaderState -> moduleLoaderState
}
add runBug://+0 moduleLoaderState := modload.NewState()
rm bug.go:/var moduleLoaderState \*modload.State/
'
Change-Id: Ic4f74d2127f667491136ee4bad4388b4d606821e
Reviewed-on: https://go-review.googlesource.com/c/go/+/711123
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@google.com>
This commit modifies `run.runRun` to construct a new modload.State
object using the new constructor instead of the current global
`modload.LoaderState` variable.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/run
rf '
add run.go:/func runRun\(/-0 var moduleLoaderState *modload.State
ex {
import "cmd/go/internal/modload";
modload.LoaderState -> moduleLoaderState
}
add runRun://+0 moduleLoaderState := modload.NewState()
rm run.go:/var moduleLoaderState \*modload.State/
'
Change-Id: I76e56798b2e0d23a0fefe65d997740e3e411d99d
Reviewed-on: https://go-review.googlesource.com/c/go/+/711116
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This change modifies the type `mvsReqs` to have an additional field to
store the current module loader state. The field is used to break the
dependency on the global `modload.LoaderState` variable.
This commit is part of the overall effort to eliminate global
modloader state.
Change-Id: Id6bd96bc5de68bf327f9e78a778173634e1d15d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/711122
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently we use 64-bit hash calculations on Wasm. The 64-bit hash
calculation make intensive uses of 64x64->128 bit multiplications,
which on many 64-bit platforms are compiler intrinsics and can be
compiled to one or two instructions. This is not the case on Wasm,
so it is not very performant.
This CL makes it use 32-bit hashes on Wasm, just like other 32-bit
architectures. The 32-bit hash calculation only uses 32x32->64 bit
multiplications, which can be compiled efficiently on Wasm.
Using 32-bit hashes may increase the chance of collisions. But it
is the same as 32-bit architectures like 386. And our Wasm port
supports only 32-bit address space (like 386), so this is not too
bad.
Runtime Hash benchmark results
goos: js
goarch: wasm
pkg: runtime
│ 0h.txt │ 1h.txt │
│ sec/op │ sec/op vs base │
Hash5 20.45n ± 9% 14.06n ± 2% -31.21% (p=0.000 n=10)
Hash16 22.34n ± 7% 17.52n ± 1% -21.62% (p=0.000 n=10)
Hash64 47.47n ± 3% 28.68n ± 1% -39.59% (p=0.000 n=10)
Hash1024 475.4n ± 1% 271.4n ± 0% -42.92% (p=0.000 n=10)
Hash65536 28.42µ ± 1% 16.66µ ± 0% -41.40% (p=0.000 n=10)
HashStringSpeed 40.07n ± 7% 29.23n ± 1% -27.05% (p=0.000 n=10)
HashBytesSpeed 62.01n ± 3% 46.11n ± 4% -25.64% (p=0.000 n=10)
HashInt32Speed 24.31n ± 2% 20.39n ± 1% -16.13% (p=0.000 n=10)
HashInt64Speed 25.48n ± 7% 20.81n ± 7% -18.29% (p=0.000 n=10)
HashStringArraySpeed 87.69n ± 4% 76.65n ± 2% -12.58% (p=0.000 n=10)
FastrandHashiter 87.65n ± 1% 87.65n ± 1% ~ (p=0.896 n=10)
geomean 90.82n 67.03n -26.19%
Map benchmarks are too many to post here. The speedups are around
0-40%.
Change-Id: I2f7a68cfc446ab5a547fdb6a40aea07854516d51
Reviewed-on: https://go-review.googlesource.com/c/go/+/714600
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
The standard approach to constraint checking involves checking the
constraints during chain building. This is typically done as most chain
building algorithms want to find a single chain. We don't do this, and
instead build every valid chain we can find. Because of this, we don't
_need_ to do constraint checking during the chain building stage, and
instead can defer it until we have built all of the potentially valid
chains (we already do this for EKU nesting and policy checking).
This allows us to limit the constraints we check to only chains issued
by trusted roots, which reduces the attack surface for constraint
checking, which is an annoyingly algorithmically complex process (for
now).
To maintain previous behavior, if we see an error during constraint
checking, and we end up with no valid chains, we return the first
constraint checking error, instead of a more verbose error indicating
if there were different problems during filtering. At some point we
probably should come up with a more unified error type for chain
building that can contain information about multiple failure modes.
Change-Id: I5780b3adce8538eb4c3b56ddec52f0723d39009e
Reviewed-on: https://go-review.googlesource.com/c/go/+/713240
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Roland Shoemaker <roland@golang.org>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Previously, we put a jsontext.Encoder (or Decoder)
back into a pool with minimal reset logic.
This was semantically safe since we always did a full reset
after obtaining an Encoder/Decoder back out of the pool.
However, this meant that so long as an Encoder/Decoder was
alive in the pool, any application data referenced by the coder
would be kept alive longer than necessary.
Explicitly, clear such fields so that application data
can be more aggressively garbage collected.
Performance:
name old time/op new time/op delta
Unmarshal/Bool-32 52.0ns ± 3% 50.3ns ± 3% -3.30% (p=0.001 n=10+10)
Marshal/Bool-32 55.4ns ± 3% 54.4ns ± 2% -1.75% (p=0.006 n=10+9)
This only impacts the performance of discrete Marshal/Unmarshal calls.
For the simplest possible call (i.e., to marsha/unmarshal a bool),
there is a 1-2ns slow down. This is an appropriate slowdown
for an improvement in memory utilization.
Change-Id: I5e7d7827473773e53a9dcb3d7fe9052a75481e9f
Reviewed-on: https://go-review.googlesource.com/c/go/+/713640
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
TryBot-Bypass: Damien Neil <dneil@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Auto-Submit: Damien Neil <dneil@google.com>
This is semantically identical and just a cleanup.
Prior to #63397, JSON object names were sorted according to UTF-16
to match the semantic of RFC 8785, but there were a number of
objections in the discussion to using that as the sorting order.
In https://github.com/go-json-experiment/json/pull/121,
we switched to sorting by UTF-8, which matches the behavior
of v1 and avoids an option to toggle the behavior.
However, we should have deleted the stringSlice.Sort method
and just directly called slices.Sort.
From a principled perspective, both UTF-16 and UTF-8 are
reasonable ways to sort JSON object names.
RFC 8259 specifies that the entire JSON text is encoded as UTF-8.
However, the way JSON strings are encoded requires escaping
Unicode codepoints according to UTF-16 surragate halves
(a quirk of JavaScript inherited by JSON).
Thus, JSON is inconsistently both UTF-8 and UTF-16.
Change-Id: Id92b5cc20efe4201827e9d3fccf24ccf894d3e60
Reviewed-on: https://go-review.googlesource.com/c/go/+/713522
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Bypass: Damien Neil <dneil@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Damien Neil <dneil@google.com>
This change refactors the injection of the global
`modload.LoaderState` variable such that the injection can occur later
in the chain of function calls. This allows us to keep the behavior
of the global PerPackageFlags (e.g. BuildGcFlags, etc) consistent and
avoid introducing a dependency on the module loader state there.
This commit is part of the overall effort to eliminate global
modloader state.
Change-Id: I1a0cc07173a1804426392581ba8de4ae1e30cdef
Reviewed-on: https://go-review.googlesource.com/c/go/+/711115
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@google.com>
This change reworks the sentinel error value ErrNoModRoot and the type
noMainModulesError so that we can determine the appropriate error
message to display based on the loader state without depending on the
state directly.
This commit is part of the overall effort to eliminate global
modloader state.
Change-Id: I64de433faca96ed90fad4c153766c50575a72157
Reviewed-on: https://go-review.googlesource.com/c/go/+/711120
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
This change makes the following functions methods on the State:
* CheckAllowed
* CheckExclusions
* CheckRetractions
Doing so allows us to reduce the use of the global state variable in
downstream function calls.
This commit is part of the overall effort to eliminate global
modloader state.
Change-Id: I97147311d9de16ecac8c122c2b6bdde94bad9d8f
Reviewed-on: https://go-review.googlesource.com/c/go/+/711119
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This change modifies the type `QueryMatchesMainModulesError` to have
an additional field to store the current module loader state. The
field is used to break the dependency on the global
`modload.LoaderState` variable.
This commit is part of the overall effort to eliminate global
modloader state.
Change-Id: Ia2066fab9f3ec4ffdd3d7393dacdf65c0fd35b92
Reviewed-on: https://go-review.googlesource.com/c/go/+/711118
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
This change adds a new field to the Builder struct to store a function
to retrieve the current vendor directory. This allows us to delay the
determination of the vendor directory until later, which is currently
necessary to successful interaction with the module loader state.
This behavior will be changed in a future CL and the Builder field
will then be removed.
In addition, a new method to get the vendor dir from the module loader
state is added that will return the empty string instead of panicing.
This commit is part of the overall effort to eliminate global
modloader state.
Change-Id: Ib0165edb9502d98ddfa986acf5579c1b746a026f
Reviewed-on: https://go-review.googlesource.com/c/go/+/711133
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Named.resolve normalizes a named type's representation so that type
operations have a uniform surface to work with, regardless of how
the type was created.
This often gives the type a heavier footprint, such as when filling
in a lazy-loaded type from UIR, or expanding the RHS of an
instantiated type.
For that reason, it seems more appropriate to call this "unpacking"
the type, as it hints to this heavier form. The term "resolving"
is used in many contexts, and generally suggests that we are
trying to figure out what a name means.
Change-Id: Ia733fd68656380b2be4f7433b7b971b7c1422783
Reviewed-on: https://go-review.googlesource.com/c/go/+/713285
Auto-Submit: Mark Freeman <markfreeman@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Griesemer <gri@google.com>
This is a minor renaming to help differentiate the two kinds of loading
that can happen for named types (eager and lazy).
Use of the term "loaded" suggests that it might also apply to types
which are eagerly-loaded, which is not the case. This change uses
"lazyLoaded" instead to mark this difference.
Change-Id: Iee170024246d9adf3eed978bde2b0500f6d490b7
Reviewed-on: https://go-review.googlesource.com/c/go/+/713282
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Mark Freeman <markfreeman@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The complete namedState tracks whether an instantiated named type has
expanded all of its methods. In the past, this was the terminal state
of a linear lifecycle, and so a term like "complete" made sense.
Now that we've expanded the lifecycle of named types to a tree structure,
the complete namedState is no longer a terminal state, and so the term
"complete" is now a bit confusing.
This change a) makes the expansion aspect of the complete namedState more
explicit and b) removes a misleading suggestion of terminality by changing
the name from complete to hasMethods.
To take a similar naming convention with the underlying namedState, which
signals presence of Named.underlying, we rename the underlying namedState
to hasUnder.
Change-Id: I29fee26efea3de88c7c1240f2dc53df218acf8b4
Reviewed-on: https://go-review.googlesource.com/c/go/+/713280
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Mark Freeman <markfreeman@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
While the locking in Named.resolveUnderlying is mostly fine, we do not
perform an atomic read before the write to underlying.
If resolveUnderlying returns and another thread was waiting on the lock,
it can perform a second (in this case identical) write to t.underlying.
A reader thread on n.underlying can thus observe either of those writes,
tripping the race detector.
Michael was kind enough to provide a diagram:
T1 T2
1. t.stateHas(underlying) // false
2. t.stateHas(underlying) // false
3. t.mu.Lock() // acquired
4. t.mu.Lock() // blocked
5. t.underlying = u
6. t.setState(underlying)
7. t.mu.Unlock()
8. t.underlying = u // overwritten
9. t.setState(underlying)
10. t.mu.Unlock()
Adding a second check before setting t.underlying prevents the write on
line 8.
Change-Id: Ia43a6d3ba751caef436b9926c6ece2a71dfb9d38
Reviewed-on: https://go-review.googlesource.com/c/go/+/714300
Auto-Submit: Mark Freeman <markfreeman@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The crypto/internal/fips140/entropy package vendors a minimal
implementation of SHA2-384 to insulate it from changes in the FIPS
module implementation. This means it also requires ACVP testing separate
from the FIPS module implementation. This commit implements the
required ACVP testing support.
There's no way via the ACVP protocol, or acvptool, to specify that we
want to test a specific SHA2-384 implementation compared to normal. We
use a new environment variable (GOENTROPYSOURCEACVP=1) to make that
distinction.
The capabilities we advertise when testing the entropy SHA2-384
implementation are limited to something that best describes the
input sizes that the entropy module's implementation supports within the
requirements imposed by ACVP. We allow 144 byte messages (3*digest size)
to support MCT and in particular the "standard" MCT algorithm, and allow
1024 byte messages as the production supported message size used by the
entropy module itself.
Change-Id: I6e693a3fa23efba35d8a7d029ddf0b11036621c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/711740
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
When profiling CPU usage LiveKit on AArch64/x86 (AWS), the graphs show
CPU spikes that was repeating in a semi-periodic manner and spikes occur
when the GC(garbage collector) is active.
Our analysis found that the getempty function accounted for 10.54% of the
overhead, which was mainly caused by the work.empty.pop() function. And
listing pop shows that the majority of the time, with a 10.29% overhead,
is spent on atomic.Cas64((*uint64)(head), old, next).
This patch adds a backoff approach to reduce the high overhead of the
atomic operation primarily occurs when contention over a specific memory
address increases, typically with the rise in the number of threads.
Note that on paltforms other than arm64, the initial value of backoff is zero.
This patch rewrites the implementation of procyield() on arm64, which is an
Armv8.0-A compatible delay function using the counter-timer.
The garbage collector benchmark:
│ master │ opt │
│ sec/op │ sec/op vs base │
Garbage/benchmem-MB=64-160 3.782m ± 4% 2.264m ± 2% -40.12% (p=0.000 n=10)
│ user+sys-sec/op │ user+sys-sec/op vs base │
Garbage/benchmem-MB=64-160 433.5m ± 4% 255.4m ± 2% -41.08% (p=0.000 n=10)
Reference for backoff mechianism:
https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/multi-threaded-applications-arm
Change-Id: Ie8128a2243ceacbb82ab2a88941acbb8428bad94
Reviewed-on: https://go-review.googlesource.com/c/go/+/654895
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Both Eisel-Lemire and Ryu depend on a table of
truncated 128-bit mantissas of powers of 10,
and so will Dragonbox.
This CL:
- Moves the table to a separate file, so it doesn't look tied to Eisel-Lemire.
- Introduces a uint128 type in math.go for the table values,
since .Hi and .Lo are clearer than [1] and [0].
- Generates the table from a standalone generator pow10gen.go.
- Adds a new pow10 function in math.go to handle table access details.
- Factors a 64x128->192-bit multiply into umul192 in math.go.
- Moves multiplication by log₁₀ 2 and log₂ 10 into math.go.
- Introduces an import_test.go to avoid having to type differently
cased names in test code versus regular code.
- Introduces named constants for the floating-point size parameters.
Previously these were only in the floatInfo global variables.
- Changes the BenchmarkAppendUintVarlen subtest names
to be more useful.
Change-Id: I9826ee5f41c5c19be3b6a7c3c5f277ec6c23b39a
Reviewed-on: https://go-review.googlesource.com/c/go/+/712661
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Avoid calling Named.resolveUnderlying in the first place (there
is only one caller) if Named.underlying exists already.
In Named.resolveUnderlying remove initial atomic check because
of the check in Named.Underlying. Also, remove a 2nd atomic
check after acquiring the lock as it likely won't help much.
Change-Id: Ife87218fa2549d0903a10218f4dd7a70f85d6c7c
Reviewed-on: https://go-review.googlesource.com/c/go/+/713521
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: Mark Freeman <markfreeman@google.com>
When following a RHS chain, the (TypeName) Object path is only needed
when there is a cycle (i.e., an error), in which case we can be slow.
Rather than always compute the path, only compute it in the error case.
In the same vain, allocate the seen map lazily, only when needed.
This code could use a test (it doesn't seem to be encountered by our
test suite), but I haven't found a case to provoke the error yet.
Change-Id: Iff6313394442a251adc56580f746928ec13450fd
Reviewed-on: https://go-review.googlesource.com/c/go/+/712321
Auto-Submit: 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>
Reviewed-by: Robert Griesemer <gri@google.com>
Currently, "//go:embed" directives are read by bespoke parsers in
go/build and cmd/go/internal/modindex. Replace these bespoke parsers
with scanner.Scanner for finding these directives and
ast.ParseDirective for parsing them.
It's not clear why we had a bespoke parser just for finding
"//go:embed" directives in the first place. We have a bespoke parser
for reading imports in order to avoid having to read the entire source
file into memory, but if we're parsing embeds, we wind up reading the
entire source file into memory anyway. Using scanner.Scanner instead
eliminates some truly confusing code.
This also demonstrates that ast.ParseDirective as proposed in #68021
achieves useful API coverage.
Updates #68021.
Change-Id: Ieb68738121dcff605a6a704a8045ddd2ff35df35
Reviewed-on: https://go-review.googlesource.com/c/go/+/704836
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Austin Clements <austin@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
If new(expr) is used before Go 1.26, don't report version errors if there
are other problems with the expression.
While at it, implement multiple missing type checks for new(expr) and
add corresponding test cases that were missed in CL 704935 (tests for
no value expressions, generic types, untyped nil).
Reorganize/rename builtins0.go tests for new to match existing test case
patterns again.
Fixes#75986.
For #45624.
Change-Id: I39e5516d3f8d191cc390a4d8b9911c312bbb177c
Reviewed-on: https://go-review.googlesource.com/c/go/+/713241
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Mark Freeman <markfreeman@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
The existing func Rel's API documentation was presented in a rather
dense way without a lot of organization that oriented around topical
flow, so the documentation has been cleaned up to present the
function's behavior more clearly and concisely.
Fixes#75893
Change-Id: I6c8f6ef508250397be9d0127a15508e7335f18c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/712440
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Bypass: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
It appears that CL 695977 introduced a data race on Named.underlying.
This fixes that race by specifying a new namedState called underlying,
which, perhaps unsurprisingly, signals that Named.underlying is populated.
Unfortunately, the underlying namedState is independent of the complete
namedState (unsurprising since methods and the underlying type are not related).
Hence, they cannot be ordered and thus do not fit the current integer-based
state representation. To account for combinations of states, we introduce a
bit set representation for namedState instead. The namedState field is also
renamed to stateMask to reflect this new representation.
Methods that operate on the stateMask are adjusted and exposition is added
throughout.
Fixes#75963
Change-Id: Icfa188ea2fa7916804c06f80668e99176bf4e978
Reviewed-on: https://go-review.googlesource.com/c/go/+/712720
Auto-Submit: Mark Freeman <markfreeman@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Griesemer <gri@google.com>
All darwin syscall implementations can be consolidated into a
single syscalln function, as already happens on Windows.
This reduces duplication and allows moving some logic from
runtime to syscall.
Updates #699135
Cq-Include-Trybots: luci.golang.try:gotip-darwin-arm64-longtest,gotip-darwin-amd64-longtest,x_sys-gotip-darwin-arm64-longtest,x_sys-gotip-darwin-amd64-longtest
Change-Id: If5de80442b1d4a1123258401a3ae21695e7c8f6b
Reviewed-on: https://go-review.googlesource.com/c/go/+/699177
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
On darwin and openbsd, the autogenerated ptrace wrapper is
nosplit because it is called from forkAndExecInChild.
This makes it difficult to modify and improve the underlying
syscall mechanism, as ptrace is almost over the nosplit limit.
We better call ptrace directly using rawSyscall6 in
forkAndExecInChild so that we can lift the ptrace nosplit
restriction to.
Doing so also fixes a long-standing inconsistency:
forkAndExecInChild is documented to only allow rawSyscall, but
the ptrace wrapper is using non-raw syscalls.
Updates #64113
Change-Id: Ibbbb218511561c1a5cb5b6d288a691f9738b14a6
Reviewed-on: https://go-review.googlesource.com/c/go/+/708575
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The Windows implementation of RemoveAll supports deleting read-only
files only on file systems that supports POSIX semantics and on
newer Windows versions (Windows 10 RS5 and latter).
For all the other cases, the read-only bit was not clearer before
deleting read-only files, so they fail to delete.
Note that this case was supported prior to CL 75922, which landed on
Go 1.25.
Fixes#75922
Change-Id: Id6e6477f42e1952d08318ca3e4ab7c1648969f66
Reviewed-on: https://go-review.googlesource.com/c/go/+/713480
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
TestNISTECAllocations is flaky (~1% failure rate) on my local Windows
machine since CL 710058, which touched TestEntropyRace.
These tests are unrelated, but some allocations might be incorrectly
accounted to TestNISTECAllocations, affecting the end result due to
the low number of iterations done in that test.
Change-Id: I01323c2a45b12665e86d940467f4f91c2e66696b
Reviewed-on: https://go-review.googlesource.com/c/go/+/712620
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Auto-Submit: Quim Muntal <quimmuntal@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The lab confirmed the that entropy source doesn't have to be inside the
module boundary, although changing the entropy source of a module does
require recertification.
Move the v1.0.0 entropy source out of crypto/internal/fips140, to a
versioned path that lets us keep multiple versions (which would be used
by different modules) if we wish to.
Change-Id: I6a6a69647e9dfca1c375650a0869bdc001d65173
Reviewed-on: https://go-review.googlesource.com/c/go/+/710057
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
procyield will currently loop infinitely if passed 0 on several
platforms. This change sidesteps this bug by renaming procyield to
procyieldAsm, and adding a wrapper named procyield that checks for
cycles == 0. The benefit of this structure is that procyield called
with a constant cycle count of 0 will be inlined and constant folded
away, the expected behavior of a procyield of 0 cycles.
A follow-up change will fix the assembly to not have this footgun
anymore.
Change-Id: I7068abfeb961bc0fa475e216836f7c0e46b38373
Reviewed-on: https://go-review.googlesource.com/c/go/+/712663
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Currently when performing multiple nested traceAcquires, we re-read
trace.gen on subsequent reads. But this is invalid, since a generation
transition may happen in between a traceAcquire and a nested
traceAcquire. The first one will produce a traceLocker with a gen from
the previous generation, and the second will produce a traceLocker from
the next generation. (Note: generations cannot _complete_ advancement
under traceAcquire, but trace.gen can move forward.) The end result is
earlier events, from the nested traceAcquire, will write to a future
generation, and then previous events will write to a past generation.
This can break the trace.
(There are also a lot of comments left over talking about the
non-reentrancy of the tracer; we should look at those again.)
Change-Id: I08ac8cc86d41ab3e6061c5de58d657b6ad0d19d8
Reviewed-on: https://go-review.googlesource.com/c/go/+/708397
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
_Gdeadextra is almost the same as _Gdead but for goroutines attached to
extra Ms. The primary difference is that it can be transitioned into a
_Gscan status, unlike _Gdead. (Why not just use _Gdead? For safety,
mostly. There's exactly one case where we're going to want to transition
_Gdead to _Gscan|_Gdead, and it's for extra Ms. It's also a bit weird to
call this state dead when it can still have a syscalling P attached to
it.)
This status is used in a follow-up change that changes entersyscall and
exitsyscall.
Change-Id: I169a4c8617aa3dc329574b829203f56c86b58169
Reviewed-on: https://go-review.googlesource.com/c/go/+/646197
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This command modifies the call tree starting at `work.runInstall` to
inject a `State` parameter to every function that is currently using
the global `modload.LoaderState` variable. By explicilty passing a
`State` parameter, we can begin to eliminate the usage of the global
`modload.LoaderState`.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/work
rf 'inject modload.LoaderState runInstall'
cd ..
./rf-cleanup.zsh
Change-Id: I038d2c4870d67835c165852b223eaad3e2496202
Reviewed-on: https://go-review.googlesource.com/c/go/+/710304
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
This command modifies the call tree starting at `work.runBuild` and
`work.runInstall` to inject a `State` parameter to every function that
is currently using the global `modload.LoaderState` variable. By
explicilty passing a `State` parameter, we can begin to eliminate the
usage of the global `modload.LoaderState`.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/work
rf 'inject modload.LoaderState runBuild'
cd ..
./rf-cleanup.zsh
# cd work
# rf 'inject modload.LoaderState runInstall'
# cd ..
# ./rf-cleanup.zsh
Change-Id: I232452d877211d4ac72f42aa193b30dab9649481
Reviewed-on: https://go-review.googlesource.com/c/go/+/709990
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
This command modifies the call tree starting at `workcmd.runSync` to
inject a `State` parameter to every function that is currently using
the global `modload.LoaderState` variable. By explicilty passing a
`State` parameter, we can begin to eliminate the usage of the global
`modload.LoaderState`.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/workcmd
rf 'inject modload.LoaderState runSync'
cd ..
./rf-cleanup.zsh
Change-Id: Ib8a7b332b89762a7463ace53243cae6aa0ffcc2d
Reviewed-on: https://go-review.googlesource.com/c/go/+/709987
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
This command modifies the call tree starting at `modget.runGet` to
inject a `State` parameter to every function that is currently using
the global `modload.LoaderState` variable. By explicilty passing a
`State` parameter, we can begin to eliminate the usage of the global
`modload.LoaderState`.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/modget
rf 'inject modload.LoaderState runGet'
cd ..
./rf-cleanup.zsh
Change-Id: Icafc5cff07c49809f5c199feec9ed7795536976c
Reviewed-on: https://go-review.googlesource.com/c/go/+/709981
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
This command modifies the call tree starting at `modcmd.runVerify` to
inject a `State` parameter to every function that is currently using
the global `modload.LoaderState` variable. By explicilty passing a
`State` parameter, we can begin to eliminate the usage of the global
`modload.LoaderState`.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/modcmd
rf 'inject modload.LoaderState runVerify'
cd ..
./rf-cleanup.zsh
Change-Id: I5b3b4670a4e2d19375049e585035145d14248b40
Reviewed-on: https://go-review.googlesource.com/c/go/+/709985
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This command modifies the call tree starting at `modcmd.runVendor` to
inject a `State` parameter to every function that is currently using
the global `modload.LoaderState` variable. By explicilty passing a
`State` parameter, we can begin to eliminate the usage of the global
`modload.LoaderState`.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/modcmd
rf 'inject modload.LoaderState runVendor'
cd ..
./rf-cleanup.zsh
Change-Id: I0572e165d291e34d212ded9a420871688b7915ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/709984
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
This command modifies the call tree starting at `modcmd.runInit` to
inject a `State` parameter to every function that is currently using
the global `modload.LoaderState` variable. By explicilty passing a
`State` parameter, we can begin to eliminate the usage of the global
`modload.LoaderState`.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/modcmd
rf 'inject modload.LoaderState runInit'
cd ..
./rf-cleanup.zsh
Change-Id: Ie8bb8eb0edc2fabceafd9c41a2b11fe2a3532b73
Reviewed-on: https://go-review.googlesource.com/c/go/+/709983
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
This command modifies the call tree starting at `modcmd.runDownload`
to inject a `State` parameter to every function that is currently
using the global `modload.LoaderState` variable. By explicilty
passing a `State` parameter, we can begin to eliminate the usage of
the global `modload.LoaderState`.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/modcmd
rf 'inject modload.LoaderState runDownload'
cd ..
./rf-cleanup.zsh
Change-Id: I64cce3e631a2614b7fabe49205d9d41fc9ba24de
Reviewed-on: https://go-review.googlesource.com/c/go/+/710299
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This command modifies the call tree starting at `toolchain.Select` to
inject a `State` parameter to every function that is currently using
the global `modload.LoaderState` variable. By explicilty passing a
`State` parameter, we can begin to eliminate the usage of the global
`modload.LoaderState`.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/toolchain
rf '
inject modload.LoaderState Select
add select.go var moduleLoaderState *modload.State
ex {
import "cmd/go/internal/modload";
modload.LoaderState -> moduleLoaderState
}
add Select://+0 moduleLoaderState := modload.NewState()
rm select.go:/var moduleLoaderState \*modload.State/
'
cd ..
./rf-cleanup.zsh
Change-Id: I759439a47e2b1aaa01a0a800bc18596dd7ce4983
Reviewed-on: https://go-review.googlesource.com/c/go/+/709988
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This command modifies the call tree starting at `tool.runTool` to
inject a `State` parameter to every function that is currently using
the global `modload.LoaderState` variable. By explicilty passing a
`State` parameter, we can begin to eliminate the usage of the global
`modload.LoaderState`.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/tool
rf 'inject modload.LoaderState runTool'
cd ..
./rf-cleanup.zsh
Change-Id: Icd1ce189f7dad421eaa2bd43d53ceaf443c5405e
Reviewed-on: https://go-review.googlesource.com/c/go/+/710302
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
This command modifies the call tree starting at `test.runTest` to
inject a `State` parameter to every function that is currently using
the global `modload.LoaderState` variable. By explicilty passing a
`State` parameter, we can begin to eliminate the usage of the global
`modload.LoaderState`.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/test
rf 'inject modload.LoaderState runTest'
cd ..
./rf-cleanup.zsh
Change-Id: I6ee495c3beabdc5568ad338f4998a5927491db1a
Reviewed-on: https://go-review.googlesource.com/c/go/+/709986
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
This command modifies the call tree starting at `list.runList` to
inject a `State` parameter to every function that is currently using
the global `modload.LoaderState` variable. By explicilty passing a
`State` parameter, we can begin to eliminate the usage of the global
`modload.LoaderState`.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/list
rf 'inject modload.LoaderState runList'
cd ..
./rf-cleanup.zsh
Change-Id: I7274bc3dc6779bd8306fb79c158aa6f0473827a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/709979
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
This command modifies the call tree starting at `fmtcmd.runFmt` to
inject a `State` parameter to every function that is currently using
the global `modload.LoaderState` variable. By explicilty passing a
`State` parameter, we can begin to eliminate the usage of the global
`modload.LoaderState`.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/fmtcmd
rf '
inject modload.LoaderState runFmt
add fmt.go var moduleLoaderState *modload.State
ex {
import "cmd/go/internal/modload";
modload.LoaderState -> moduleLoaderState
}
add runFmt://+0 moduleLoaderState := modload.NewState()
rm fmt.go:/var moduleLoaderState \*modload.State/
'
cd ..
./rf-cleanup.zsh
Change-Id: Ib6692aba37a2cbc5b52d3bb705ec2b442afd26eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/709989
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This command modifies the call tree starting at `clean.runClean` to
inject a `State` parameter to every function that is currently using
the global `modload.LoaderState` variable. By explicilty passing a
`State` parameter, we can begin to eliminate the usage of the global
`modload.LoaderState`.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/clean
rf '
inject modload.LoaderState runClean
add clean.go var moduleLoaderState *modload.State
ex {
import "cmd/go/internal/modload";
modload.LoaderState -> moduleLoaderState
}
add runClean://+0 moduleLoaderState := modload.NewState()
rm clean.go:/var moduleLoaderState \*modload.State/
'
cd ..
./rf-cleanup.zsh
Change-Id: I2e30e44cfff7e533801dabd7159fa760ac6bb824
Reviewed-on: https://go-review.googlesource.com/c/go/+/710296
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This command modifies the call tree starting at `bug.runBug` to inject
a `State` parameter to every function that is currently using the
global `modload.LoaderState` variable. By explicilty passing a
`State` parameter, we can begin to eliminate the usage of the global
`modload.LoaderState`.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/bug
rf 'inject modload.LoaderState runBug'
cd ..
./rf-cleanup.zsh
Change-Id: Idf87733f586a8aae0779132f54a8d988e2551bae
Reviewed-on: https://go-review.googlesource.com/c/go/+/709982
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Explanation of the different types of linkname and guidance on the
preferred form. Written for myself, as I can never remember the guidance
and always rederive this from first principles.
Change-Id: If10cb8fc87782e25526ad597569e3c526ee33a1f
Reviewed-on: https://go-review.googlesource.com/c/go/+/609715
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Bypass: Michael Pratt <mpratt@google.com>
CL 706055 added AES support but chose to not generate feature checks for
composite features. Intel lists AES as AVXAES which gets manually mapped
to the composite feature AVX, AES. With the previous writeSIMDFeatures
code ignoring composite features, and there being no other references to
AES, we neglected to generate a feature check at all.
To resolve this, we instead split composite features into their
constituent parts and ensure that each feature has a check generated.
Currently AVXAES is the only composite feature.
Updates #73787
Change-Id: Ic8e9d8a3c9c0854fc717512c2ce092d81cb6b66c
Reviewed-on: https://go-review.googlesource.com/c/go/+/712880
Reviewed-by: Junyang Shao <shaojunyang@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
CL 706395 refactored the ppc64 library entry point and missed some
important aix-specific characteristics:
- _rt0_ppc64x_lib should account for the function descriptor when
getting the callback pointer.
- _rt0_ppc64x_lib should only call _cgo_sys_thread_create when
built as a c-archive.
Fixes#75801
Cq-Include-Trybots: luci.golang.try:gotip-linux-ppc64_power10
Change-Id: I343ca09d3b9688ffa585668a6c52f0ad519d6203
Reviewed-on: https://go-review.googlesource.com/c/go/+/710175
Reviewed-by: Paul Murphy <paumurph@redhat.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
A type definition or alias declaration consists of a type name (LHS)
which is bound to a type expression (RHS) by the declaration.
This CL consistently uses the fromRHS fields of Named and Alias types
to represent that RHS type expression, and sets Named.underlying and
Alias.actual only once those types have been computed.
Currently, Named types use Named.underlying for some of this
functionality, which makes the code difficult to understand. Operations
which used Named.underlying now use Named.fromRHS.
For example, in:
type A = B
type B = int
A.fromRHS is B (Alias) and B.fromRHS is int (Basic).
Meanwhile, in:
type A B
type B int
A.underlying is B (Named) and B.underlying is int (Basic) initially.
Note that despite A.underlying pointing to B, B is not the underlying
type of A (it is int). At some point during type checking, A walks
through the chain A.underlying -> B.underlying -> int and sets
A.underlying to int.
While this approach works, it introduces some problems:
1. Whether A.underlying refers to the underlying type (int) or not
(B) depends on when the field is accessed.
2. There is no convenient mechanism to check if the underlying type
of B has been deduced. One can check if B.underlying is a named
type, but since B.underlying is already B's underlying type (int),
it's still ambiguous.
Operations derived from Named.underlying share similar problems. For
example, Named.expandUnderlying() (which substitutes type arguments)
returns an instantiated named type whose Named.underlying also may or
may not refer to its underlying type.
With this change, Named.underlying is nil as long as it is unknown, and
non-nil and not a named type once it is known. Additional assertions are
added to enforce that:
1. Named.underlying is not set until Named has been resolved.
2. Named is not resolved until Named.fromRHS is populated, unless it
is given explicit permission. This permission is briefly given
while type-checking declarations of named types to account for
cycles of alias types represented as TypeNames. It is also given to
named types created through NewNamed for backward compatibility.
This permission is revoked when SetUnderlying is called.
Accessors of Named.underlying are responsible for first resolving
the named type, unless they are in a context where they know the
type to already be resolved.
This change also exposed a bug in validType wherein the underlying
type for struct types containing invalid types did not have their
underlying type set to invalid (see #75194). This bug was exploited by a
test in x/tools, which has been disabled for Go 1.26 (via CL 700395).
Other minor adjustments are made for instantiated and loaded types.
Instantiated types have no RHS as they are not declared, and loaded
types set their RHS to the underlying from export data directly.
Minor simplifications are also made throughout.
Fixes#75194
Change-Id: I72644d7329c996eb1e67514063fe51c3ae06c38d
Reviewed-on: https://go-review.googlesource.com/c/go/+/695977
Auto-Submit: Mark Freeman <markfreeman@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Griesemer <gri@google.com>
CL 709335 changed ResponseWriter.Write to return an error
when trying to write to a response with a status code which
doesn't permit a body, such as 304.
Continue to return an error, but still record the write in
ResponseWriter.Body. This maintains the documented property that
"the data in buf is written to rw.Body".
For #75471
Change-Id: I69139797559fe09d6580c5d25b4458f04263c60e
Reviewed-on: https://go-review.googlesource.com/c/go/+/711940
Reviewed-by: Sean Liao <sean@liao.dev>
TryBot-Bypass: Damien Neil <dneil@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
Reviewed-by: Nicholas Husin <nsh@golang.org>
Reviewed-by: Nicholas Husin <husin@google.com>
If two slices start out with the same length and decrease in length by
the same amount on each round of the loop (or in the if block), then
we think their length are always equal.
For example:
if len(a) != len(b) {
return
}
for len(a) >= 4 {
a = a[4:]
b = b[4:] // proved here, omit boundary check
}
if len(a) == len(b) { // proved here
//...
}
Or, change 'for' to 'if':
if len(a) != len(b) {
return
}
if len(a) >= 4 {
a = a[4:]
b = b[4:]
}
if len(a) == len(b) { // proved here
//...
}
Fixes#75144
Change-Id: I4e5902a02b5cf8fdc122715a7dbd2fb5e9a8f5dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/699155
Reviewed-by: Michael Pratt <mpratt@google.com>
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>
Auto-Submit: Keith Randall <khr@golang.org>
I think the original depth-1 argument to allocDeep was correct.
Reverted that, and also the change to maxSkip in mprof.go, which was
also incorrect. I think before we were usually passing accidentally in
the loop over matched stacks when we really should usually have been
passing in the previous loop.
Change-Id: I6a6a696463e2baf045b66f418d7afbfcb49258e4
Reviewed-on: https://go-review.googlesource.com/c/go/+/712100
Reviewed-by: Michael Matloob <matloob@google.com>
TryBot-Bypass: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
This command modifies the call tree starting at `run.runRun` to inject
a `State` parameter to every function that is currently using the
global `modload.LoaderState` variable. By explicilty passing a
`State` parameter, we can begin to eliminate the usage of the global
`modload.LoaderState`.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/run
rf 'inject modload.LoaderState runRun'
cd ..
./rf-cleanup.zsh
Change-Id: I337323c087ed4e43af28973fad27152791eefbc2
Reviewed-on: https://go-review.googlesource.com/c/go/+/698063
TryBot-Bypass: Ian Alexander <jitsu@google.com>
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
This is a large series of sed commands to cleanup after successful use
of the `rf inject` command. This script will be used to refactor the
codebase to eliminate global state within the module loader. Once
that effort is complete, this script will be removed.
This commit is part of the overall effort to eliminate global
modloader state.
Change-Id: If04926b5ca5b7230f91ac98fe4a82c20ef5f73ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/709978
Reviewed-by: Michael Matloob <matloob@golang.org>
TryBot-Bypass: Ian Alexander <jitsu@google.com>
Commit-Queue: Ian Alexander <jitsu@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
The new conversions can be activated (or bisected) with
-gcflags=all=-d=converthash=PATTERN
where PATTERN is either a hash string or n, qn, y, qy for
no, quietly no, yes, quietly yes.
This CL makes the default pattern be "qn" instead of the
default-default which is an efficient encoding of "qy".
Updates #75834
Change-Id: I88a9fd7880bc999132420c8d0a22a8fdc1e95a2a
Reviewed-on: https://go-review.googlesource.com/c/go/+/711845
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Bypass: David Chase <drchase@google.com>
This reverts commit b9f3accdcf.
Reason for revert: we need to do this more carefully, at minimum gated by a module version
(This should follow the WASM FP conversion revert)
Change-Id: Ib98ce7d243348f69c9944db8537397b225c2cc33
Reviewed-on: https://go-review.googlesource.com/c/go/+/711841
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Bypass: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@google.com>
The jsontext package represents the location of JSON errors
using a JSON Pointer (RFC 6901). This uses the JSON type system.
Unfortunately the v1 json.UnmarshalTypeError assumes a Go struct-based
mechanism for reporting the location of errors
(and has historically never been implemented correctly since
it was a weird mix of both JSON and Go namespaces; see #43126).
Trying to map a JSON Pointer into UnmarshalTypeError.{Struct,Field}
is difficult to get right without teaching jsontext
about the Go type system.
To reduce the probability of misleading errors,
check whether the last token looks like a JSON array index
and if so, elide the phrase "into Go struct field".
Fixes#74801
Change-Id: Id2088ffb9c339a9238ed38c90223d86a89422842
Reviewed-on: https://go-review.googlesource.com/c/go/+/710676
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Originally, DefaultOptionsV1 and DefaultOptionsV2 represented
the full set of all options with specific ones set to true or false.
However, there are certain options such as WithIndent or WithMarshalers
that are neither v1 or v2 specific.
At some point we removed whitespace related options from the set:
https://github.com/go-json-experiment/json/pull/26
This avoids DefaultOptionsV1 or DefaultOptionsV2 from affecting
any previously set whitespace. However, why are whitespace options
special and thus excluded from the set? What about Marshalers?
As a more principaled way to address this, we restrict
DefaultOptionsV1 and DefaultOptionsV2 to only be the options
where the default setting changes between v1 and v2.
All other options are unpopulated.
This avoids a panic with GetOption(DefaultOptionsV2, WithMarshalers)
since DefaultOptionsV2 previously had the presence bit for
Marshalers set to true, but had no actual value.
Now, the presence bit is set to false, so the value is not consulted.
Fixes#75149
Change-Id: I30b45abd35404578b4135cc3bad1a1a2993cb0cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/710878
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
Issue #49439 was about a deadlock during type inference inside
a type parameter list of a recursive constraint. As a remedy
we disallowed recursive type parameter lists.
In the meantime we have removed support for type inference for
type arguments to generic types; the Go 1.18 generic release
didn't support it.
As a consequence, the fix for #49439, CL 361922, is probably
not needed anymore: cycles through type parameter lists are ok.
Fixes#68162.
For #49439.
Change-Id: Ie9deb3274914d428e8e45071cee5e68abf8afe9c
Reviewed-on: https://go-review.googlesource.com/c/go/+/711420
Commit-Queue: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Mark Freeman <markfreeman@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Leave those constant foldings for runtime, similar to how we do it
for NaN generation.
These are the only instances I could find in cmd/compile/..., using
objdump -d ../pkg/tool/darwin_arm64/compile| egrep "(fcvtz|>:)" | grep -B1 fcvt
(There are instances in other places, like runtime and reflect, but I don't
think those places would affect compiler output.)
Change-Id: I4113fe4570115e4765825cf442cb1fde97cf2f27
Reviewed-on: https://go-review.googlesource.com/c/go/+/711281
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@google.com>
The fully streaming UnmarshalJSONFrom method and UnmarshalFromFunc
introduce an edge case where they can encounter EOF in the stream,
where it should be reported upstream as EOF rather than
ErrUnexpectedEOF or be wrapped within a SemanticError.
This is not possible with other unmarshal methods since the
"json" package would read the appropriate JSON value
before calling the custom method or function.
To avoid custom unmarshal methods from encountering EOF,
check whether the stream is already at EOF for top-level values
before calling the custom method.
Also, when wrapping EOF within a SemanticError, convert it
to ErrUnexpectedEOF to better indicate that this is unexpected.
Fixes#75802
Change-Id: I001396734b7e95b5337f77b71326284974ee730a
Reviewed-on: https://go-review.googlesource.com/c/go/+/710877
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
In CL 709854 we enabled strict validation for a number of properties of
domain names (and their constraints). This caused significant breakage,
since we didn't previously disallow the creation of certificates which
contained these malformed domains.
Rollback a number of the properties we enforced, making domainNameValid
only enforce the same properties that domainToReverseLabels does. Since
this also undoes some of the DoS protections our initial fix enabled,
this change also adds caching of constraints in isValid (which perhaps
is the fix we should've initially chosen).
Updates #75835Fixes#75828
Change-Id: Ie6ca6b4f30e9b8a143692b64757f7bbf4671ed0e
Reviewed-on: https://go-review.googlesource.com/c/go/+/710735
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
The number-of-blocks check was introduced when fixing a Darwin-
specific bug. On Darwin, the file allocation syscall is a bit
tricky. On Linux and BSDs, it is more straightforward and unlikely
to go wrong.
The test itself, on the other hand, is less reliable on Linux (and
perhaps BSDs), as it is considered less portable and is an
implementation detail of the file system.
Given these two reasons, only check it on Darwin.
Fixes#75795.
Change-Id: I3da891fd60a141c3eca5d0f5ec20c2cad65b8862
Reviewed-on: https://go-review.googlesource.com/c/go/+/711095
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
The legacy parsing of quoted numbers in v1 was according to
the Go grammar for a number, rather than
the JSON grammar for a number.
The former is a superset of the latter.
This is a historical mistake, but usages exist that depend on it.
We already have branches for StringifyWithLegacySemantics
to handle quoted nulls, so we can expand it to handle this.
Fixes#75619
Change-Id: Ic07802539b7cbe0e1f53bd0f7e9bb344a8447203
Reviewed-on: https://go-review.googlesource.com/c/go/+/709615
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Some of the programs in testdata/testgoroutineleakprofile have data
races because they were taken from a corpus that showcases general Go
concurrency bugs, not just leaked goroutines.
This causes some flakiness as tests might fail due to, for example, a
concurrent map access, even outside of race mode.
Let's just call data races a failure and fix them in the examples. As
far as I can tell, there are only two that show up consistently.
Fixes#75732.
Change-Id: I160b3a1cdce4c2de3f2320b68b4083292e02b557
Reviewed-on: https://go-review.googlesource.com/c/go/+/710756
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This change unifies the fix and vet subcommands; they use the
same run function, action graph, and external tool (-vettool
for go vet and -fixtool for go fix). go fix runs the tool
with the -fix flag, whereas although go vet also supports
-fix, it is not the default. The two tools have different
(overlapping) suites of analyzers.
The high-level parts are fully parameterized over the
vet/fix distinction; the lower-level parts (the action
graph) continue to use only the "vet" terminology.
The cmd/{vet,fix} executable is referred to as the "tool".
The tool is generally invoked in -json mode, regardless
of whether -json was requested, so that the tool produces
a cacheable JSON blob on stdout. When the go user did not
request -json, this blob is parsed and printed to stderr
by logic in the go vet command. (Formerly the tool would
print diagnostics to stderr, but this interacts poorly
with the build cache.)
go fix's legacy -fix=fixer,... flag is now a no-op that
prints a warning that the flag is obsolete.
The unitchecker's -c=n flag (to display n lines of context
around each diagnostic) is reimplemented in go vet based
on the JSON information, to avoid reliance on the stderr
output of the tool.
cmd/fix is added to dist's prebuilt set of tools since
go fix cannot build it dynamically (though ideally
it would).
Updates #71859
For #75432
Change-Id: I0a84746720b59d05d662ed57826747c5598dca44
Reviewed-on: https://go-review.googlesource.com/c/go/+/700795
Reviewed-by: Michael Matloob <matloob@google.com>
Auto-Submit: Alan Donovan <adonovan@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
TryBot-Bypass: Alan Donovan <adonovan@google.com>
This test verifies whether or not we use the chunked encoding when
sending a request with a body like io.NopCloser(strings.NewReader("")).
This depends on whether the transport can read a single byte from the
request body within 200ms, which is flaky on very slow builders.
Use fake time to avoid flakes.
Fixes#52575
Change-Id: Ie11a58ac6bc18d43af1423827887e804242dee30
Reviewed-on: https://go-review.googlesource.com/c/go/+/710737
Auto-Submit: Nicholas Husin <nsh@golang.org>
Reviewed-by: Nicholas Husin <husin@google.com>
Reviewed-by: Nicholas Husin <nsh@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The ICE seen on loong64 while compiling the `(*gcWork).tryStealSpan`
function was due to an `LoweredAtomicAnd32` op (inlined from the
`(pMask).clear` implementation) being incorrectly assigned an output
register while it shouldn't have. Because the op is of mem type, it has
needRegister() == false; hence in the shuffle phase of regalloc, its
bogus output register has no associated `orig` value recorded. The bug
was introduced in CL 482756, but only recently exposed by CL 696035.
Since the old-style atomic ops need no return value (and is even
documented so besides the loong64 ssa op definition), just fix the
register info for both.
While at it, add a note in the ssa op definition file about the
architectural necessity of resultNotInArgs for loong64 atomic ops,
because the practice is not seen in several other arches I have
checked.
Updates #75776
Change-Id: I087f51b8a2825d7b00fc3965b0afcc8b02cad277
Reviewed-on: https://go-review.googlesource.com/c/go/+/710475
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This change creates calls to size-specialized malloc functions instead
of calls to newObject when we know the size of the allocation at
compilation time. Most of it is a matter of calling the newObject
function (which will create calls to the size-specialized functions)
rather then the newObjectNonSpecialized function (which won't). In the
newHeapaddr, small, non-pointer case, we'll create a non specialized
newObject and transform that into the appropriate size-specialized
function when we produce the mallocgc in flushPendingHeapAllocations.
We have to update some of the rewrites in generic.rules to also apply to
the size-specialized functions when they apply to newObject.
The messiest thing is we have to adjust the offset we use to save the
memory profiler stack, because the depth of the call to profilealloc is
two frames fewer in the size-specialized malloc functions compared to
when newObject calls mallocgc. A bunch of tests have been adjusted to
account for that.
Change-Id: I6a6a6964c9037fb6719e392c4a498ed700b617d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/707856
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
This test has an arbitrary 5 second timeout, and this seems to fire on
Darwin with mayMoreStackMove enabled (which is slow). Just rely on the
regular test timeout instead of this arbitrary shorter timeout to
eliminate the possibility that the test is just too slow.
On my Linux VM, I can get this test to take up to 2 seconds with
mayMoreStackMove set on all the same packages dist does, so this failure
mode is actually plausible.
Fixes#75742.
Change-Id: Iebcc859cab26e9205b57b869690162a9a424dfce
Reviewed-on: https://go-review.googlesource.com/c/go/+/710618
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
The security fix we applied in CL709857 was overly broad. It applied
rules from RFC 2732, which disallowed IPv4-mapped IPv6 addresses, but
these were later allowed in RFC 3986, which is the canonical URI syntax
RFC.
Revert the portion of CL709857 which restricted IPv4-mapped addresses,
and update the related tests.
Fixes#75815
Change-Id: I3192f2275ad5c386f5c15006a6716bdb5282919d
Reviewed-on: https://go-review.googlesource.com/c/go/+/710375
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ethan Lee <ethanalee@google.com>
Auto-Submit: Roland Shoemaker <roland@golang.org>
This commit refactors usage of the global variable `workFilePath` to
the global LoaderState field of the same name.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/modload
rf 'ex { workFilePath -> LoaderState.workFilePath }'
rf 'add State.requirements \
// Set to the path to the go.work file, or "" if workspace mode is\
// disabled'
rf 'rm workFilePath'
Change-Id: I53cdbc3cc619914421513db74a74a04ab10b3e33
Reviewed-on: https://go-review.googlesource.com/c/go/+/698062
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This commit refactors usage of the global variable `requirements` to
the global LoaderState field of the same name.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/modload
rf 'ex { requirements -> LoaderState.requirements }'
rf 'add State.MainModules \
// requirements is the requirement graph for the main module.\
//\
// It is always non-nil if the main module'\\\''s go.mod file has been\
// loaded.\
//\
// This variable should only be read from the loadModFile\
// function, and should only be written in the loadModFile and\
// commitRequirements functions. All other functions that need or\
// produce a *Requirements should accept and/or return an explicit\
// parameter.'
rf 'rm requirements'
Change-Id: I9d7d1d301a9e89f9214ce632fa5b656dd2940f39
Reviewed-on: https://go-review.googlesource.com/c/go/+/698061
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
analysis for
- is this block only reached through feature checks?
- does the function signature imply AVX-something?
- is there an instruction in this block which implies AVX-something?
and keep track of which features those are. Features =
AVX, AVX2, AVX512, etc.
Has a test.
Change-Id: I0b6f2e87d01ec587818db11cf71fac1e4d500650
Reviewed-on: https://go-review.googlesource.com/c/go/+/706337
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
This commit refactors usage of the global variable `MainModules` to
the global LoaderState variable of the same name.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/modload
rf 'mv State.mainModules State.MainModules'
rf 'ex { MainModules -> LoaderState.MainModules }'
for dir in load modcmd modget test tool workcmd ; do
cd ../${dir}
rf 'ex {
import "cmd/go/internal/modload"
modload.MainModules -> modload.LoaderState.MainModules
}'
done
cd ../modload
rf 'rm MainModules'
Change-Id: I15644c84190717d62ae953747a288ec6495ef168
Reviewed-on: https://go-review.googlesource.com/c/go/+/698060
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Sparse files in tar archives contain only the non-zero components
of the file. There are several different encodings for sparse
files. When reading GNU tar pax 1.0 sparse files, archive/tar did
not set a limit on the size of the sparse region data. A malicious
archive containing a large number of sparse blocks could cause
archive/tar to read an unbounded amount of data from the archive
into memory.
Since a malicious input can be highly compressable, a small
compressed input could cause very large allocations.
Cap the size of the sparse block data to the same limit used
for PAX headers (1 MiB).
Thanks to Harshit Gupta (Mr HAX) (https://www.linkedin.com/in/iam-harshit-gupta/)
for reporting this issue.
Fixes CVE-2025-58183
Fixes#75677
Change-Id: I70b907b584a7b8676df8a149a1db728ae681a770
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/2800
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Nicholas Husin <husin@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/709861
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Bypass: Michael Pratt <mpratt@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
RFC 5322 domain-literal parsing built the dtext value one character
at a time with string concatenation, resulting in excessive
resource consumption when parsing very large domain-literal values.
Replace with a subslice.
Benchmark not included in this CL because it's too narrow to be
of general ongoing use, but for:
ParseAddress("alice@[" + strings.Repeat("a", 0x40000) + "]")
goos: darwin
goarch: arm64
pkg: net/mail
cpu: Apple M4 Pro
│ /tmp/bench.0 │ /tmp/bench.1 │
│ sec/op │ sec/op vs base │
ParseAddress-14 1987.732m ± 9% 1.524m ± 5% -99.92% (p=0.000 n=10)
│ /tmp/bench.0 │ /tmp/bench.1 │
│ B/op │ B/op vs base │
ParseAddress-14 33692.767Mi ± 0% 1.282Mi ± 0% -100.00% (p=0.000 n=10)
│ /tmp/bench.0 │ /tmp/bench.1 │
│ allocs/op │ allocs/op vs base │
ParseAddress-14 263711.00 ± 0% 17.00 ± 0% -99.99% (p=0.000 n=10)
Thanks to Philippe Antoine (Catena cyber) for reporting this issue.
Fixes CVE-2025-61725
Fixes#75680
Change-Id: Id971c2d5b59882bb476e22fceb7e01ec08234bb7
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/2840
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Nicholas Husin <husin@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/709860
Reviewed-by: Carlos Amedee <carlos@golang.org>
TryBot-Bypass: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reader.ReadResponse constructed a response string from repeated
string concatenation, permitting a malicious sender to cause excessive
memory allocation and CPU consumption by sending a response consisting
of many short lines.
Use a strings.Builder to construct the string instead.
Thanks to Jakub Ciolek for reporting this issue.
Fixes CVE-2025-61724
Fixes#75716
Change-Id: I1a98ce85a21b830cb25799f9ac9333a67400d736
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/2940
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Nicholas Husin <husin@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/709859
TryBot-Bypass: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Because Decode scanned the input first for the first BEGIN line, and
then the first END line, the complexity of Decode is quadratic. If the
input contained a large number of BEGINs and then a single END right at
the end of the input, we would find the first BEGIN, and then scan the
entire input for the END, and fail to parse the block, so move onto the
next BEGIN, scan the entire input for the END, etc.
Instead, look for the first END in the input, and then the first BEGIN
that precedes the found END. We then process the bytes between the BEGIN
and END, and move onto the bytes after the END for further processing.
This gives us linear complexity.
Fixes CVE-2025-61723
Fixes#75676
Change-Id: I813c4f63e78bca4054226c53e13865c781564ccf
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/2921
Reviewed-by: Nicholas Husin <husin@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/709858
TryBot-Bypass: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
- Previously, url.Parse did not enforce validation of hostnames within
square brackets.
- RFC 3986 stipulates that only IPv6 hostnames can be embedded within
square brackets in a URL.
- Now, the parsing logic should strictly enforce that only IPv6
hostnames can be resolved when in square brackets. IPv4, IPv4-mapped
addresses and other input will be rejected.
- Update url_test to add test cases that cover the above scenarios.
Thanks to Enze Wang, Jingcheng Yang and Zehui Miao of Tsinghua
University for reporting this issue.
Fixes CVE-2025-47912
Fixes#75678
Change-Id: Iaa41432bf0ee86de95a39a03adae5729e4deb46c
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/2680
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/709857
TryBot-Bypass: Michael Pratt <mpratt@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Auto-Submit: Michael Pratt <mpratt@google.com>
Span queues must be empty when destroying a P since we are outside of
the mark phase. But we don't actually free them, so they simply sit
around using memory. More importantly, they are still in
work.spanSPMCs.all, so freeDeadSpanSPMCs must continue traversing past
them until the end of time.
Prior to CL 709575, keeping them in work.spanSPMCs.all allowed programs
with low GOMAXPROCS to continue triggering the bug if they ever had high
GOMAXPROCS in the past.
The spanSPMCs list is singly-linked, so it is not efficient to remove a
random element from the middle. Instead, we simply mark it as dead to
all freeDeadSpanSPMCs to free it when it scans the full list.
For #75771.
Change-Id: I6a6a636cfa22a4bdef0c273d083c91553e923fe5
Reviewed-on: https://go-review.googlesource.com/c/go/+/709656
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Within parseSequenceOf, reflect.MakeSlice is being used to pre-allocate
a slice that is needed in order to fully validate the given DER payload.
The size of the slice allocated are also multiple times larger than the
input DER:
- When using asn1.Unmarshal directly, the allocated slice is ~28x
larger.
- When passing in DER using x509.ParseCertificateRequest, the allocated
slice is ~48x larger.
- When passing in DER using ocsp.ParseResponse, the allocated slice is
~137x larger.
As a result, a malicious actor can craft a big empty DER payload,
resulting in an unnecessary large allocation of memories. This can be a
way to cause memory exhaustion.
To prevent this, we now use SliceCapWithSize within internal/saferio to
enforce a memory allocation cap.
Thanks to Jakub Ciolek for reporting this issue.
For #75671
Fixes CVE-2025-58185
Change-Id: Id50e76187eda43f594be75e516b9ca1d2ae6f428
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/2700
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/709856
Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
When handling HTTP headers, net/http does not currently limit the number
of cookies that can be parsed. The only limitation that exists is for
the size of the entire HTTP header, which is controlled by
MaxHeaderBytes (defaults to 1 MB).
Unfortunately, this allows a malicious actor to send HTTP headers which
contain a massive amount of small cookies, such that as much cookies as
possible can be fitted within the MaxHeaderBytes limitation. Internally,
this causes us to allocate a massive number of Cookie struct.
For example, a 1 MB HTTP header with cookies that repeats "a=;" will
cause an allocation of ~66 MB in the heap. This can serve as a way for
malicious actors to induce memory exhaustion.
To fix this, we will now limit the number of cookies we are willing to
parse to 3000 by default. This behavior can be changed by setting a new
GODEBUG option: GODEBUG=httpcookiemaxnum. httpcookiemaxnum can be set to
allow a higher or lower cookie limit. Setting it to 0 will also allow an
infinite number of cookies to be parsed.
Thanks to jub0bs for reporting this issue.
For #75672
Fixes CVE-2025-58186
Change-Id: Ied58b3bc8acf5d11c880f881f36ecbf1d5d52622
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/2720
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/709855
Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Don't use domainToReverseLabels to check if domain names are valid,
since it is not particularly performant, and can contribute to DoS
vectors. Instead just iterate over the name and enforce the properties
we care about.
This also enforces that DNS names, both in SANs and name constraints,
are valid. We previously allowed invalid SANs, because some
intermediates had these weird names (see #23995), but there are
currently no trusted intermediates that have this property, and since we
target the web PKI, supporting this particular case is not a high
priority.
Thank you to Jakub Ciolek for reporting this issue.
Fixes CVE-2025-58187
Fixes#75681
Change-Id: I6ebce847dcbe5fc63ef2f9a74f53f11c4c56d3d1
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/2820
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/709854
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This commit refactors usage of the global variable `modRoots` to the
global LoaderState field of the same name.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/modload
rf 'ex { modRoots -> LoaderState.modRoots }'
rf 'add State.RootMode \
// These are primarily used to initialize the MainModules, and should\
// be eventually superseded by them but are still used in cases where\
// the module roots are required but MainModules has not been\
// initialized yet. Set to the modRoots of the main modules.\
// modRoots != nil implies len(modRoots) > 0'
rf 'rm modRoots'
Change-Id: Ie9e1f3d468cfceee25efefaf945b10492318b079
Reviewed-on: https://go-review.googlesource.com/c/go/+/698059
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The sbrk mem.go implementation doesn't enforce being called on the
systemstack, but it can call back into itself if there's a stack growth.
Because the sbrk implementation requires acquiring memlock, it can
self-deadlock.
For the most part the mem.go API is called on the system stack, but
there are cases where we call sysAlloc on the regular Go stack. This is
fine in general, except on sbrk platforms because of the aforementioned
deadlock.
This change, rather than adding a new invariant to mem.go, switches to
the systemstack in the mem.go API implementation for sbrk platforms.
Change-Id: Ie0f0ea80a8d7578cdeabc8252107e64a5e633856
Reviewed-on: https://go-review.googlesource.com/c/go/+/709775
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This commit refactors usage of the global variable `RootMode` to the
global LoaderState variable of the same name.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/modload
rf 'mv State.rootMode State.RootMode'
for dir in load modcmd run tool toolchain work ; do
cd ../${dir}
rf 'ex {
import "cmd/go/internal/modload";
modload.RootMode -> modload.LoaderState.RootMode
}'
done
cd ../modload
rf 'ex { RootMode -> LoaderState.RootMode }'
rf 'add State.ForceUseModules \
// RootMode determines whether a module root is needed.'
rf 'rm RootMode'
Change-Id: Ib5e513ee570dfc3b01cc974fe32944e5e391fd82
Reviewed-on: https://go-review.googlesource.com/c/go/+/698058
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
This commit refactors usage of the global variable `ForceUseModules`
to the global LoaderState field of the same name.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/modload
rf 'mv State.forceUseModules State.ForceUseModules'
rf 'ex { ForceUseModules -> LoaderState.ForceUseModules }'
for dir in load modcmd modget run toolchain work workcmd ; do
cd ../${dir}
rf 'ex {
import "cmd/go/internal/modload";
modload.ForceUseModules -> modload.LoaderState.ForceUseModules
}'
done
cd ../modload
rf 'add State.initialized \
// ForceUseModules may be set to force modules to be enabled when\
// GO111MODULE=auto or to report an error when GO111MODULE=off.'
rf 'rm ForceUseModules'
Change-Id: Ibdecfd273ff672516c9eb86279e5dfc6cdecb2ea
Reviewed-on: https://go-review.googlesource.com/c/go/+/698057
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
For unformatted strings, it comes up periodically that there are
more allocations using fmt.Errorf("x") compared to errors.New("x").
People cite it as a reason to switch code using fmt.Errorf to
use errors.New instead.
Three examples from the last few weeks essentially made
this suggestion: #75235, CL 708496, and CL 708618. Prior to that,
it is periodically suggested as a vet check (e.g., proposals #17173
and #52696) or in various CLs to change the standard library
(e.g., CL 403938 and CL 588776).
On the other hand, I believe the position of the core Go team
is that it is usually not worthwhile to make such a change. For example,
in #52696, Russ wrote:
Thanks for raising the issue, but please don't do this. Using
fmt.Errorf("foo") is completely fine, especially in a program where
all the errors are constructed with fmt.Errorf. Having to
mentally switch between two functions based on the argument
is unnecessary noise.
This CL attempts to mostly take performance out of the discussion.
We drop from 2 allocations to 0 allocations for a non-escaping error,
and drop from 2 allocations to 1 allocation for an escaping error:
_ = fmt.Errorf("foo") // non-escaping error
sink = fmt.Errorf("foo") // escaping error
This now matches the allocations for errors.New("foo") in both cases.
The CPU cost difference is greatly reduced, though there is still
a small ~4ns difference measurable in these microbenchmarks. Previously,
it was ~64ns vs. ~21ns for fmt.Errorf("x") vs. errors.New("x")
for escaping errors, whereas with this CL it is now ~25ns vs. ~21ns.
When fmt.Errorf("foo") executes with this CL, there are essentially
three optimizations now, in rough order of usefulness:
(1) we always avoid an allocation inside the doPrintf machinery;
(2) if the error does not otherwise escape, we can stack allocate
the errors.errorString struct by virtue of mid-stack inlining
of fmt.Errorf and the resulting inlining of errors.New, which
also can be more effective via PGO;
(3) stringslite.IndexByte is a tiny bit faster than going through the
for loops looking for '%' inside doPrintf.
See https://blog.filippo.io/efficient-go-apis-with-the-inliner/ for
background on avoiding heap allocations via mid-stack inlining.
The common case here is likely that the string format argument is a
constant when there are no other arguments.
However, one concern could be that by not allocating a copy, we could
now keep a string argument alive longer with this change, which could
be a pessimization if for example that string argument is a
slice of a much bigger string:
s := bigString[m:n]
longLivedErr := fmt.Errorf(s)
Aside from that being perhaps unusual code, vet will complain about
s there as a "non-constant format string in call to fmt.Errorf", so that
particular example seems unlikely to occur frequently in practice.
The main benchmark results are below. "old" is prior to this CL, "new"
is with this CL. The non-escaping case is "local", the escaping case is
"sink". In practice, I suspect errors escape the majority of the time.
Benchmark code at https://go.dev/play/p/rlRSO1ehx8O
goos: linux
goarch: amd64
pkg: fmt
cpu: AMD EPYC 7B13
│ old-7bd6fac4.txt │ new-dcd2a72f0.txt │
│ sec/op │ sec/op vs base │
Errorf/no-args/local-16 63.76n ± 1% 4.874n ± 0% -92.36% (n=120)
Errorf/no-args/sink-16 64.25n ± 1% 25.81n ± 0% -59.83% (n=120)
Errorf/int-arg/local-16 90.86n ± 1% 90.97n ± 1% ~ (p=0.713 n=120)
Errorf/int-arg/sink-16 91.81n ± 1% 91.10n ± 1% -0.76% (p=0.036 n=120)
geomean 76.46n 31.95n -58.20%
│ old-7bd6fac4.txt │ new-dcd2a72f0.txt │
│ B/op │ B/op vs base │
Errorf/no-args/local-16 19.00 ± 0% 0.00 ± 0% -100.00% (n=120)
Errorf/no-args/sink-16 19.00 ± 0% 16.00 ± 0% -15.79% (n=120)
Errorf/int-arg/local-16 24.00 ± 0% 24.00 ± 0% ~ (p=1.000 n=120) ¹
Errorf/int-arg/sink-16 24.00 ± 0% 24.00 ± 0% ~ (p=1.000 n=120) ¹
geomean 21.35 ? ² ³
¹ all samples are equal
│ old-7bd6fac4.txt │ new-dcd2a72f0.txt │
│ allocs/op │ allocs/op vs base │
Errorf/no-args/local-16 2.000 ± 0% 0.000 ± 0% -100.00% (n=120)
Errorf/no-args/sink-16 2.000 ± 0% 1.000 ± 0% -50.00% (n=120)
Errorf/int-arg/local-16 2.000 ± 0% 2.000 ± 0% ~ (p=1.000 n=120) ¹
Errorf/int-arg/sink-16 2.000 ± 0% 2.000 ± 0% ~ (p=1.000 n=120) ¹
geomean 2.000 ? ² ³
¹ all samples are equal
Change-Id: Ib27c52933bec5c2236624c577fbb1741052e792f
Reviewed-on: https://go-review.googlesource.com/c/go/+/708836
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Commit-Queue: t hepudds <thepudds1460@gmail.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
This commit refactors usage of the global variable `initialized` to
the global LoaderState field of the same name.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/modload
rf 'ex { initialized -> LoaderState.initialized }'
rf 'rm initialized'
Change-Id: I97e35bab00f4c22661670b01b69425fc25efe6df
Reviewed-on: https://go-review.googlesource.com/c/go/+/698056
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
The page allocator's scavenge index has sysGrow called on it twice,
once in pageAlloc.grow, and once in pageAlloc.sysGrow on 64-bit
platforms. Calling it twice is OK since sysGrow is idempotent,
but it's also wasteful. This change removes the call
in pageAlloc.sysGrow.
Change-Id: I5b955b6e2beed5c2b8305ab82b76718ea305792c
Reviewed-on: https://go-review.googlesource.com/c/go/+/707735
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Instead of storing LR (the return address) at 0(SP) and the FP
(parent's frame pointer) at -8(SP), store them at framesize-8(SP)
and framesize-16(SP), respectively.
We push and pop data onto the stack such that we're never accessing
anything below SP.
The prolog/epilog lengths are unchanged (3 insns for a typical prolog,
2 for a typical epilog).
We use 8 bytes more per frame.
Typical prologue:
STP.W (FP, LR), -16(SP)
MOVD SP, FP
SUB $C, SP
Typical epilogue:
ADD $C, SP
LDP.P 16(SP), (FP, LR)
RET
The previous word where we stored LR, at 0(SP), is now unused.
We could repurpose that slot for storing a local variable.
The new prolog and epilog instructions are recognized by libunwind,
so pc-sampling tools like perf should now be accurate. (TODO: except
maybe after the first RET instruction? Have to look into that.)
Update #73753 (fixes, for arm64)
Update #57302 (Quim thinks this will help on that issue)
Change-Id: I4800036a9a9a08aaaf35d9f99de79a36cf37ebb8
Reviewed-on: https://go-review.googlesource.com/c/go/+/674615
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Added in CL 700496, freeSomeSpanSPMCs attempts to bound tail latency by
processing at most 64 entries at a time, as well as returning early if
it notices a preemption request. Both of those are attempts to reduce
tail latency, as we cannot preempt the function while it holds the lock.
This scheme is based on a similar scheme in freeSomeWbufs.
freeSomeWbufs has a key difference: all workbufs in its list are
unconditionally freed. So freeSomeWbufs will always make forward
progress in each call (unless it is constantly preempted).
In contrast, freeSomeSpanSPMCs only frees "dead" entries. If the list
contains >64 live entries, a call may make no progress, and the caller
will simply keep calling in a loop forever, until the GC ends at which
point it returns success early. The infinite loop likely restarts at the
next GC cycle.
The queues are used on each P, so it is easy to have 64 permanently live
queues if GOMAXPROCS >= 64. If GOMAXPROCS < 64, it is possible to
transiently have more queues, but spanQueue.drain increases queue size
in an attempt to reach a steady state of one queue per P.
We must drop work.spanSPMCs.lock to allow preemption, but dropping the
lock allows mutation of the linked list, meaning we cannot simply
continue iteration after retaking lock. Since there is no
straightforward resolution to this and we expect this to generally only
be around 1 entry per P, simply remove the batching and process the
entire list without preemption. We may want to revisit this in the
future for very high GOMAXPROCS or if application regularly otherwise
create very long lists.
Fixes#75771.
Change-Id: I6a6a636cd3be443aacde5a678c460aa7066b4c4a
Reviewed-on: https://go-review.googlesource.com/c/go/+/709575
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Export the type `State` and add global variable `LoaderState` in
preparation for refactoring usage of other global variables in the
modload package.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/modload
rf 'mv state State'
rf 'add State func NewState() *State { return &State{} }'
rf 'add init.go:/NewState/+0 var LoaderState = NewState()'
Change-Id: I0ec6199ba3e05927bec12f11a60383d1b51b111a
Reviewed-on: https://go-review.googlesource.com/c/go/+/698055
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This test is *still* flaky, but it appears to be just
mayMoreStackPreempt and the thread count *occasionally* exceeds the
original (and arbitrary) thread count slack by exactly 1.
Bump the thread count slack by one. We can investigate further and bump
it again if it continues to be a problem.
Fixes#75664.
Change-Id: I29c922bba6d2cc99a8c3bf5e04cc512d0694f7fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/708868
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
If -bogo-local-dir is provided but doesn't exist, populate it with a git
checkout of the BoringSSL repo at the correct SHA.
Without any -bogo-local-dir argument the BoGo TLS handshake test will
fetch the BoringSSL source at a specific SHA as a Go module in a r/o
module directory. When debugging, or extending BoGo coverage, it's
preferable to have a mutable local copy of BoGo that the test will
use.
The pre-existing -bogo-local-dir flag offered a way to use a checkout of
BoGo but it relied on the user fetching the correct repo & revision
manually ahead of time. This commit extends the test to automatically
invoke `git` to clone the repo into the provided local dir at the
correct SHA based on the boringsslModVer const if the local dir doesn't
exist.
This leaves the user ready to make changes in local BoGo dir to aid
debugging, or to upstream as CRs to BoringSSL, and prevents using an
incorrect SHA by mistake.
Updates #72006
Change-Id: I0451a3d35203878cdf02a7587e138c3cd60d15a9
Reviewed-on: https://go-review.googlesource.com/c/go/+/687475
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
TryBot-Bypass: Daniel McCarney <daniel@binaryparadox.net>
Currently, we remove stores to local variables that are not read.
We don't do that for arguments. But arguments and locals are
essentially the same. Arguments are passed by value, and are not
expected to be read in the caller's frame. So we can remove the
writes to them as well. One exception is the cgo_unsafe_arg
directive, which makes all the arguments effectively address-taken.
cgo_unsafe_arg implies ABI0, so we just skip ABI0 functions'
arguments.
Cherry-picked from the dev.simd branch. This CL is not
necessarily SIMD specific. Apply early to reduce risk.
Change-Id: I8999fc50da6a87f22c1ec23e9a0c15483b6f7df8
Reviewed-on: https://go-review.googlesource.com/c/go/+/705815
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/708865
Currently, when shuffling registers, if we need to spill a
register, we always create a spill slot of type int64. The type
doesn't actually matter, as long as it is wide enough to hold the
registers. This is no longer true with SIMD registers, which could
be wider than a int64. Create the slot with the proper type
instead.
Cherry-picked from the dev.simd branch. This CL is not
necessarily SIMD specific. Apply early to reduce risk. Test is
SIMD specific so not included for now.
Change-Id: I85c82e2532001bfdefe98c9446f2dd18583d49b4
Reviewed-on: https://go-review.googlesource.com/c/go/+/704055
TryBot-Bypass: Cherry Mui <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/708860
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
For chunked iterations (useful for, but not exclusive to,
SIMD calculations) it is common to see the combination of
```
for ; i <= len(m)-4; i += 4 {
```
and
```
r0, r1, r2, r3 := m[i], m[i+1], m[i+2], m[i+3]
``
Prove did not handle the case of len-offset1 vs index+offset2
checking, but this change fixes this. There may be other
similar cases yet to handle -- this worked for the chunked
loops for simd, as well as a handful in std.
Cherry-picked from the dev.simd branch. This CL is not
necessarily SIMD specific. Apply early to reduce risk.
Change-Id: I3785df83028d517e5e5763206653b34b2befd3d0
Reviewed-on: https://go-review.googlesource.com/c/go/+/700696
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-on: https://go-review.googlesource.com/c/go/+/708859
Reviewed-by: David Chase <drchase@google.com>
The compiler has a logic to print different messages on internal
compiler error depending on whether this is a released version of
Go. It hides the panic stack trace if it is a released version. It
does this by checking the version and see if it has a "go" prefix.
This includes all the released versions. However, for a non-
released build, if there is no explicit version set, cmd/dist now
sets the toolchain version as go1.X-devel_XXX, which makes it be
treated as a released compiler, and causes the stack trace to be
hidden. Change the logic to not match a devel compiler as a
released compiler.
Cherry-picked from the dev.simd branch. This CL is not
necessarily SIMD specific. Apply early to reduce risk.
Change-Id: I5d3b2101527212f825b6e4000b36030c4f83870b
Reviewed-on: https://go-review.googlesource.com/c/go/+/682975
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/708855
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Updates the BoGo test runner to add a `-bogo-html-report` flag. When
provided, an HTML report is written to the flag argument path. The
report shows the fail/pass/skip status of run tests and allows
sorting/searching the output.
Change-Id: I8c704a51fbb03500f4134ebfaba06248baa3ca2f
Reviewed-on: https://go-review.googlesource.com/c/go/+/684955
Auto-Submit: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
TryBot-Bypass: Daniel McCarney <daniel@binaryparadox.net>
Commit-Queue: Carlos Amedee <carlos@golang.org>
This may be the long-term fix, but we first need to understand if this
just makes the tests flaky, or if it's revealing an actual underlying
issue. I'm leaning toward the former. If it is the former, ideally we
just make the tests robust (wait longer, maybe?).
For now, this change will make the longtest builders OK again.
For #75729.
Change-Id: If9b30107d04a8e5af5670850add3a53f9471eec6
Reviewed-on: https://go-review.googlesource.com/c/go/+/708715
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
The Decoder.InputOffset method was always ambiguous about the exact
offset returned since anything between the end of the previous token
to the start of the next token could be a valid result.
Empirically, it seems that the behavior was to report
the end of the previous token unless Decoder.More is called,
in which case it reports the start of the next token.
This is an odd semantic since a relatively side-effect free method
like More is not quite so side-effect free.
However, our goal is to preserve historical v1 semantic when possible
regardless of whether it made sense.
Note that jsontext.Decoder.InputOffset consistently always reports
the end of the previous token. Users can explicitly choose the
exact position they want by inspecting the UnreadBuffer.
Fixes#75468
Change-Id: I1e946e83c9d29dfc09f2913ff8d6b2b80632f292
Reviewed-on: https://go-review.googlesource.com/c/go/+/703856
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Use a sync.Pool to reuse the overlapped object passed to the different
Windows syscalls instead of keeping two of them in the FD struct.
This reduces the size of the FD struct from 248 to 152 bytes.
While here, pin the overlapped object for the duration of the overlapped
IO operation to comply with the memory safety rules.
Cq-Include-Trybots: luci.golang.try:gotip-windows-amd64-longtest,gotip-windows-amd64-race
Change-Id: I0161d163f681fe94b822c0c885aaa42c449e5342
Reviewed-on: https://go-review.googlesource.com/c/go/+/704235
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
WSASend and WSARecv functions capture the WSABuf structure before
returning, so there is no need to keep a copy of it in the
operation structure.
Write and Read functions don't need it, they can operate directly
on the byte slice.
To be on the safe side, pin the input byte slice so that stack-allocated
slices don't get moved while overlapped I/O is in progress.
Cq-Include-Trybots: luci.golang.try:gotip-windows-amd64-longtest,gotip-windows-amd64-race
Change-Id: I474bed94e11acafa0bdd8392b5dcf8993d8e1ed5
Reviewed-on: https://go-review.googlesource.com/c/go/+/704155
Reviewed-by: Junyang Shao <shaojunyang@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
Binutils defaults to exporting all symbols when building a Windows DLL.
To avoid that we were marking symbols with __declspec(dllexport) in
the cgo-generated headers, which instructs ld to export only those
symbols. However, that approach makes the headers hard to reuse when
importing the resulting DLL into other projects, as imported symbols
should be marked with __declspec(dllimport).
A better approach is to generate a .def file listing the symbols to
export, which gets the same effect without having to modify the headers.
Updates #30674Fixes#56994
Change-Id: I22bd0aa079e2be4ae43b13d893f6b804eaeddabf
Reviewed-on: https://go-review.googlesource.com/c/go/+/705776
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Reviewed-by: Than McIntosh <thanm@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The pcln.cutab slice holds uint32 elements, as can be seen in the
runtime.moduledata type. The slice was being created with the len
(and cap) set to the size of the slice, which means that the count
was four times too large. This patch sets the correct len/cap.
This doesn't matter for the runtime because nothing looks at
the len of cutab. Since the incorrect len is larger, all valid
indexes remain valid. Using the correct length means that more
invalid indexes will be caught at run time, but such cases are unlikely.
Still, using the correct len is less confusing.
While we're here use the simpler sliceSym for pcln.pclntab.
Change-Id: I09f680b3287467120d994b171c86c784085e3d27
Reviewed-on: https://go-review.googlesource.com/c/go/+/707595
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
This is a test/example/performance-comparison. Looking at the
generated code shows that there is still a lot of checking that
perhaps we can figure out how to optimize away.
$b/go test -bench=B -benchtime=5x .
goos: linux
goarch: amd64
pkg: simd/internal/simd_test
cpu: Intel(R) Xeon(R) Platinum 8481C CPU @ 2.70GHz
BenchmarkPlainTranspose-88 5 3143116414 ns/op
BenchmarkTiled4Transpose-88 5 1127457328 ns/op
BenchmarkTiled8Transpose-88 5 671788993 ns/op
Benchmark2BlockedTranspose-88 5 1665429657 ns/op
Benchmark3BlockedTranspose-88 5 1208767441 ns/op
Benchmark4BlockedTranspose-88 5 910212696 ns/op
Benchmark5aBlockedTranspose-88 5 939205670 ns/op
Benchmark5bBlockedTranspose-88 5 1018286871 ns/op
Change-Id: I78bae0fd2ff4f511dac4291b898bbb79b0114741
Reviewed-on: https://go-review.googlesource.com/c/go/+/700695
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
CL 706175 removed the NOFRAME directive from _rt0_arm64_netbsd but
did not change the BL instruction to a JMP instruction. This causes the
frame pointer to be stored on the stack, this making direct load from
RSP to be off by 8 bytes.
Cq-Include-Trybots: luci.golang.try:gotip-netbsd-arm64
Change-Id: I0c212fbaba74cfce508f961090dc6e66154c3054
Reviewed-on: https://go-review.googlesource.com/c/go/+/707675
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
When applying relocations, a malformed ELF file can provide an offset
that, when added to the relocation size, overflows. This wrapped-around
value could then incorrectly pass the bounds check, leading to a panic
when the slice is accessed with the original large offset.
This change eliminates the manual bounds and overflow checks
and writes a relocation to slice by calling putUint.
The putUint helper function centralizes the logic for validating slice
access, correctly handling both out-of-bounds and integer overflow conditions.
This simplifies the relocation code and improves robustness when parsing
malformed ELF files.
Fixes#75516
Change-Id: I00d806bf5501a9bf70200585ba4fd0475d7b2ddc
GitHub-Last-Rev: 49144311d3
GitHub-Pull-Request: golang/go#75522
Reviewed-on: https://go-review.googlesource.com/c/go/+/705075
Reviewed-by: Florian Lehner <lehner.florian86@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Commit-Queue: Ian Lance Taylor <iant@golang.org>
On Wasm, some programs have very small heap. Currently,
we use 4 MB arena size (like all other 32-bit platforms).
For a very small program, it needs to allocate one heap
arena, 4 MB size at a 4 MB aligned address. So we'll
need 8 MB of linear memory, whereas only a smaller
portion is actually used by the program. On Wasm, samll
programs are not uncommon (e.g. WASI plugins), and
users are concerned about the memory usage.
This CL switches to a smaller arena size, as well as a
smaller page allocator chunk size (both are now 512 KB).
So the heap will be grown in 512 KB granularity. For a
helloworld program, it now uses less than 3 MB of
linear memory, instead of 8 MB.
Change-Id: Ibd66c1fa6e794a12c00906cbacc8f2e410f196c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/683296
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The getgrouplist call is available on Illumos since December 2020:
f2c438c505
We can assume it is available for users now. Let's switch to using it
when cgo is enabled.
Since neither LUCY nor legacy trybots provide illumos, I tested this
locally in a OpenIndiana VM, with and without osusergo, with cgo enabled
and disabled.
This is a continuation of CL 315278.
Fixes#14709
Change-Id: I922049e7ea5f450f6900914b30967e522e56cfc9
Reviewed-on: https://go-review.googlesource.com/c/go/+/702975
Reviewed-by: Andrew Stormont <andyjstormont@gmail.com>
Auto-Submit: Damien Neil <dneil@google.com>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Kirill Kolyshkin <kolyshkin@gmail.com>
TryBot-Bypass: Kirill Kolyshkin <kolyshkin@gmail.com>
This adds methods SelectFromPair for {Int,Uint,Float}32x4
and SelectFromPairGrouped for {Int,Uint,Float}32x8.
Each of these has the signature
```
func(x T32xK.Method(a,b,c,d uint8, y T32xK) T32xK)
```
where a, b, c, d can be 0-7 and each one specifies an
element from the concatenated elements of x (0-3) and
y (4-7). When a, b, c, d are constants, 1 or 2
instructions are generated, otherwise, it's done the
harder-slower way with a function call.
Change-Id: I05eb9342e90edb9d83a4d0f5b924bcd2cfd4d12e
Reviewed-on: https://go-review.googlesource.com/c/go/+/703575
Reviewed-by: Junyang Shao <shaojunyang@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
When provided with a field or file name containing newlines,
multipart.FileContentDisposition and other header-producing functions
could create an invalid header value.
In some scenarios, this could permit a malicious input to perform
a CRLF injection attack:
field := "field"
evilFile := "name\"\r\nEvil-Header: \"evil"
fmt.Printf("Content-Disposition: %v\r\n", multipart.FileContentDisposition(field, evilFile))
// Prints:
// Content-Disposition: form-data; name="field"; filename="name"
// Evil-Header: "evil"
Percent-endode \r and \n characters in headers, as recommended by
https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#multipart/form-data-encoding-algorithm
The above algorithm also recommends using percent-encoding for quotes,
but preserve the existing backslash-escape behavior for now.
Empirically, browsers understand backslash-escape in attribute values.
Fixes#75557
Change-Id: Ia203df6ef45a098070f3ebb17f9b6cf80c520ed4
Reviewed-on: https://go-review.googlesource.com/c/go/+/706677
Auto-Submit: Damien Neil <dneil@google.com>
Reviewed-by: Nicholas Husin <nsh@golang.org>
Reviewed-by: Nicholas Husin <husin@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Exceptionally, we decided to make a compliance-related change following
CMVP's updated Implementation Guidance on September 2nd.
The Security Policy will be updated to reflect the new zip hash.
mkzip.go has been modified to accept versions of the form vX.Y.Z-hash,
where the -hash suffix is ignored for fips140.Version() but used to
name the zip file and the unpacked cache directory.
The new zip is generated with
go run ../../src/cmd/go/internal/fips140/mkzip.go -b c2097c7c v1.0.0-c2097c7c
from c2097c7c which is the current release-branch.go1.24 head.
The full diff between the zip file contents is included below.
For #74947
Updates #69536
$ diff -ru golang.org/fips140@v1.0.0/fips140/v1.0.0/ golang.org/fips140@v1.0.0-c2097c7c/fips140/v1.0.0-c2097c7c
diff -ru golang.org/fips140@v1.0.0/fips140/v1.0.0/cast.go golang.org/fips140@v1.0.0-c2097c7c/fips140/v1.0.0-c2097c7c/cast.go
--- golang.org/fips140@v1.0.0/fips140/v1.0.0/cast.go 1980-01-10 00:00:00.000000000 +0100
+++ golang.org/fips140@v1.0.0-c2097c7c/fips140/v1.0.0-c2097c7c/cast.go 1980-01-10 00:00:00.000000000 +0100
@@ -56,9 +56,10 @@
}
// PCT runs the named Pairwise Consistency Test (if operated in FIPS mode) and
-// returns any errors. If an error is returned, the key must not be used.
+// aborts the program (stopping the module input/output and entering the "error
+// state") if the test fails.
//
-// PCTs are mandatory for every key pair that is generated/imported, including
+// PCTs are mandatory for every generated (but not imported) key pair, including
// ephemeral keys (which effectively doubles the cost of key establishment). See
// Implementation Guidance 10.3.A Additional Comment 1.
//
@@ -66,17 +67,23 @@
//
// If a package p calls PCT during key generation, an invocation of that
// function should be added to fipstest.TestConditionals.
-func PCT(name string, f func() error) error {
+func PCT(name string, f func() error) {
if strings.ContainsAny(name, ",#=:") {
panic("fips: invalid self-test name: " + name)
}
if !Enabled {
- return nil
+ return
}
err := f()
if name == failfipscast {
err = errors.New("simulated PCT failure")
}
- return err
+ if err != nil {
+ fatal("FIPS 140-3 self-test failed: " + name + ": " + err.Error())
+ panic("unreachable")
+ }
+ if debug {
+ println("FIPS 140-3 PCT passed:", name)
+ }
}
diff -ru golang.org/fips140@v1.0.0/fips140/v1.0.0/ecdh/ecdh.go golang.org/fips140@v1.0.0-c2097c7c/fips140/v1.0.0-c2097c7c/ecdh/ecdh.go
--- golang.org/fips140@v1.0.0/fips140/v1.0.0/ecdh/ecdh.go 1980-01-10 00:00:00.000000000 +0100
+++ golang.org/fips140@v1.0.0-c2097c7c/fips140/v1.0.0-c2097c7c/ecdh/ecdh.go 1980-01-10 00:00:00.000000000 +0100
@@ -161,6 +161,27 @@
if err != nil {
continue
}
+
+ // A "Pairwise Consistency Test" makes no sense if we just generated the
+ // public key from an ephemeral private key. Moreover, there is no way to
+ // check it aside from redoing the exact same computation again. SP 800-56A
+ // Rev. 3, Section 5.6.2.1.4 acknowledges that, and doesn't require it.
+ // However, ISO 19790:2012, Section 7.10.3.3 has a blanket requirement for a
+ // PCT for all generated keys (AS10.35) and FIPS 140-3 IG 10.3.A, Additional
+ // Comment 1 goes out of its way to say that "the PCT shall be performed
+ // consistent [...], even if the underlying standard does not require a
+ // PCT". So we do it. And make ECDH nearly 50% slower (only) in FIPS mode.
+ fips140.PCT("ECDH PCT", func() error {
+ p1, err := c.newPoint().ScalarBaseMult(privateKey.d)
+ if err != nil {
+ return err
+ }
+ if !bytes.Equal(p1.Bytes(), privateKey.pub.q) {
+ return errors.New("crypto/ecdh: public key does not match private key")
+ }
+ return nil
+ })
+
return privateKey, nil
}
}
@@ -188,28 +209,6 @@
panic("crypto/ecdh: internal error: public key is the identity element")
}
- // A "Pairwise Consistency Test" makes no sense if we just generated the
- // public key from an ephemeral private key. Moreover, there is no way to
- // check it aside from redoing the exact same computation again. SP 800-56A
- // Rev. 3, Section 5.6.2.1.4 acknowledges that, and doesn't require it.
- // However, ISO 19790:2012, Section 7.10.3.3 has a blanket requirement for a
- // PCT for all generated keys (AS10.35) and FIPS 140-3 IG 10.3.A, Additional
- // Comment 1 goes out of its way to say that "the PCT shall be performed
- // consistent [...], even if the underlying standard does not require a
- // PCT". So we do it. And make ECDH nearly 50% slower (only) in FIPS mode.
- if err := fips140.PCT("ECDH PCT", func() error {
- p1, err := c.newPoint().ScalarBaseMult(key)
- if err != nil {
- return err
- }
- if !bytes.Equal(p1.Bytes(), publicKey) {
- return errors.New("crypto/ecdh: public key does not match private key")
- }
- return nil
- }); err != nil {
- panic(err)
- }
-
k := &PrivateKey{d: bytes.Clone(key), pub: PublicKey{curve: c.curve, q: publicKey}}
return k, nil
}
diff -ru golang.org/fips140@v1.0.0/fips140/v1.0.0/ecdsa/cast.go golang.org/fips140@v1.0.0-c2097c7c/fips140/v1.0.0-c2097c7c/ecdsa/cast.go
--- golang.org/fips140@v1.0.0/fips140/v1.0.0/ecdsa/cast.go 1980-01-10 00:00:00.000000000 +0100
+++ golang.org/fips140@v1.0.0-c2097c7c/fips140/v1.0.0-c2097c7c/ecdsa/cast.go 1980-01-10 00:00:00.000000000 +0100
@@ -51,8 +51,8 @@
}
}
-func fipsPCT[P Point[P]](c *Curve[P], k *PrivateKey) error {
- return fips140.PCT("ECDSA PCT", func() error {
+func fipsPCT[P Point[P]](c *Curve[P], k *PrivateKey) {
+ fips140.PCT("ECDSA PCT", func() error {
hash := testHash()
drbg := newDRBG(sha512.New, k.d, bits2octets(P256(), hash), nil)
sig, err := sign(c, k, drbg, hash)
diff -ru golang.org/fips140@v1.0.0/fips140/v1.0.0/ecdsa/ecdsa.go golang.org/fips140@v1.0.0-c2097c7c/fips140/v1.0.0-c2097c7c/ecdsa/ecdsa.go
--- golang.org/fips140@v1.0.0/fips140/v1.0.0/ecdsa/ecdsa.go 1980-01-10 00:00:00.000000000 +0100
+++ golang.org/fips140@v1.0.0-c2097c7c/fips140/v1.0.0-c2097c7c/ecdsa/ecdsa.go 1980-01-10 00:00:00.000000000 +0100
@@ -166,11 +166,6 @@
return nil, err
}
priv := &PrivateKey{pub: *pub, d: d.Bytes(c.N)}
- if err := fipsPCT(c, priv); err != nil {
- // This can happen if the application went out of its way to make an
- // ecdsa.PrivateKey with a mismatching PublicKey.
- return nil, err
- }
return priv, nil
}
@@ -203,10 +198,7 @@
},
d: k.Bytes(c.N),
}
- if err := fipsPCT(c, priv); err != nil {
- // This clearly can't happen, but FIPS 140-3 mandates that we check it.
- panic(err)
- }
+ fipsPCT(c, priv)
return priv, nil
}
diff -ru golang.org/fips140@v1.0.0/fips140/v1.0.0/ecdsa/hmacdrbg.go golang.org/fips140@v1.0.0-c2097c7c/fips140/v1.0.0-c2097c7c/ecdsa/hmacdrbg.go
--- golang.org/fips140@v1.0.0/fips140/v1.0.0/ecdsa/hmacdrbg.go 1980-01-10 00:00:00.000000000 +0100
+++ golang.org/fips140@v1.0.0-c2097c7c/fips140/v1.0.0-c2097c7c/ecdsa/hmacdrbg.go 1980-01-10 00:00:00.000000000 +0100
@@ -121,7 +121,7 @@
//
// This should only be used for ACVP testing. hmacDRBG is not intended to be
// used directly.
-func TestingOnlyNewDRBG(hash func() fips140.Hash, entropy, nonce []byte, s []byte) *hmacDRBG {
+func TestingOnlyNewDRBG[H fips140.Hash](hash func() H, entropy, nonce []byte, s []byte) *hmacDRBG {
return newDRBG(hash, entropy, nonce, plainPersonalizationString(s))
}
diff -ru golang.org/fips140@v1.0.0/fips140/v1.0.0/ed25519/cast.go golang.org/fips140@v1.0.0-c2097c7c/fips140/v1.0.0-c2097c7c/ed25519/cast.go
--- golang.org/fips140@v1.0.0/fips140/v1.0.0/ed25519/cast.go 1980-01-10 00:00:00.000000000 +0100
+++ golang.org/fips140@v1.0.0-c2097c7c/fips140/v1.0.0-c2097c7c/ed25519/cast.go 1980-01-10 00:00:00.000000000 +0100
@@ -12,8 +12,8 @@
"sync"
)
-func fipsPCT(k *PrivateKey) error {
- return fips140.PCT("Ed25519 sign and verify PCT", func() error {
+func fipsPCT(k *PrivateKey) {
+ fips140.PCT("Ed25519 sign and verify PCT", func() error {
return pairwiseTest(k)
})
}
diff -ru golang.org/fips140@v1.0.0/fips140/v1.0.0/ed25519/ed25519.go golang.org/fips140@v1.0.0-c2097c7c/fips140/v1.0.0-c2097c7c/ed25519/ed25519.go
--- golang.org/fips140@v1.0.0/fips140/v1.0.0/ed25519/ed25519.go 1980-01-10 00:00:00.000000000 +0100
+++ golang.org/fips140@v1.0.0-c2097c7c/fips140/v1.0.0-c2097c7c/ed25519/ed25519.go 1980-01-10 00:00:00.000000000 +0100
@@ -69,10 +69,7 @@
fips140.RecordApproved()
drbg.Read(priv.seed[:])
precomputePrivateKey(priv)
- if err := fipsPCT(priv); err != nil {
- // This clearly can't happen, but FIPS 140-3 requires that we check.
- panic(err)
- }
+ fipsPCT(priv)
return priv, nil
}
@@ -88,10 +85,6 @@
}
copy(priv.seed[:], seed)
precomputePrivateKey(priv)
- if err := fipsPCT(priv); err != nil {
- // This clearly can't happen, but FIPS 140-3 requires that we check.
- panic(err)
- }
return priv, nil
}
@@ -137,12 +130,6 @@
copy(priv.prefix[:], h[32:])
- if err := fipsPCT(priv); err != nil {
- // This can happen if the application messed with the private key
- // encoding, and the public key doesn't match the seed anymore.
- return nil, err
- }
-
return priv, nil
}
diff -ru golang.org/fips140@v1.0.0/fips140/v1.0.0/fips140.go golang.org/fips140@v1.0.0-c2097c7c/fips140/v1.0.0-c2097c7c/fips140.go
--- golang.org/fips140@v1.0.0/fips140/v1.0.0/fips140.go 1980-01-10 00:00:00.000000000 +0100
+++ golang.org/fips140@v1.0.0-c2097c7c/fips140/v1.0.0-c2097c7c/fips140.go 1980-01-10 00:00:00.000000000 +0100
@@ -62,6 +62,10 @@
return "Go Cryptographic Module"
}
+// Version returns the formal version (such as "v1.0.0") if building against a
+// frozen module with GOFIPS140. Otherwise, it returns "latest".
func Version() string {
- return "v1.0"
+ // This return value is replaced by mkzip.go, it must not be changed or
+ // moved to a different file.
+ return "v1.0.0"
}
diff -ru golang.org/fips140@v1.0.0/fips140/v1.0.0/mlkem/mlkem1024.go golang.org/fips140@v1.0.0-c2097c7c/fips140/v1.0.0-c2097c7c/mlkem/mlkem1024.go
--- golang.org/fips140@v1.0.0/fips140/v1.0.0/mlkem/mlkem1024.go 1980-01-10 00:00:00.000000000 +0100
+++ golang.org/fips140@v1.0.0-c2097c7c/fips140/v1.0.0-c2097c7c/mlkem/mlkem1024.go 1980-01-10 00:00:00.000000000 +0100
@@ -118,10 +118,7 @@
var z [32]byte
drbg.Read(z[:])
kemKeyGen1024(dk, &d, &z)
- if err := fips140.PCT("ML-KEM PCT", func() error { return kemPCT1024(dk) }); err != nil {
- // This clearly can't happen, but FIPS 140-3 requires us to check.
- panic(err)
- }
+ fips140.PCT("ML-KEM PCT", func() error { return kemPCT1024(dk) })
fips140.RecordApproved()
return dk, nil
}
@@ -149,10 +146,6 @@
d := (*[32]byte)(seed[:32])
z := (*[32]byte)(seed[32:])
kemKeyGen1024(dk, d, z)
- if err := fips140.PCT("ML-KEM PCT", func() error { return kemPCT1024(dk) }); err != nil {
- // This clearly can't happen, but FIPS 140-3 requires us to check.
- panic(err)
- }
fips140.RecordApproved()
return dk, nil
}
diff -ru golang.org/fips140@v1.0.0/fips140/v1.0.0/mlkem/mlkem768.go golang.org/fips140@v1.0.0-c2097c7c/fips140/v1.0.0-c2097c7c/mlkem/mlkem768.go
--- golang.org/fips140@v1.0.0/fips140/v1.0.0/mlkem/mlkem768.go 1980-01-10 00:00:00.000000000 +0100
+++ golang.org/fips140@v1.0.0-c2097c7c/fips140/v1.0.0-c2097c7c/mlkem/mlkem768.go 1980-01-10 00:00:00.000000000 +0100
@@ -177,10 +177,7 @@
var z [32]byte
drbg.Read(z[:])
kemKeyGen(dk, &d, &z)
- if err := fips140.PCT("ML-KEM PCT", func() error { return kemPCT(dk) }); err != nil {
- // This clearly can't happen, but FIPS 140-3 requires us to check.
- panic(err)
- }
+ fips140.PCT("ML-KEM PCT", func() error { return kemPCT(dk) })
fips140.RecordApproved()
return dk, nil
}
@@ -208,10 +205,6 @@
d := (*[32]byte)(seed[:32])
z := (*[32]byte)(seed[32:])
kemKeyGen(dk, d, z)
- if err := fips140.PCT("ML-KEM PCT", func() error { return kemPCT(dk) }); err != nil {
- // This clearly can't happen, but FIPS 140-3 requires us to check.
- panic(err)
- }
fips140.RecordApproved()
return dk, nil
}
diff -ru golang.org/fips140@v1.0.0/fips140/v1.0.0/rsa/keygen.go golang.org/fips140@v1.0.0-c2097c7c/fips140/v1.0.0-c2097c7c/rsa/keygen.go
--- golang.org/fips140@v1.0.0/fips140/v1.0.0/rsa/keygen.go 1980-01-10 00:00:00.000000000 +0100
+++ golang.org/fips140@v1.0.0-c2097c7c/fips140/v1.0.0-c2097c7c/rsa/keygen.go 1980-01-10 00:00:00.000000000 +0100
@@ -105,7 +105,28 @@
// negligible chance of failure we can defer the check to the end of key
// generation and return an error if it fails. See [checkPrivateKey].
- return newPrivateKey(N, 65537, d, P, Q)
+ k, err := newPrivateKey(N, 65537, d, P, Q)
+ if err != nil {
+ return nil, err
+ }
+
+ if k.fipsApproved {
+ fips140.PCT("RSA sign and verify PCT", func() error {
+ hash := []byte{
+ 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08,
+ 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10,
+ 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18,
+ 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f, 0x20,
+ }
+ sig, err := signPKCS1v15(k, "SHA-256", hash)
+ if err != nil {
+ return err
+ }
+ return verifyPKCS1v15(k.PublicKey(), "SHA-256", hash, sig)
+ })
+ }
+
+ return k, nil
}
}
diff -ru golang.org/fips140@v1.0.0/fips140/v1.0.0/rsa/rsa.go golang.org/fips140@v1.0.0-c2097c7c/fips140/v1.0.0-c2097c7c/rsa/rsa.go
--- golang.org/fips140@v1.0.0/fips140/v1.0.0/rsa/rsa.go 1980-01-10 00:00:00.000000000 +0100
+++ golang.org/fips140@v1.0.0-c2097c7c/fips140/v1.0.0-c2097c7c/rsa/rsa.go 1980-01-10 00:00:00.000000000 +0100
@@ -310,26 +310,6 @@
return errors.New("crypto/rsa: d too small")
}
- // If the key is still in scope for FIPS mode, perform a Pairwise
- // Consistency Test.
- if priv.fipsApproved {
- if err := fips140.PCT("RSA sign and verify PCT", func() error {
- hash := []byte{
- 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08,
- 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10,
- 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18,
- 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f, 0x20,
- }
- sig, err := signPKCS1v15(priv, "SHA-256", hash)
- if err != nil {
- return err
- }
- return verifyPKCS1v15(priv.PublicKey(), "SHA-256", hash, sig)
- }); err != nil {
- return err
- }
- }
-
return nil
}
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest
Change-Id: I6a6a6964b1780f19ec2b5202052de58b47d9342c
Reviewed-on: https://go-review.googlesource.com/c/go/+/701520
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Commit-Queue: Junyang Shao <shaojunyang@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
CMVP clarified with the September 2nd changes to IG 10.3.A that PCTs
don't need to run on imported keys.
However, PCT failure must enter the error state (which for us is fatal).
Thankfully, now that PCTs only run on key generation, we can be assured
they will never fail.
This change should only affect FIPS 140-3 mode.
While at it, make the CAST/PCT testing more robust, checking
TestConditional is terminated by a fatal error (and not by t.Fatal).
Fixes#74947
Updates #69536
Change-Id: I6a6a696439e1560c10f3cce2cb208fd40c5bc641
Reviewed-on: https://go-review.googlesource.com/c/go/+/701517
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
TryBot-Bypass: Filippo Valsorda <filippo@golang.org>
We are re-sealing the .zip file anyway for another reason, might as well
take the opportunity to fix the "v1.0" mistake.
Note that the actual returned version change will happen when re-sealing
the .zip, as the latest mkzip.go will inject "v1.0.0" instead of "v1.0".
This reapplies CL 701518, reverted in CL 702255.
Change-Id: Ib5b3721bda35c32dd48293b3d1193c12661662dd
Reviewed-on: https://go-review.googlesource.com/c/go/+/702316
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Bypass: Filippo Valsorda <filippo@golang.org>
SIMD vector types are opqaue, and are expected to be operated with
methods. It is not always possible to compare the two vectors
efficiently. Instead of adding more magic to the compiler to
handle the == operator, mark the vector types uncomparable.
Change-Id: I4ca5d5e80ca7d8992dffa7b3c0386b75eb19cfa8
Reviewed-on: https://go-review.googlesource.com/c/go/+/705855
Reviewed-by: Junyang Shao <shaojunyang@google.com>
TryBot-Bypass: Cherry Mui <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
When calling into C via cmd/cgo, the generated code calls
_cgo_tsan_acquire / _cgo_tsan_release around the C call to report a
dummy lock to the C/C++ TSAN runtime. This is necessary because the
C/C++ TSAN runtime does not understand synchronization within Go and
would otherwise report false positive race reports. See the comment in
cmd/cgo/out.go for more details.
Various C functions in runtime/cgo also contain manual calls to
_cgo_tsan_acquire/release where necessary to suppress race reports.
However, the cgo symbolizer and cgo traceback functions called from
callCgoSymbolizer and cgoContextPCs, respectively, do not have any
instrumentation [1]. They call directly into user C functions with no
TSAN instrumentation.
This means they have an opportunity to report false race conditions. The
most direct way is via their argument. Both are passed a pointer to a
struct stored on the Go stack, and both write to fields of the struct.
If two calls are passed the same pointer from different threads, the C
TSAN runtime will think this is a race.
This is simple to achieve for the cgo symbolizer function, which the
new regression test does. callCgoSymbolizer is called on the standard
goroutine stack, so the argument is a pointer into the goroutine stack.
If the goroutine moves Ms between two calls, it will look like a race.
On the other hand, cgoContextPCs is called on the system stack. Each M
has a unique system stack, so for it to pass the same argument pointer
on different threads would require the first M to exit, free its stack,
and the same region of address space to be used as the stack for a new
M. Theoretically possible, but quite unlikely.
Both of these are addressed by providing a C wrapper in runtime/cgo that
calls _cgo_tsan_acquire/_cgo_tsan_release around calls to the symbolizer
and traceback functions.
There is a lot of room for future cleanup here. Most runtime/cgo
functions have manual instrumentation in their C implementation. That
could be removed in favor of instrumentation in the runtime. We could
even theoretically remove the instrumentation from cmd/cgo and move it
to cgocall. None of these are necessary, but may make things more
consistent and easier to follow.
[1] Note that the cgo traceback function called from the signal handler
via x_cgo_callers _does_ have manual instrumentation.
Fixes#73949.
Cq-Include-Trybots: luci.golang.try:gotip-freebsd-amd64,gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Change-Id: I6a6a636c9daa38f7fd00694af76b75cb93ba1886
Reviewed-on: https://go-review.googlesource.com/c/go/+/677955
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently, when the -w flag is set, it doesn't actually disable
the debug info generation with in external linking mode. (It does
make the Go object have no debug info, but C objects may still
have.) Pass "-Wl,-S" to let the external linker disable debug info
generation.
Change-Id: I0fce56b9f23a45546b69b9e6dd027c5527b1bc87
Reviewed-on: https://go-review.googlesource.com/c/go/+/705857
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The fdct.go and idct.go files were derived from the MPEG-SSG and
JPEG-IJG reference code and therefore carry licenses specific to those
groups. Various license checkers flag these files as potentially
problematic. The code is also not terribly well documented.
This CL fixes the license problem by adding a new, from-scratch
implementation using a different algorithm. As a bonus, the new code
is both faster and more accurate than the old encumbered code.
On speed, the new code is up to 20% faster; benchmarks below.
On accuracy, in the set of blocks used in the test, we can measure
the number of output values that are off-by-one from the exact rounded answer.
The old FDCT was off in 8.6% of values; the new one is off in 2.5%.
The old IDCT was off in 1.4% of values; the new one is off in 1.2%.
goos: darwin
goarch: arm64
pkg: image/jpeg
cpu: Apple M3 Pro
│ old │ new │
│ sec/op │ sec/op vs base │
FDCT-12 619.6n ± 3% 586.5n ± 1% -5.34% (p=0.000 n=10)
IDCT-12 752.4n ± 4% 628.0n ± 1% -16.54% (p=0.000 n=10)
goos: linux
goarch: amd64
cpu: Intel(R) Xeon(R) CPU @ 2.30GHz
│ old │ new │
│ sec/op │ sec/op vs base │
FDCT-16 1.817µ ± 0% 1.542µ ± 0% -15.11% (p=0.000 n=10)
IDCT-16 1.897µ ± 0% 1.514µ ± 0% -20.22% (p=0.000 n=10)
goos: linux
goarch: arm64
cpu: whatever gotip-linux-arm64 has
│ old │ new │
│ sec/op │ sec/op vs base │
FDCT-8 1.844µ ± 0% 1.847µ ± 0% +0.14% (p=0.000 n=10)
IDCT-8 2.127µ ± 0% 1.973µ ± 0% -7.26% (p=0.000 n=10)
Change-Id: Ie6d14103c8478ba5a779f234da84f345828eb925
Reviewed-on: https://go-review.googlesource.com/c/go/+/705518
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Nigel Tao <nigeltao@google.com>
The reference implementations slowFDCT and slowIDCT were not
rounding correctly, making the test not as good as it could be.
Before, the real implementations were required to always produce
values within ±2 of the reference; now, with no changes,
the real implementations produce values within ±1 of the (corrected)
reference.
Also tighten the test to return an error not just on a single value
exceeding tolerance but also on too many values at exactly that
tolerance.
Change-Id: I3dd6ca7582178fef972fb812d848f7a0158a6ed8
Reviewed-on: https://go-review.googlesource.com/c/go/+/705517
Auto-Submit: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Loop information is sketchy when there are irreducible loops.
Sometimes blocks inside 2 loops can be recorded as only being part of
the outer loop. That causes tighten to move values that want to move
into such a block to move out of the loop altogether, breaking the
invariant that operations have to be scheduled after their args.
Fixes#75569
Change-Id: Idd80e6d2268094b8ae6387563081fdc1e211856a
Reviewed-on: https://go-review.googlesource.com/c/go/+/706355
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
This CL adds a generator function in runtime/_mkmalloc to generate
specialized mallocgc functions for sizes up throuht 512 bytes. (That's
the limit where it's possible to end up in the no header case when there
are scan bits, and where the benefits of the specialized functions
significantly diminish according to microbenchmarks). If the
specializedmalloc GOEXPERIMENT is turned on, mallocgc will call one of
these functions in the no header case.
malloc_generated.go is the generated file containing the specialized
malloc functions.
malloc_stubs.go contains the templates that will be stamped to create
the specialized malloc functions.
malloc_tables_generated contains the tables that mallocgc will use to
select the specialized function to call.
I've had to update the two stdlib_test.go files to account for the new
submodule mkmalloc is in. mprof_test accounts for the changes in the
stacks since different functions can be called in some cases.
I still need to investigate heapsampling.go.
Change-Id: Ia0f68dccdf1c6a200554ae88657cf4d686ace819
Reviewed-on: https://go-review.googlesource.com/c/go/+/665835
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This change removes the locked global span queue and replaces the
fixed-size local span queue with a variable-sized local span queue. The
variable-sized local span queue grows as needed to accomodate local
work. With no global span queue either, GC workers balance work amongst
themselves by stealing from each other.
The new variable-sized local span queues are inspired by the P-local
deque underlying sync.Pool. Unlike the sync.Pool deque, however, both
the owning P and stealing Ps take spans from the tail, making this
incarnation a strict queue, not a deque. This is intentional, since we
want a queue-like order to encourage objects to accumulate on each span.
These variable-sized local span queues are crucial to mark termination,
just like the global span queue was. To avoid hitting the ragged barrier
too often, we must check whether any Ps have any spans on their
variable-sized local span queues. We maintain a per-P atomic bitmask
(another pMask) that contains this state. We can also use this to speed
up stealing by skipping Ps that don't have any local spans.
The variable-sized local span queues are slower than the old fixed-size
local span queues because of the additional indirection, so this change
adds a non-atomic local fixed-size queue. This risks getting work stuck
on it, so, similarly to how workbufs work, each worker will occasionally
dump some spans onto its local variable-sized queue. This scales much
more nicely than dumping to a global queue, but is still visible to all
other Ps.
For #73581.
Change-Id: I814f54d9c3cc7fa7896167746e9823f50943ac22
Reviewed-on: https://go-review.googlesource.com/c/go/+/700496
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
TestNumberOfExportedFunctions checks the number of exported functions
announced in the PE export table, getting it from the .edata section.
If the section is not found, the test is skipped. However, the PE spec
doesn't mandate that the export table be in a section named .edata,
making this test prone to being skipped unnecessarily.
While here, remove a check in cmd/go.testBuildmodePIE that was testing
the same thing in order to verify that the binary had a relocation table
. Not only the test is duplicated, but also it in unnecessary because
it already testing that the PE characteristics doesn't contain the
IMAGE_FILE_RELOCS_STRIPPED flag.
Closes#46719
Cq-Include-Trybots: luci.golang.try:gotip-windows-arm64
Change-Id: I28d1e261b38388868dd3c19ef6ddddad7bf105ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/705755
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
X86_64_RELOC_SUBTRACTOR is handled as a generic R_PCREL relocations,
which gets the relocation size subtracted from the relocated value.
This is not supposed to happen for this particular relocation, so
compensate by adding the size to the addend.
Cq-Include-Trybots: luci.golang.try:gotip-darwin-amd64-race
Change-Id: I6e6889d63bb03b8076e3e409722601dfebec57e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/703776
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
CL 641955 changes the Unified IR reader to not doing shapify when
reading reshaping expression, prevent losing of the original type.
This is an oversight, as the main problem isn't about shaping during the
reshaping process itself, but about the specific case of shaping a
pointer shape type. This bug occurs when instantiating a generic
function within another generic function with a pointer shape type as
type parameter, which will convert `*[]go.shape.T` to `*go.shape.uint8`,
resulting in the loss of the original expression's type.
This commit changes Unified IR reader to avoid pointer shaping for
`*[]go.shape.T`, ensures that the original type is preserved when
processing reshaping expressions.
Updates #71184
Updates #73947Fixes#74260Fixes#75461
Change-Id: Icede6b73247d0d367bb485619f2dafb60ad66806
Reviewed-on: https://go-review.googlesource.com/c/go/+/704095
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: David Chase <drchase@google.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Right now, gcMarkWorkAvailable is used in two scenarios. The first is
critical: we use it to determine whether we're approaching mark
termination, and it's crucial to reaching a fixed point across the
ragged barrier in gcMarkDone. The second is a heuristic: should we spin
up another GC worker?
This change splits gcMarkWorkAvailable into these two separate
conditions. This change also deduplicates the logic for updating
work.nwait into more abstract helpers "gcBeginWork" and "gcEndWork."
This change is solely refactoring, and should be a no-op. There are only
two functional changes:
- work.nwait is incremented after setting pp.gcMarkWorkerMode in the
background worker code. I don't believe this change is observable
except if the code fails to update work.nwait (either it results in a
non-sensical number, or the stack is corrupted) in which case the
goroutine may not be labeled as a mark worker in the resulting stack
trace (it should be obvious from the stack frames though).
- endCheckmarks also checks work.nwait == work.nproc, which should be
fine since we never mutate work.nwait on that path. That extra check
should be a no-op.
Splitting these two use-cases for gcMarkWorkAvailable is conceptually
helpful, and the checks may also diverge from Green Tea once we get rid
of the global span queue.
Change-Id: I0bec244a14ee82919c4deb7c1575589c0dca1089
Reviewed-on: https://go-review.googlesource.com/c/go/+/701176
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently, we remove stores to local variables that are not read.
We don't do that for arguments. But arguments and locals are
essentially the same. Arguments are passed by value, and are not
expected to be read in the caller's frame. So we can remove the
writes to them as well. One exception is the cgo_unsafe_arg
directive, which makes all the arguments effectively address-taken.
cgo_unsafe_arg implies ABI0, so we just skip ABI0 functions'
arguments.
Change-Id: I8999fc50da6a87f22c1ec23e9a0c15483b6f7df8
Reviewed-on: https://go-review.googlesource.com/c/go/+/705815
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
On UNIX-like platforms, the -w flag disables DWARF, and the -s
flag implies -w (so it disables both the symbol table and DWARF).
The implied -w can be negated with -w=0, i.e. -s -w=0 disables the
symbol table but keeps the DWARF. Currently, this negation doesn't
work on Windows. This CL makes it so, so it is consistent on all
platforms (that support DWARF).
Change-Id: I19764a15768433afe333b37061cea16f06cb901b
Reviewed-on: https://go-review.googlesource.com/c/go/+/703998
Reviewed-by: Than McIntosh <thanm@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Conflicts:
- src/internal/buildcfg/exp.go
Merge List:
+ 2025-09-22 9b2d39b75b cmd/compile/internal/ssa: match style and formatting
+ 2025-09-22 e23edf5e55 runtime: don't re-read metrics before check in TestReadMetricsSched
+ 2025-09-22 177cd8d763 log/slog: use a pooled json encoder
+ 2025-09-22 2353c15785 cmd/cgo/internal/test: skip TestMultipleAssign when using UCRT on Windows
+ 2025-09-22 32dfd69282 cmd/dist: disable FIPS 140-3 mode when testing maphash with purego
+ 2025-09-19 7f6ff5ec3e cmd/compile: fix doc word
+ 2025-09-19 9693b94be0 runtime: include stderr when objdump fails
+ 2025-09-19 8616981ce6 log/slog: optimize slog Level.String() to avoid fmt.Sprintf
+ 2025-09-19 b8af744360 testing: fix example for unexported identifier
+ 2025-09-19 51dc5bfe6c Revert "cmd/go: disable cgo by default if CC unset and DefaultCC doesn't exist"
+ 2025-09-19 ee7bf06cb3 time: improve ParseDuration performance for invalid input
+ 2025-09-19 f9e61a9a32 cmd/compile: duplicate nil check to two branches of write barrier
+ 2025-09-18 3cf1aaf8b9 runtime: use futexes with 64-bit time on Linux
+ 2025-09-18 0ab038af62 cmd/compile/internal/abi: use clear built-in
+ 2025-09-18 00bf24fdca bytes: use clear in test
+ 2025-09-18 f9701d21d2 crypto: use clear built-in
+ 2025-09-18 a58afe44fa net: fix testHookCanceledDial race
+ 2025-09-18 3203a5da29 net/http: avoid connCount underflow race
+ 2025-09-18 8ca209ec39 context: don't return a non-nil from Err before Done is closed
+ 2025-09-18 3032894e04 runtime: make explicit nil check in heapSetTypeSmallHeader
+ 2025-09-17 ef05b66d61 cmd/internal/obj/riscv: add support for Zicond instructions
+ 2025-09-17 78ef487a6f cmd/compile: fix the issue of shift amount exceeding the valid range
+ 2025-09-17 77aac7bb75 runtime: don't enable heap randomization if MSAN or ASAN is enabled
+ 2025-09-17 465b85eb76 runtime: fix CheckScavengedBitsCleared with randomized heap base
+ 2025-09-17 909704b85e encoding/json/v2: fix typo in comment
+ 2025-09-17 3db5979e8c testing: use reflect.TypeAssert and reflect.TypeFor
+ 2025-09-17 6a8dbbecbf path/filepath: fix EvalSymlinks to return ENOTDIR on plan9
+ 2025-09-17 bffe7ad9f1 go/parser: Add TestBothLineAndLeadComment
+ 2025-09-17 02a888e820 go/ast: document that (*ast.File).Comments is sorted by position
+ 2025-09-16 594deca981 cmd/link: simplify PE relocations mapping
+ 2025-09-16 9df1a289ac go/parser: simplify expectSemi
+ 2025-09-16 72ba117bda internal/buildcfg: enable randomizedHeapBase64 by default
+ 2025-09-16 796ea3bc2e os/user: align test file name and build tags
+ 2025-09-16 a69395eab2 runtime/_mkmalloc: add a copy of cloneNode
+ 2025-09-16 cbdad4fc3c cmd/go: check pattern for utf8 validity before call regexp.MustCompile
+ 2025-09-16 c2d85eb999 cmd/go: disable cgo by default if CC unset and DefaultCC doesn't exist
+ 2025-09-16 ac82fe68aa bytes,strings: remove reference to non-existent SplitFunc
+ 2025-09-16 0b26678db2 cmd/compile: fix mips zerorange implementation
+ 2025-09-16 e2cfc1eb3a cmd/internal/obj/riscv: improve handling of float point moves
+ 2025-09-16 281c632e6e crypto/x509/internal/macos: standardize package name
+ 2025-09-16 61dc7fe30d iter: document that calling yield after terminated range loop causes runtime panic
Change-Id: Ic06019efc855913632003f41eb10c746b3410b0a
The two remaining popular flakes in TestReadMetricsSched are with
waiting and not-in-go goroutines. I believe the reason for both of these
is pollution due to other goroutines in the test binary, and we can be a
little bit more robust to them.
In particular, both of these tests spin until there's a particular
condition met in the metrics. Then they both immediately re-read the
metrics. The metrics being checked are not guaranteed to stay that way
in the re-read. For example, for the waiting case, it's possible for
>1000 to be waiting, but then some leftover goroutines from a previous
test wake up off of some condition, causing the number to dip again on
the re-read. This is supported by the fact that in some of these
failures, the test takes very little time to execute (the condition that
there are at least 1000 waiting goroutines is almost immediately
satisfied) but it still fails (the re-read causes us to notice that there
are <1000 waiting goroutines).
This change makes the test more robust by not performing this re-read.
This means more possible false negatives, but the error cases we're
looking for (bad metrics) should still show up with some reasonable
probability when something *is* truly wrong.
For #75049.
Change-Id: Idc3a8030bed8da51f24322efe15f3ff13da05623
Reviewed-on: https://go-review.googlesource.com/c/go/+/705875
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The Universal C Runtime (UCRT) default behavior is to crash the program
when strtol is called with an invalid base (that is, not 0 or 2..36).
This an invalid base (that is, not 0 or 2..36). This changes the test to
skip when running on Windows and linking with UCRT.
When using external linking mode this test passes if using the Mingw-w64
toolchain, even when linking with UCRT. That's because the Mingw-w64
linker adds a _set_invalid_parameter_handler call at startup that
overrides the default UCRT behavior. However, other toolchains, like
MSVC and LLVM, doesn't override the default behavior.
Overriding the default behavior is out of the scope for this test, so
the test is skipped instead.
Fixes#62887
Change-Id: I60f140faf0eda80a2de4e10876be25e0dbe442d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/705455
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Add "parseDurationError" to reduce memory allocation in the error path of
"ParseDuration" and delay the generation of error messages. This improves
the performance when dealing with invalid input.
The format of the error message remains unchanged.
Benchmarks:
│ old │ new │
│ sec/op │ sec/op vs base │
ParseDurationError-10 132.10n ± 4% 45.93n ± 2% -65.23% (p=0.000 n=10)
│ old │ new │
│ B/op │ B/op vs base │
ParseDurationError-10 192.00 ± 0% 64.00 ± 0% -66.67% (p=0.000 n=10)
│ old │ new │
│ allocs/op │ allocs/op vs base │
ParseDurationError-10 6.000 ± 0% 2.000 ± 0% -66.67% (p=0.000 n=10)
Fixes#75521
Change-Id: I0dc9f28c9601b6be07b70d0a98613757d76e2c97
GitHub-Last-Rev: 737273936a
GitHub-Pull-Request: golang/go#75531
Reviewed-on: https://go-review.googlesource.com/c/go/+/705195
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Auto-Submit: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently, for a write of a pointer (e.g. *p = x where x is a
pointer), we generate an explicit nil check of p, despite that the
store instruction may have the same faulting behavior as the nil
check. This is because the write needs a write barrier, which
creates a control flow, which prevents the nil check being removed
as it is in a differnt block as the actual store.
This CL duplicates the nil check to two branches, so it is likely
that they will be followed by the actual store and the write
barrier load, which may have the same faulting behavior, so they
can be removed.
Change-Id: Ied9480de5dd6a8fcbd5affc5f6e029944943cc07
Reviewed-on: https://go-review.googlesource.com/c/go/+/705156
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>
Loading and calling testHookCanceledDial in the function passed to
context.AfterFunc is racey, because the function runs in a separate
goroutine, and is not synchronized with the test code that restores
the original testHookCanceledDial value.
We could add a channel and wait for the "AfterFunc" to return in
the deferred function, but that's a lot of synchronization overhead
just for a bit of test code. Instead we simply load
testHookCanceledDial into a local variable synchronously. This fixes
the race without introducing any overhead.
Fixes#75474
Change-Id: If8fbd0f5f65375577c2ded64a13a15b406c45ecc
Reviewed-on: https://go-review.googlesource.com/c/go/+/704455
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Remove a race condition in counting the number of connections per host,
which can cause a connCount underflow and a panic.
The race occurs when:
- A RoundTrip call attempts to use a HTTP/2 roundtripper (pconn.alt != nil)
and receives an isNoCachedConn error. The call removes the pconn from
the idle conn pool and decrements the connCount for its host.
- A second RoundTrip call on the same pconn succeeds,
and delivers the pconn to a third RoundTrip waiting for a conn.
- The third RoundTrip receives the pconn at the same moment its request
context is canceled. It places the pconn back into the idle conn pool.
At this time, the connCount is incorrect, because the conn returned to
the idle pool is not matched by an increment in the connCount.
Fix this by not adding HTTP/2 pconns back to the idle pool in
wantConn.cancel.
Fixes#61474
Change-Id: I104d6cf85a54d0382eebf3fcf5dda99c69a7c3f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/703936
Auto-Submit: Damien Neil <dneil@google.com>
Reviewed-by: Nicholas Husin <husin@google.com>
Reviewed-by: Nicholas Husin <nsh@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The Context.Err documentation states that it returns nil if the
context's done channel is not closed. Fix a race condition introduced
by CL 653795 where Err could return a non-nil error slightly before
the Done channel is closed.
No impact on Err performance when returning nil.
Slows down Err when returning non-nil by about 3x,
but that's still almost 2x faster than before CL 653795
and the performance of this path is less important.
(A tight loop checking Err for doneness will be terminated
by the first Err call to return a non-nil result.)
goos: darwin
goarch: arm64
pkg: context
cpu: Apple M4 Pro
│ /tmp/bench.0 │ /tmp/bench.1 │
│ sec/op │ sec/op vs base │
ErrOK-14 1.806n ± 1% 1.774n ± 0% -1.77% (p=0.000 n=8)
ErrCanceled-14 1.821n ± 1% 7.525n ± 3% +313.23% (p=0.000 n=8)
geomean 1.813n 3.654n +101.47%
Fixes#75533
Change-Id: Iea22781a199ace7e7f70cf65168c36e090cd2e2a
Reviewed-on: https://go-review.googlesource.com/c/go/+/705235
TryBot-Bypass: Damien Neil <dneil@google.com>
Reviewed-by: Nicholas Husin <husin@google.com>
Reviewed-by: Nicholas Husin <nsh@golang.org>
Auto-Submit: Damien Neil <dneil@google.com>
This is another case very similar to CL 684015 and #74375.
In spans with type headers, mallocgc always writes to the page before
returning the allocated memory. This initial write is done by
runtime.heapSetTypeSmallHeader. Prior to the write, the compiler inserts
a nil check, implemented as a dummy instruction reading from memory.
On a freshly mapped page, this read triggers a page fault, mapping the
zero page read-only. Immediately afterwards, the write triggers another
page fault, copying to a writeable page and performing a TLB flush.
This problem is exacerbated as the process scales up. At GOMAXPROCS=6,
the tile38 sweet benchmark spends around 0.1% of cycles directly
handling these page faults. On the same machine at GOMAXPROCS=192, it
spends about 2.7% of cycles directly handling these page faults.
Replacing the read with an explicit nil check reduces the direct cost of
these page faults down to around 0.1% at GOMAXPROCS=192. There are
additional positive side-effects due to reduced contention, so the
overall time spent in page faults drops from around 12.8% to 6.8%. Most
of the remaining time in page faults is spent on automatic NUMA page
migration (completely unrelated to this issue).
Impact on the tile38 benchmark results:
│ baseline │ cl704755 │
│ sec/op │ sec/op vs base │
Tile38QueryLoad-192 1.638m ± 3% 1.494m ± 5% -8.79% (p=0.002 n=6)
│ baseline │ cl704755 │
│ average-RSS-bytes │ average-RSS-bytes vs base │
Tile38QueryLoad-192 5.384Gi ± 3% 5.399Gi ± 3% ~ (p=0.818 n=6)
│ baseline │ cl704755 │
│ peak-RSS-bytes │ peak-RSS-bytes vs base │
Tile38QueryLoad-192 5.818Gi ± 1% 5.864Gi ± 2% ~ (p=0.394 n=6)
│ baseline │ cl704755 │
│ peak-VM-bytes │ peak-VM-bytes vs base │
Tile38QueryLoad-192 7.121Gi ± 1% 7.180Gi ± 2% ~ (p=0.818 n=6)
│ baseline │ cl704755 │
│ p50-latency-sec │ p50-latency-sec vs base │
Tile38QueryLoad-192 343.2µ ± 1% 313.2µ ± 3% -8.73% (p=0.002 n=6)
│ baseline │ cl704755 │
│ p90-latency-sec │ p90-latency-sec vs base │
Tile38QueryLoad-192 1.662m ± 2% 1.603m ± 5% ~ (p=0.093 n=6)
│ baseline │ cl704755 │
│ p99-latency-sec │ p99-latency-sec vs base │
Tile38QueryLoad-192 41.56m ± 8% 35.26m ± 18% -15.17% (p=0.026 n=6)
│ baseline │ cl704755 │
│ ops/s │ ops/s vs base │
Tile38QueryLoad-192 87.89k ± 3% 96.36k ± 4% +9.64% (p=0.002 n=6)
Updates #74375.
Change-Id: I6a6a636c1a16261b6d5076f2e1b08524a6544d33
Reviewed-on: https://go-review.googlesource.com/c/go/+/704755
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
We cannot easily determine the base address of the arena we added the
random padding pages to, which can cause confusing
TestScavengedBitsCleared failures when the arena we padded does not have
the lowest address of all of the arenas.
Instead of attempting to determine the correct arena to ignore when
checking the scav and alloc bits, switch to just tolerating _one_ arena
having mismatches, which is expected when randomizedHeapBase64 is
enabled. Any other number of arenas having mismatches is likely a real
error.
Fixes#75502
Change-Id: Iacc445b2905824f9f71970c7abd33f187793cf39
Reviewed-on: https://go-review.googlesource.com/c/go/+/704855
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
CL 155597 added a test to check EvalSymlinks returns ENOTDIR
for existing path which ends with a slash.
CL 404954 added a separate evalSymlinks implementation for plan9,
which has a kludge to ensure the ENOTDIR is returned in the above case.
Apparently the added kludge is not working now (and maybe never worked),
as seen in [1]:
=== RUN TestIssue29372
path_test.go:1730: test#0: want "not a directory", got "stat /tmp/TestIssue293724085649913/001/file.txt/: not a directory: '/tmp/TestIssue293724085649913/001/file.txt/'"
--- FAIL: TestIssue29372 (0.00s)
This happens because on plan9 errors are strings and they contain the
file name after the error text, and the check assumes the "not a
directory" text is at the end of the message.
The fix is to check whether the error is somewhere in the error text,
not ends with it (as it is done in other plan9 code, for example, see
checkErrMessageContent added in CL 163058).
This should fix the above test failure.
PS perhaps the kludge should be moved up the call chain to os.Stat/Lstat?
[1]: https://ci.chromium.org/ui/p/golang/builders/try/gotip-plan9-amd64/b8704772617873749345/test-results?q=ExactID%3Apath%2Ffilepath.TestIssue29372+VHash%3Aa63f5798e9f8f502
Change-Id: I6afb68be5f65a28929b2f717247ab34ff3b4a812
Reviewed-on: https://go-review.googlesource.com/c/go/+/700775
Auto-Submit: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Richard Miller <millerresearch@gmail.com>
TryBot-Bypass: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
I was wondering whether is is expected that both p.lineComment
and p.leadComment might be populated at the same time.
i.e. whether parser.go:275 can be changed from:
if p.lineFor(p.pos) != endline || p.tok == token.SEMICOLON || p.tok == token.EOF
to:
if (p.tok != token.COMMENT && p.lineFor(p.pos) != endline) || p.tok == token.SEMICOLON || p.tok == token.EOF
It turns out that we cannot do so. So while i am here, add a test
case for that, since nothing else failed with that change.
Change-Id: I6a6a6964f760237c068098db8a7b4b7aaf26c651
Reviewed-on: https://go-review.googlesource.com/c/go/+/703915
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
The code for mapping Windows PE relocations to Go relocations was
difficult to follow and contains some duplicated code. Also, it was
mapping IMAGE_REL_AMD64_ADDR32 to R_PCREL instead of R_ADDR.
This CL commit simplifies the code and fixes the mapping. I haven't been
able to coerce mingw-w64 to generate IMAGE_REL_AMD64_ADDR32 relocations,
so I haven't been able to test this change. However, the previous
implementation was clearly wrong.
While here, remove code supporting the unsupported windows/arm support.
Updates #71671
Updates #75485
Change-Id: Id0d6f352fa7d5df9e00509fcdf09ca0cb91ca524
Reviewed-on: https://go-review.googlesource.com/c/go/+/672155
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Translate moves from an integer register to a floating point register, or
from a floating point register to an integer register, to the appropriate
move instruction (i.e. FMVXW/FMVWX/FMVXD/FMVDX).
Add support for MOVF with a constant - we previously added support for MOVD
but not for MOVF. Add special handling for 0.0, which we can translate to
a move from the zero register to a floating point register (leveraging the
above mentioned change).
Change-Id: If8df2f5610e69b4ec0af85efb884951024685f5b
Reviewed-on: https://go-review.googlesource.com/c/go/+/703216
Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com>
Reviewed-by: Mark Freeman <markfreeman@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Mark Ryan <markdryan@rivosinc.com>
Currently, when shuffling registers, if we need to spill a
register, we always create a spill slot of type int64. The type
doesn't actually matter, as long as it is wide enough to hold the
registers. This is no longer true with SIMD registers, which could
be wider than a int64. Create the slot with the proper type
instead.
Change-Id: I85c82e2532001bfdefe98c9446f2dd18583d49b4
Reviewed-on: https://go-review.googlesource.com/c/go/+/704055
TryBot-Bypass: Cherry Mui <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
There are a few places in the code which checks that the running kernel
is greater than or equal to x.y. The check takes a few lines and the
checking code is somewhat distracting.
Let's abstract this check into a simple function, KernelVersionGE,
and convert the users accordingly.
Add a test case (I'm not sure it has much value, can be dropped).
Change-Id: I8ec91dcc7452363361f95e46794701c0ae57d956
Reviewed-on: https://go-review.googlesource.com/c/go/+/700796
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Mark Freeman <markfreeman@google.com>
The darwin port provides different syscall functions that only
differ on how they handle the errors, and they are all written
in assembly.
This duplication can be removed by factoring out the error handling
logic to arch-agnostic Go code and leaving the assembly functions
with the only reponsibility of making the syscall and mapping
parameters between ABIs.
Updates #51087
Cq-Include-Trybots: luci.golang.try:gotip-darwin-arm64-longtest,gotip-darwin-amd64-longtest
Change-Id: I9524377f3ef9c9a638412c7e87c8f46a33ee3453
Reviewed-on: https://go-review.googlesource.com/c/go/+/699135
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Mark Freeman <markfreeman@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The go command connects both the stdout and stderr files of
its child commands (cmd/compile, cmd/vet, etc) to the go
command's own stderr. If the child command is supposed to
produce structure output on stderr, as is the case for
go vet -json or go fix -diff, it will be merged with the
error stream, making it useless.
This change to the go vet <-> unitchecker protocol specifies
the name of a file into which the vet tool should write its
stdout. On success, the go command will then copy the entire
content of that file to its own stdout, under a lock.
This ensures that partial writes to stdout in case of failure,
concurrent writes to stdout by parallel vet tasks, or other
junk on stderr, cannot interfere with the integrity of the
go command's structure output on stdout.
CL 702835 is the corresponding change on the x/tools side.
For #75432
Change-Id: Ib4db25b6b0095d359152d7543bd9bf692551bbfa
Reviewed-on: https://go-review.googlesource.com/c/go/+/702815
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@google.com>
Auto-Submit: Alan Donovan <adonovan@google.com>
Previous CLs optimized direct use of abi.Type, but reflect.Type is
indirected, so was not benefiting.
For TypeFor, we can use toRType directly without a nil check because the
types are statically known.
Normally, I'd think SSA would remove the nil check, but due to some
oddity (specifically, late fuse being required to remove the nil check,
but opt doesn't run that late) means that the nil check persists and
gets in the way.
Manually writing the code in this instance seems to fix the problem.
It also exposed another problem; depending on the ordering, writeType
could get to a type symbol before SSA, thereby preventing Extra from
being created on the symbol for later lookups that don't go through
TypeLinksym directly. In writeType, for non-shape types, call
TypeLinksym to ensure that the type is set up for later callers. That
change itself passed toolstash -cmp.
All up, this stack put through compilecmp shows a lot of improvement in
various reflect-using packages, and reflect itself. It is too big to fit
in the commit message but here's some info:
compilecmp master -> HEAD
master (d767064170): cmd/compile: mark abi.PtrType.Elem sym as used
HEAD (846a94c568): cmd/compile, reflect: further allow inlining of TypeFor
file before after Δ %
addr2line 3735911 3735391 -520 -0.014%
asm 6382235 6382091 -144 -0.002%
buildid 3608568 3608360 -208 -0.006%
cgo 5951816 5951480 -336 -0.006%
compile 28362080 28339772 -22308 -0.079%
cover 6668686 6661414 -7272 -0.109%
dist 4311961 4311425 -536 -0.012%
fix 3771706 3771474 -232 -0.006%
link 8686073 8684993 -1080 -0.012%
nm 3715923 3715459 -464 -0.012%
objdump 6074366 6073774 -592 -0.010%
pack 3025653 3025277 -376 -0.012%
pprof 18269485 18261653 -7832 -0.043%
test2json 3442726 3438390 -4336 -0.126%
trace 16984831 16981767 -3064 -0.018%
vet 10701931 10696355 -5576 -0.052%
total 133693951 133639075 -54876 -0.041%
runtime
runtime.stkobjinit 240 -> 165 (-31.25%)
runtime [cmd/compile]
runtime.stkobjinit 240 -> 165 (-31.25%)
reflect
reflect.Value.Seq2.func3 309 -> 245 (-20.71%)
reflect.Value.Seq2.func1.1 281 -> 198 (-29.54%)
reflect.Value.Seq.func1.1 242 -> 165 (-31.82%)
reflect.Value.Seq2.func2 360 -> 285 (-20.83%)
reflect.Value.Seq.func4 281 -> 239 (-14.95%)
reflect.Value.Seq2.func4 399 -> 284 (-28.82%)
reflect.Value.Seq.func2 271 -> 230 (-15.13%)
reflect.TypeFor[go.shape.uint64] 33 -> 18 (-45.45%)
reflect.Value.Seq.func3 219 -> 178 (-18.72%)
reflect [cmd/compile]
reflect.Value.Seq2.func2 360 -> 285 (-20.83%)
reflect.Value.Seq.func4 281 -> 239 (-14.95%)
reflect.Value.Seq.func2 271 -> 230 (-15.13%)
reflect.Value.Seq.func1.1 242 -> 165 (-31.82%)
reflect.Value.Seq2.func1.1 281 -> 198 (-29.54%)
reflect.Value.Seq2.func3 309 -> 245 (-20.71%)
reflect.Value.Seq.func3 219 -> 178 (-18.72%)
reflect.TypeFor[go.shape.uint64] 33 -> 18 (-45.45%)
reflect.Value.Seq2.func4 399 -> 284 (-28.82%)
fmt
fmt.(*pp).fmtBytes 1723 -> 1691 (-1.86%)
database/sql/driver
reflect.TypeFor[go.shape.interface 33 -> 18 (-45.45%)
database/sql/driver.init 72 -> 57 (-20.83%)
Change-Id: I9eb750cf0b7ebf532589f939431feb0a899e42ff
Reviewed-on: https://go-review.googlesource.com/c/go/+/701301
Reviewed-by: Mark Freeman <markfreeman@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The aarch64 ABI says that only the first 8 arguments should be
passed as registers, subsequent arguments should be put on
the stack.
Syscall9 is not putting the 9th argument on the stack, and it should.
The standard library hasn't hit this issue because it uses Syscall9
for functions that only require 7 or 8 parameters.
Change-Id: I1fafca5b16f977ea856e3f08b4ff3d0a2a7a4dfe
Reviewed-on: https://go-review.googlesource.com/c/go/+/702297
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently on Windows, for cgo, we support MinGW-based C toolchain,
that is, with a -windows-gnu target. This CL makes it work with
clang with a -windows-msvc target. The LLVM toolchain bundled in
MSVC (https://learn.microsoft.com/en-us/cpp/build/clang-support-msbuild)
is such an example.
Currently it is expecting lld-link as the C linker, which is also
bundled in MSVC, can be requested with -fuse-ld=lld, but is not
the default.
This is the first step, which makes it generate a working cgo
binary. There are still more work to do, e.g. there are some
linker warnings, and the binary doesn't have symbol table.
all.bat doesn't pass with this setting.
Change-Id: I54d33f7dd5f5eeeafa0735cd52f4127fe4865636
Reviewed-on: https://go-review.googlesource.com/c/go/+/703055
Reviewed-by: Than McIntosh <thanm@golang.org>
Reviewed-by: Florian Zenker <floriank@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Support is added for the generic RISC-V CSR operations; CSRRC, CSRRCI,
CSRRS, CSRRSI, CSRRW, CSRRWI. These instructions require special
handling as their second operand is a symbolic CSR register name and
not an immediate value or a register. CSR names are implemented as
special operands.
RISC-V CSRs are not currently saved and restored when a go routine is
asynchronously pre-empted so it is only safe to use these instructions
in hand written assembler. Note that CSRRS was already partially
supported by the assembler so this restriction predates this commit.
We mention it here as this commit makes CSRRS much easier to use.
Change-Id: I9ff8d804328b418a879d463e7d9cc31f489c7a00
Reviewed-on: https://go-review.googlesource.com/c/go/+/630519
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Reviewed-by: Joel Sing <joel@sing.id.au>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
This change splits package builds further into even more actions.
Between the cache action (and cover action, if present) and the actual
build action we insert three layers of actions:
Check Cache Action
| |
| V
| Run Cover Action (if cover requested)
| |
| V
New Layer 1 | Run Cgo Action (if package is built with cgo)
| | | | (multiple arrows representing fan-out to
| V V V multiple actions)
New Layer 2 | gcc Compile Action for each C/C++/S/F/M file (if cgo)
| |/ (arrow represeting fan-in to single action)
| V
New Layer 3 | Cgo collect action (if cgo)
| |
\ V
Build action
The first run cgo action takes the input source files and runs cgo on
them to produce the cgo-processed go files, which are given to the
compiler, and to produce additional C files to compile and headers to
use in the following compilations. The action also takes care of running
SWIG before running cgo if there are swig files. This will produce
additional cgo sources that are inputs to cgo.
The run cgo action action fans out to multiple actions to do each of the
C/C++/Obj-C/assembly/Fortran compilations for the non-Go files in the
package, as well as those produced as outputs by the cgo command
invocation.
These actions then join into a single noop "collect" action which
primarily exists so that we don't pollute the build action's
dependencies with a bunch of non-go compile actions. (The build action
expects its dependencies to mostly be other build actions).
All of this work in the new actions was previously being done in the
build action itself. There's still a remnant of the original cgo logic
left in the build action to run the cgo command with -dynimport to
produce a go file to be built with the rest of the package, and do some
checks.
Most of this CL consists of moving code around. Just like the previous
CL breaking out the coverage logic into a separate action, we don't
cache the outputs of the cgo actions, and just treat all the actions
used to build a single package as one cacheable unit. This makes things
a bit simpler. If we decide in a future CL to cache the outputs
separately, we could remove the dependency on the cover action on the
check cache action (which in turn depends on all the package's
dependencies) and could start non-go compilation pretty much as early as
we want in the build.
The 'cgoAction' function in action.go takes care of creating the layers
of cgo action dependencies, which are inserted as dependencies of the
build action. It's mostly straightforward, except for the fact that we
need to tell each non-go compile action which non-go file to compile, so
we need to compute the names of the generated files. (Alternatively we
could give each action a number and have it build the nth file produced
by the run cgo action, but that seems even more complicated). The actors
produced to run the action logic are pretty light wrappers around the
execution logic in exec.go.
In the 'build' function in exec.go, most of the new code mainly checks
for the information from the cgo actions to use instead of running it,
and then passes it to the processCgoOutputs function. The only other
weird thing in the build functian is that we we call the logic to
compute the nonGoOverlay separately just for the C files that are being
built with gccgo. We compute the overlay for the non-go files used in a
cgo build in the run cgo action.
The 'cgo' function that previously ran the cgo logic for the build has
now been split into three: the first half, which runs cgo is now in the
runCgo function, the center part, which compiles the non-go files is now
partly in creating the invididual non-go compile actions, as well as the
cgoCompileActor's Act function. And the final part, which runs
cgo -dynimport is now in processCgoOutputs. These parts communicate with
each other through the providers that are set on the cgo actions.
One further improvement we can make to this change in the future is to
compile the dynimport file separately from the build action: its output
is only needed by the linker. This would remove any dependencies from
dependent packages' build actions on the cgo compile actions, allowing
more flexibility for scheduling actions.
Fixes#9887
Change-Id: Ie3c70bbf985148ba73094cddfc78c39dc6faad6e
Reviewed-on: https://go-review.googlesource.com/c/go/+/694475
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@google.com>
There's a cap of 1 billion benchmark iterations because more than that
is usually not going to give more useful data. Unfortunately, the
existing implementation neglected to check whether the 1e9 cap had
already been exceeded when it adjusted the number of iterations in the
B.Loop slow path (stopOrScaleBLoop), since it's only when that cap is hit
that it needed to terminate early.
As a result, for _very_ cheap benchmarks (e.g. testing assembly
implementations with just a few instructions), the B.Loop would stop
incrementing the number of iterations, but wouldn't terminate early,
making it re-enter the slow-path _every_ iteration until the benchmark
time was exhausted.
This wasn't normally visible with the default -benchtime 2s, but when
raised to 5s, it would cause benchmarks that took <5ns/op to be reported
as exactly 5ns/op. (which looks a bit suspicious)
Notably, one can use -count for larger groupings to compute statistics.
golang.org/x/perf/cmd/benchstat is valuable for coalescing larger
run-counts from -count into more useful statistics.
Add a test which allows for fewer iterations on slow/contended
platforms but guards against reintroducing a bug of this nature.
Fixes#75210
Change-Id: Ie7f0b2e6c737b064448434f3ed565bfef8c4f020
Reviewed-on: https://go-review.googlesource.com/c/go/+/700275
Reviewed-by: Junyang Shao <shaojunyang@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Sean Liao <sean@liao.dev>
Auto-Submit: Sean Liao <sean@liao.dev>
Merge List:
+ 2025-09-11 cf5e993177 cmd/link: allow one to specify the data section in the internal linker
+ 2025-09-11 cdb3d467fa encoding/gob: make use of reflect.TypeAssert
+ 2025-09-11 fef360964c archive/tar: fix typo in benchmark name
+ 2025-09-11 7d562b8460 syscall: actually remove unreachable code
+ 2025-09-11 c349582344 crypto/rsa: don't test CL 687836 against v1.0.0 FIPS 140-3 module
+ 2025-09-11 253dd08f5d debug/macho: filter non-external symbols when reading imported symbols without LC_DYSYMTAB
+ 2025-09-10 2009e6c596 internal/runtime/maps: remove redundant package docs
+ 2025-09-10 de5d7eccb9 runtime/internal/maps: only conditionally clear groups when sparse
+ 2025-09-10 8098b99547 internal/runtime/maps: speed up Clear
+ 2025-09-10 fe5420b054 cmd: delete some more windows/arm remnants
+ 2025-09-10 fad1dc608d runtime: don't artificially limit TestReadMetricsSched
+ 2025-09-10 b1f3e38e41 cmd/compile: when CSEing two values, prefer the statement marked one
+ 2025-09-10 00824f5ff5 types2: better documentation for resolve()
+ 2025-09-10 5cf8ca42e3 internal/trace/raw: use strings.Cut instead of strings.SplitN 2
+ 2025-09-10 80a2aae922 Revert "cmd/compile: improve stp merging for non-sequent cases"
+ 2025-09-10 f327a05419 go/token, syscall: annotate if blocks that defeat vet's unreachable pass
+ 2025-09-10 9650c97d0f syscall: remove unreachable code
+ 2025-09-10 f1c4b860d4 Revert "crypto/internal/fips140: update frozen module version to "v1.0.0""
+ 2025-09-10 30686c4cc8 encoding/json/v2: document context annotation with SemanticError
+ 2025-09-09 c5737dc21b runtime: when using cgo on 386, call C sigaction function
+ 2025-09-09 b9a4a09b0f runtime: remove duff support for riscv64
+ 2025-09-09 4dac9e093f cmd/compile: use generated loops instead of DUFFCOPY on riscv64
+ 2025-09-09 879ff736d3 cmd/compile: use generated loops instead of DUFFZERO on riscv64
+ 2025-09-09 77643dc63f cmd/compile: simplify zerorange on riscv64
+ 2025-09-09 e6605a1bcc encoding/json: use reflect.TypeAssert
+ 2025-09-09 4c20f7f15a cmd/cgo: run gcc to get errors and debug info in parallel
+ 2025-09-09 5dcedd6550 runtime: lock mheap_.speciallock when allocating synctest specials
+ 2025-09-09 d3be949ada runtime: don't negate eventfd errno
+ 2025-09-09 836fa74518 syscall: optimise cgo clearenv
+ 2025-09-09 ce39174482 crypto/rsa: check PrivateKey.D for consistency with Dp and Dq
+ 2025-09-09 5d9d0513dc crypto/rsa: check for post-Precompute changes in Validate
+ 2025-09-09 968a5107a9 crypto/internal/fips140: update frozen module version to "v1.0.0"
+ 2025-09-09 645ee44492 crypto/ecdsa: deprecate direct use of big.Int fields in keys
+ 2025-09-09 a67977da5e cmd/compile/internal/inline: ignore superfluous slicing
+ 2025-09-09 a5fa5ea51c cmd/compile/internal/ssa: expand runtime.memequal for length {3,5,6,7}
+ 2025-09-09 4c63d798cb cmd/compile: improve stp merging for non-sequent cases
+ 2025-09-09 bdd51e7855 cmd/compile: use constant zero register instead of specialized zero instructions on mips64x
+ 2025-09-09 10ac80de77 cmd/compile: introduce CCMP generation
+ 2025-09-09 3b3b16957c Revert "cmd/go: use os.Rename to move files on Windows"
+ 2025-09-09 e3223518b8 cmd/go: split generating cover files into its own action
+ 2025-09-09 af03343f93 cmd/compile: fix bounds check report
+ 2025-09-08 6447ff409a cmd/compile: fold constant in ADDshift op on loong64
+ 2025-09-08 5b218461f9 cmd/compile: optimize loads from abi.Type.{Size_,PtrBytes,Kind_}
+ 2025-09-08 b915e14490 cmd/compile: consolidate logic for rewriting fixed loads
+ 2025-09-08 06e791c0cd cmd/compile: simplify zerorange on mips
+ 2025-09-08 cf42b785b7 cmd/cgo: run recordTypes for each of the debugs at the end of Translate
+ 2025-09-08 5e6296f3f8 archive/tar: optimize nanosecond parsing in parsePAXTime
+ 2025-09-08 ea00650784 debug/pe: permit symbols with no name
+ 2025-09-08 4cc7cc74c3 crypto: update Hash comments to point to crypto/sha3
+ 2025-09-08 ff45d5d53c encoding/json/internal/jsonflags: fix comment with wrong field name
+ 2025-09-06 861c90c907 net/http: pool transport gzip readers
+ 2025-09-06 57769b5532 os: reject OpenDir of a non-directory file in Plan 9
+ 2025-09-06 a6144613d3 crypto/tls: use context.AfterFunc in handshakeContext
+ 2025-09-05 e8126bce9e runtime/cgo: save and restore R31 for crosscall1 on loong64
+ 2025-09-05 d767064170 cmd/compile: mark abi.PtrType.Elem sym as used
+ 2025-09-05 0b1eed09a3 vendor/golang.org/x/tools: update to a09a2fb
+ 2025-09-05 f5b20689e9 cmd/compile: optimize loads from readonly globals into constants on loong64
+ 2025-09-05 3492e4262b cmd/compile: simplify specific addition operations using the ADDV16 instruction
+ 2025-09-05 459b85ccaa cmd/fix: remove all functionality except for buildtag
+ 2025-09-05 87e72769fa runtime: simplify openbsd check in usesLibcall and mStackIsSystemAllocated
+ 2025-09-05 bb48272e24 cmd/compile: simplify zerorange on mips64
+ 2025-09-05 d52a56cce1 cmd/link/internal/ld: unconditionally use posix_fallocate on FreeBSD
+ 2025-09-04 9d0829963c net/http: fix cookie value of "" being interpreted as empty string.
+ 2025-09-04 ddce0522be cmd/internal/obj/loong64: add ADDU16I.D instruction support
+ 2025-09-04 00b8474e47 cmd/trace: don't filter events for profile by whether they have stack
+ 2025-09-04 e36c5aead6 log/slog: add multiple handlers support for logger
+ 2025-09-04 150fae714e crypto/x509: don't force system roots load in SetFallbackRoots
+ 2025-09-04 4f7bbc62c7 runtime, cmd/compile, cmd/internal/obj: remove duff support for loong64
+ 2025-09-04 b8cc907425 cmd/internal/obj/loong64: fix the usage of offset in the instructions [X]VLDREPL.{B/H/W/D}
+ 2025-09-04 8c27a80890 path{,/filepath}: speed up Match
+ 2025-09-04 b7c20413c5 runtime: remove obsolete osArchInit function
+ 2025-09-04 df29038486 cmd/compile/internal/ssa: load constant values from abi.PtrType.Elem
+ 2025-09-04 4373754bc9 cmd/compile: add store to load forwarding rules on riscv64
+ 2025-09-03 80038586ed cmd/compile: export to DWARF types only referenced through interfaces
+ 2025-09-03 91e76a513b cmd/compile: use generated loops instead of DUFFCOPY on loong64
+ 2025-09-03 c552ad913f cmd/compile: simplify memory load and store operations on loong64
+ 2025-09-03 e8f9127d1f net/netip: export Prefix.Compare, fix ordering
+ 2025-09-03 731e546166 cmd/compile: simplify the support for 32bit high multiply on loong64
Change-Id: I2c124fb8071e2972d39804867cafb6806e601aba
This CL adds the machine ops for memory-op and also their prog writing
logic.
This CL also fixes a bug in the XED parser. Previously the
merge of machine ops is not checking the CPU feature, so some AVX
instruction might have their "memFeatures" field set incorrectly.
However since that field is not used until this CL, putting the fix here
should be ok.
Change-Id: I91031cbbf63453257473dd1d2ff47f7496d1a01d
Reviewed-on: https://go-review.googlesource.com/c/go/+/701198
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
File.ImportedSymbols will return symbols with a type that has one of the
N_STAB (0xe0) bits set and no section. That's not the expected behavior,
as those symbols might not be external.
We should expand the type check to also account for the N_EXT bit.
The section check is not necessary, as N_EXT symbols never have it set.
I have found this issue in the wild by running "go tool cgo -dynimport",
but unfortuantely I couldn't get a minimal C code that generates
N_STAB symbols without section, so this CL doesn't add any new test.
Change-Id: Ib0093ff66b50c7cc2f39d83936314fc293236917
Reviewed-on: https://go-review.googlesource.com/c/go/+/702296
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>
We only want to do the work of clearing slots
if they are full. But we also don't want to do too
much work to figure out whether a slot is full or not,
especially if clearing a slot is cheap.
1) We decide group-by-group instead of slot-by-slot.
If any slot in a group is full, we zero the whole group.
2) If groups are unlikely to be empty, don't bother
testing for it.
3) If groups are 50%/50% likely to be empty, also don't
bother testing, as it confuses the branch predictor. See #75097.
4) But if a group is really large, do the test anyway, as
clearing is expensive.
Fixes#75097
Change-Id: I9191865dd3e0fe887751cffe6082ac27d8d8439c
Reviewed-on: https://go-review.googlesource.com/c/go/+/697876
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@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Youlin Feng <fengyoulin@live.com>
Reported by go vet:
$ go vet syscall
# syscall_test
# [syscall_test]
syscall/env_unix_test.go:100:4: unreachable code
The TestVetStdlib test in golang.org/x/tools/go/analysis/unitchecker
also ran into this.
Fixes#73998.
Change-Id: I7f2842a42835a38163433a09a3311be9c30f8a14
Cq-Include-Trybots: luci.golang.try:x_tools-gotip-linux-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/702415
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
TryBot-Bypass: Dmitri Shuralyov <dmitshur@golang.org>
On 386 the C sigaction function assumes that the caller does not set
the SA_RESTORER flag. It does not copy the C sa_restorer field to
the kernel sa_restorer field. The effect is that the kernel sees
the SA_RESTORER flag but a NULL sa_restorer field, and the program
crashes when returning from a signal handler.
On the other hand, the C sigaction function will return the SA_RESTORER
flag and the sa_restorer field stored in the kernel.
This means that if the Go runtime installs a signal handler,
with SA_RESTORER as is required when calling the kernel,
and the Go program calls C code that calls the C sigaction function
to query the current signal handler, that C code will get a result
that it can't pass back to sigaction.
This CL fixes the problem by using the C sigaction function
for 386 programs that use cgo. This reuses the functionality
used on amd64 and other GOARCHs to support the race detector.
See #75253, or runtime/testdata/testprogcgo/eintr.go, for sample
code that used to fail on 386. No new test case is required,
we just remove the skip we used to have for eintr.go.
Fixes#75253
Change-Id: I803059b1fb9e09e9fbb43f68eccb6a59a92c2991
Reviewed-on: https://go-review.googlesource.com/c/go/+/701375
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
This change kicks off the work to load the debug info when processing
each file, and then waits for all the files to be processed before
starting the single-goroutined part that processes them. The processing
is very order dependent so we won't try to make it concurrent. Though
in a later CL we can wait for only the relevant package to have been
processed concurrently before doing the single-goroutined processing for
it instead of waiting for all packages to be processed concurrently
before the single goroutine section.
We use a par.Queue to make sure we're not running too many gcc compiles
at the same time. The change to cmd/dist makes the par package available
to cgo.
Fixes#75167
Change-Id: I6a6a6964fb7f3a3684118b5ee66f1ad856b3ee59
Reviewed-on: https://go-review.googlesource.com/c/go/+/699020
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
For programs with very large environments, calling unsetenv(3) for each
environment variable can be very expensive because of CGo overhead, but
clearenv(3) is much faster. The only thing we have to track is whether
GODEBUG is being unset by the operation, which can be done very quickly
without resorting to doing unsetenv(3) for every variable.
This change makes syscall.Clearenv() >98% faster when run in an
environment with as little as 100 environment variables. (Note that due
to golang/go#27217, it is necessary to modify BenchmarkClearenv to use
t.StopTimer() and -benchtime=100x in order to get these benchmark times
-- otherwise syscall.Setenv() time is included and the benchmarks give a
more pessimistic 50% performance improvement.)
goos: linux
goarch: amd64
pkg: syscall
cpu: AMD Ryzen 7 7840U w/ Radeon 780M Graphics
│ before │ after │
│ sec/op │ sec/op vs base │
Clearenv/100-16 22276.5n ± 5% 285.8n ± 3% -98.72% (p=0.000 n=10)
Clearenv/1000-16 1414104.0n ± 1% 783.1n ± 8% -99.94% (p=0.000 n=10)
Clearenv/10000-16 143827.554µ ± 1% 7.591µ ± 5% -99.99% (p=0.000 n=10)
geomean 1.655m 1.193µ -99.93%
The above benchmarks are CGo builds, which require CGo overhead for
every setenv(2). If you run the same benchmarks for a non-CGo package
(i.e., outside of the "syscall" package), you get slightly more modest
performance improvements:
goos: linux
goarch: amd64
pkg: clearenv_nocgo
cpu: AMD Ryzen 7 7840U w/ Radeon 780M Graphics
│ before │ after │
│ sec/op │ sec/op vs base │
Clearenv/100-16 1106.0n ± 3% 230.7n ± 8% -79.14% (p=0.000 n=10)
Clearenv/1000-16 11222.0n ± 1% 305.4n ± 6% -97.28% (p=0.000 n=10)
Clearenv/10000-16 195676.5n ± 6% 759.9n ± 10% -99.61% (p=0.000 n=10)
geomean 13.44µ 376.9n -97.20%
(As above, this requires modifying the benchmarks to use t.StopTimer()
and -benchtime=100x.)
Change-Id: I53b96a75f189e91affbde423c907888b7e0fafcd
GitHub-Last-Rev: f8d7a8140d
GitHub-Pull-Request: golang/go#70672
Reviewed-on: https://go-review.googlesource.com/c/go/+/633515
Reviewed-by: Mark Freeman <markfreeman@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Kirill Kolyshkin <kolyshkin@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
This change breaks up the build action into multiple actions: a first
action checks to see what's cached and determines what the following
actions need to do. Then the optional cover action will generate cover
instrumented files if this is a cover build. Finally the build action
does the rest of this work. For simplicity of implementation, the new
actions do not cache their outputs separately from the build action
itself. It might be better to make changes in future CLs to enable that,
but it does add a reasonable amount of complexity. The purpose of this
CL is to split up the cover and build actions, so that in the next CL we
can insert cgo actions in the middle to enable running the cgo compile
actions in parallel.
For #9887
Change-Id: I6a6a696459feade17a144e5341096475676ae99f
Reviewed-on: https://go-review.googlesource.com/c/go/+/697135
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@google.com>
With the previous CL in place, we can now pretty easily optimize a few
more loads from abi.Type. I've done Size_, PtrBytes, and Kind_, which
are easily calculated.
Among std/cmd, this rule fires a number of times:
75 abi.Type field Kind_
50 abi.PtrType field Elem
14 abi.Type field Hash
4 abi.Type field Size_
2 abi.Type field PtrBytes
The other ones that show up when compiling std/cmd are TFlag and GCData,
but these are not trivially calculated. Doing TFlag would probably be a
decent help given it's often used in things like switches where
statically knowing the kind could eliminate a bunch of dead code.
Change-Id: Ic7fd2113fa7479af914d06916edbca60cc71819f
Reviewed-on: https://go-review.googlesource.com/c/go/+/701298
Reviewed-by: Mark Freeman <markfreeman@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Many CLs have worked with this bit of code, extending the cases more and
more for various fixed addresses and constants. But, I find that it's
getting duplicitive, and I don't find the current setup very clear that
something like isFixed32 _only_ works for a specific element within the
type data.
This CL rewrites these rules (pun unintended) into a single set of
rewrite rules with shared logic, which stops hardcoding offsets and type
compatibility checks.
This should open the door to optimizing further type:... field loads, of
which most can be done entirely statically but are not yet today outside
Hash and Elem.
Passes toolstash -cmp.
Change-Id: I754138ce1785c6036eada9ed53f0ce2ad2a58b63
Reviewed-on: https://go-review.googlesource.com/c/go/+/701297
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Mark Freeman <markfreeman@google.com>
Reviewed-by: Florian Lehner <lehner.florian86@gmail.com>
For chunked iterations (useful for, but not exclusive to,
SIMD calculations) it is common to see the combination of
```
for ; i <= len(m)-4; i += 4 {
```
and
```
r0, r1, r2, r3 := m[i], m[i+1], m[i+2], m[i+3]
``
Prove did not handle the case of len-offset1 vs index+offset2
checking, but this change fixes this. There may be other
similar cases yet to handle -- this worked for the chunked
loops for simd, as well as a handful in std.
Change-Id: I3785df83028d517e5e5763206653b34b2befd3d0
Reviewed-on: https://go-review.googlesource.com/c/go/+/700696
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>
CL 700336 let the compiler see into the abi.PtrType.Elem field,
but forgot the MarkTypeSymUsedInInterface to ensure that the symbol
is marked as referenced.
I am not sure how to write a test for this, but I noticed this when
working on further optimizations where I "fixed" this issue and
confusingly failed toolstash -cmp, with diffs like:
@@ -70582,6 +70582,7 @@ reflect.groupAndSlotOf<1> STEXT size=696 args=0x20 locals=0x1e0 funcid=0x0 align
rel 3+0 t=R_USEIFACE type:*reflect.rtype<0>+0
rel 3+0 t=R_USEIFACE type:*reflect.rtype<0>+0
rel 3+0 t=R_USEIFACE type:*uint64<0>+0
+ rel 3+0 t=R_USEIFACE type:uint64<0>+0
rel 71+0 t=R_CALLIND +0
rel 92+4 t=R_PCREL go:itab.*reflect.rtype,reflect.Type<0>+0
rel 114+4 t=R_CALL reflect.(*rtype).ptrTo<1>+0
Updates #75203
Change-Id: Ib8de8a32aeb8a7ea6fcf5d728a2e4944ef227ab2
Reviewed-on: https://go-review.googlesource.com/c/go/+/701296
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Keith Randall <khr@google.com>
On loong64, the addi.d instruction can only directly handle 12-bit
immediate numbers. If a larger immediate number needs to be processed,
it must first be placed in a register, and then the add.d instruction
is used to complete the processing of the larger immediate number.
If a larger immediate number c satisfies is32Bit(c) && c&0xffff == 0,
then the ADDV16 instruction can be used to complete the addition operation.
Removes 164 instructions from the go binary on loong64.
Change-Id: I404de93cc4eaaa12fe424f5a0d61b03231215d1a
Reviewed-on: https://go-review.googlesource.com/c/go/+/700536
Reviewed-by: Meidan Li <limeidan@loongson.cn>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Right now the profile-from-trace code blindly discards events that don't
have a stack, but this means it can discard 'end' events for goroutine
time ranges that don't have stacks, like when a goroutine exits a
syscall. This means we drop stack samples we *do* have, because we
correctly already only use the stack trace of the corresponding 'start'
event for a time-range-of-interest anyway.
This change means that some events will be tracked that have no stack in
their start event, but that's fine. It won't end up in the profile
anyway because the stack is empty! And the rest of the code appears to
be robust to an empty stack already.
Thank you to Rhys Hiltner for reporting this issue and for the
reproducer, which I have worked into a test for this change.
Fixes#74850.
Change-Id: I943b97ecf6b82803e4a778a0f83a14473d32254e
Reviewed-on: https://go-review.googlesource.com/c/go/+/694156
Reviewed-by: Rhys Hiltner <rhys.hiltner@gmail.com>
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>
Delve and viewcore use DWARF type DIEs to display and explore the
runtime value of interface variables.
This has always been slightly problematic since the runtime type of an
interface variable might only be reachable through interfaces and thus
be missing from debug_info (see issue #46670).
Prior to commit f4de2ecf this was not a severe problem since a struct
literal caused the allocation of a struct into an autotemp variable,
which was then used by dwarfgen to make sure that the DIE for that type
would be generated.
After f4de2ecf such autotemps are no longer being generated and
go1.25.0 ends up having many more instances of interfaces with
unreadable runtime type (https://github.com/go-delve/delve/issues/4080).
This commit fixes this problem by scanning the relocation of the
function symbol and adding to the function's DIE symbol references to
all types used by the function to create interfaces.
Fixes go-delve/delve#4080
Updates #46670
Change-Id: I3e9db1c0d1662905373239816a72604ac533b09e
Reviewed-on: https://go-review.googlesource.com/c/go/+/696955
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Than McIntosh <thanm@golang.org>
Reviewed-by: Florian Lehner <lehner.florian86@gmail.com>
Merge List:
+ 2025-09-03 4c4cefc19a cmd/gofmt: simplify logic to process arguments
+ 2025-09-03 925a3cdcd1 unicode/utf8: make DecodeRune{,InString} inlineable
+ 2025-09-03 3e596d448f math: rename Modf parameter int to integer
+ 2025-09-02 2a7f1d47b0 runtime: use one more address bit for tagged pointers
+ 2025-09-02 b09068041a cmd/dist: run racebench tests only in longtest mode
+ 2025-09-02 355370ac52 runtime: add comment for concatstring2
+ 2025-09-02 1eec830f54 go/doc: linkify interface methods
+ 2025-08-31 7bba745820 cmd/compile: use generated loops instead of DUFFZERO on loong64
+ 2025-08-31 882335e2cb cmd/internal/obj/loong64: add LDPTR.{W/D} and STPTR.{W/D} instructions support
+ 2025-08-31 d4b17f5869 internal/runtime/atomic: reset wrong jump target in Cas{,64} on loong64
+ 2025-08-31 6a08e80399 net/http: skip redirecting in ServeMux when URL path for CONNECT is empty
+ 2025-08-29 8bcda6c79d runtime/race: add race detector support for linux/riscv64
+ 2025-08-29 8377adafc5 cmd/cgo: split loadDWARF into two parts
+ 2025-08-29 a7d9d5a80a cmd/cgo: move typedefs and typedefList out of Package
+ 2025-08-29 1d459c4357 all: delete more windows/arm remnants
+ 2025-08-29 27ce6e4e26 cmd/compile: remove sign extension before MULW on riscv64
+ 2025-08-29 84b070bfb1 cmd/compile/internal/ssa: make oneBit function generic
+ 2025-08-29 fe42628dae internal/cpu: inline DebugOptions
+ 2025-08-29 94b7d519bd net: update document on limitation of iprawsock on Windows
+ 2025-08-29 ba9e1ddccf testing: allow specify temp dir by GOTMPDIR environment variable
+ 2025-08-29 9f6936b8da cmd/link: disallow linkname of runtime.addmoduledata
+ 2025-08-29 89d41d254a bytes, strings: speed up TrimSpace
+ 2025-08-29 38204e0872 testing/synctest: call out common issues with tests
+ 2025-08-29 252c901125 os,syscall: pass file flags to CreateFile on Windows
+ 2025-08-29 53515fb0a9 crypto/tls: use hash.Cloner
+ 2025-08-28 13bb48e6fb go/constant: fix complex != unknown comparison
+ 2025-08-28 ba1109feb5 net: remove redundant cgoLookupCNAME return parameter
+ 2025-08-28 f74ed44ed9 net/http/httputil: remove redundant pw.Close() call in DumpRequestOut
+ 2025-08-28 a9689d2e0b time: skip TestLongAdjustTimers in short mode on single CPU systems
+ 2025-08-28 ebc763f76d syscall: only get parent PID if SysProcAttr.Pdeathsig is set
+ 2025-08-28 7f1864b0a8 strings: remove redundant "runs" from string.Fields docstring
+ 2025-08-28 90c21fa5b6 net/textproto: eliminate some bounds checks
+ 2025-08-27 e47d88beae os: return nil slice when ReadDir is used with a file on file_windows
+ 2025-08-27 6b837a64db cmd/internal/obj/loong64: simplify buildop
+ 2025-08-27 765905e3bd debug/elf: don't panic if symtab too small
+ 2025-08-27 2ee4b31242 net/http: Ensure that CONNECT proxied requests respect MaxResponseHeaderBytes
+ 2025-08-27 b21867b1a2 net/http: require exact match for CrossSiteProtection bypass patterns
+ 2025-08-27 d19e377f6e cmd/cgo: make it safe to run gcc in parallel
+ 2025-08-27 49a2f3ed87 net: allow zero value destination address in WriteMsgUDPAddrPort
+ 2025-08-26 afc51ed007 internall/poll: remove bufs field from Windows' poll.operation
+ 2025-08-26 801b74eb95 internal/poll: remove rsa field from Windows' poll.operation
+ 2025-08-26 fa18c547cd syscall: sort Windows env block in StartProcess
+ 2025-08-26 bfd130db02 internal/poll: don't use stack-allocated WSAMsg parameters
+ 2025-08-26 dae9e456ae runtime: identify virtual memory layout for riscv64
+ 2025-08-25 25c2d4109f math: use Trunc to implement Modf
+ 2025-08-25 4e05a070c4 math: implement IsInf using Abs
+ 2025-08-25 1eed4f32a0 math: optimize Signbit implementation slightly
+ 2025-08-25 bd71b94659 cmd/compile/internal: optimizing add+sll rule using ALSLV instruction on loong64
+ 2025-08-25 ea55ca3600 runtime: skip doInit of plugins in runtime.main
+ 2025-08-25 9ae2f1fb57 internal/trace: skip async preempt off tests on low end systems
+ 2025-08-25 bbd5342a62 net: fix cgoResSearch
+ 2025-08-25 ed7f804775 os: set full name for Roots created with Root.OpenRoot
+ 2025-08-25 a21249436b internal/poll: use fdMutex to provide read/write locking on Windows
+ 2025-08-24 44c5956bf7 test/codegen: add Mul2 and DivPow2 test for loong64
+ 2025-08-24 0aa8019e94 test/codegen: add Mul* test for loong64
+ 2025-08-24 83420974b7 test/codegen: add sqrt* abs and copysign test for loong64
+ 2025-08-23 f2db0dca0b net/http/httptest: redirect example.com requests to server
+ 2025-08-22 d86ec92499 internal/syscall/windows: increase internal Windows O_ flags values
+ 2025-08-22 9d3f7fda70 crypto/tls: fix quic comment typo
+ 2025-08-22 78a05c541f internal/poll: don't pass non-nil WSAMsg.Name with 0 namelen on windows
+ 2025-08-22 52c3f73fda runtime/metrics: improve doc
+ 2025-08-22 a076f49757 os: fix Root.MkdirAll to handle race of directory creation
+ 2025-08-22 98238fd495 all: delete remaining windows/arm code
+ 2025-08-21 1ad30844d9 cmd/asm: process forward jump to PCALIGN
+ 2025-08-21 13c082601d internal/poll: permit nil destination address in WriteMsg{Inet4,Inet6}
+ 2025-08-21 9b0a507735 runtime: remove remaining windows/arm files and comments
+ 2025-08-21 1843f1e9c0 cmd/compile: use zero register instead of specialized *zero instructions on loong64
+ 2025-08-21 e0870a0a12 cmd/compile: simplify zerorange on loong64
+ 2025-08-21 fb8bbe46d5 cmd/compile/internal/ssa: eliminate unnecessary extension operations
+ 2025-08-21 9632ba8160 cmd/compile: optimize some patterns into revb2h/revb4h instruction on loong64
+ 2025-08-21 8dcab6f450 syscall: simplify execve handling on libc platforms
+ 2025-08-21 ba840c1bf9 cmd/compile: deduplication in the source code generated by mknode
+ 2025-08-21 fa706ea50f cmd/compile: optimize rule (x + x) << c to x << c+1 on loong64
+ 2025-08-21 ffc85ee1f1 cmd/internal/objabi,cmd/link: add support for additional riscv64 relocations
Change-Id: I3896f74b1a3cc0a52b29ca48767bb0ba84620f71
Rather than stat-ing each argument and taking different code paths
depending on whether it's a directory or not, we can leverage
the fact that filepath.WalkDir works on regular files and already
has to figure out whether each file it walks is a directory or not.
We can then implement "always format non-directory arguments"
by looking at whether the path we are walking is the original argument,
meaning we are walking the top file.
For full clarity, we expand the skipping logic with a switch,
as before it was a bit confusing how we could `return err`
on directories and other non-Go files.
Given that we discard directories separately now,
simplify isGoFile to just be about filenames.
While here, also note that we called AddReport inside WalkDir;
this is unnecessary, as we can return the error for the same effect.
Change-Id: I50ab94710143f19bd8dd95a69e01a3dd228e397e
Reviewed-on: https://go-review.googlesource.com/c/go/+/700115
Reviewed-by: Sean Liao <sean@liao.dev>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This change makes the fast path for ASCII characters inlineable in
DecodeRune and DecodeRuneInString and removes most instances of manual
inlining at call sites.
Here are some benchmark results (no change to allocations):
goos: darwin
goarch: amd64
pkg: unicode/utf8
cpu: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz
│ old │ new │
│ sec/op │ sec/op vs base │
DecodeASCIIRune-8 2.4545n ± 2% 0.6253n ± 2% -74.52% (p=0.000 n=20)
DecodeJapaneseRune-8 3.988n ± 1% 4.023n ± 1% +0.86% (p=0.050 n=20)
DecodeASCIIRuneInString-8 2.4675n ± 1% 0.6264n ± 2% -74.61% (p=0.000 n=20)
DecodeJapaneseRuneInString-8 3.992n ± 1% 4.001n ± 1% ~ (p=0.625 n=20)
geomean 3.134n 1.585n -49.43%
Note: when #61502 gets resolved, DecodeRune and DecodeRuneInString should
be reverted to their idiomatic implementations.
Fixes#31666
Updates #48195
Change-Id: I4be25c4f52417dc28b3a7bd72f1b04018470f39d
GitHub-Last-Rev: 2e352a0045
GitHub-Pull-Request: golang/go#75181
Reviewed-on: https://go-review.googlesource.com/c/go/+/699675
Reviewed-by: Sean Liao <sean@liao.dev>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
We use one extra bit to placate systems which simulate amd64 binaries on
an arm64 host. Allocated arm64 addresses could be as high as 1<<48-1,
which would be invalid if we assumed 48-bit sign-extended addresses.
(Note that this does not help the other way around, simluating arm64
on amd64, but we don't have that problem at the moment.)
Fixes#69255
Change-Id: Iace17a5d41a65e34abf201d03d8b0ff6f7bf1150
Reviewed-on: https://go-review.googlesource.com/c/go/+/700515
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
The racebench tests represent a significant portion of the race
builders' runtimes, but these tests aren't providing a lot of value.
Disable them and run them only on -longtest-race builders.
For #32032.
Change-Id: Ic4383c3f3b51d123ae9f5c377bc0e2ec02f2ddd7
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-race,gotip-linux-amd64-longtest-race
Reviewed-on: https://go-review.googlesource.com/c/go/+/700455
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Bypass: Michael Knyszek <mknyszek@google.com>
Apparently, on macOS 15 or newer, Rosetta 2 supports AVX1 and 2.
However, neither CPUID nor the Apple-recommended sysctl says it
has AVX. If AVX is used without checking the CPU feature, it may
run fine without SIGILL, but the runtime doesn't know AVX is
available therefore save and restore its states. This may lead to
value corruption.
Check if we are running under Rosetta 2 on macOS 15 or newer. If so,
report AVX1 and 2 as supported.
Change-Id: Ib981379405b1ae28faa378f051096827d760a4cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/700055
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
A hash object needs to be cloned when doing certain steps in a
TLS 1.3 server handshake. It is more efficient to use the
hash.Cloner interface to clone a hash than to encode and decode
the hash object using the binary encoding interfaces.
We still need to support the binary encoding path in case the
hash objects come from the fips140 v1.0.0 module, given that
this module doesn't support the hash.Cloner interface.
Change-Id: I8425e14e481dcefafc9aa1e5bfd63b61c22675ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/682597
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently, CONNECT proxied requests use an unlimited Reader. As a
result, a malicious or misbehaving proxy server can send an unlimited
number of bytes to a client; causing the client to indefinitely receive bytes
until it runs out of memory.
To prevent this, we now use a LimitedReader that limits the number of
bytes according to MaxResponseHeaderBytes in Transport. If
MaxResponseHeaderBytes is not provided, we use the default value of 10
MB that has historically been used (see #26315).
Fixes#74633
Change-Id: I0b03bb354139dbc64318874402f7f29cc0fb42ce
Reviewed-on: https://go-review.googlesource.com/c/go/+/698915
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The rsa field was added to the operation structure to avoid allocating
it every time it is needed. We can do better by using a sync.Pool to
reuse allocations across operations and FDs instead of the field.
A side benefit is that FD is now 16 bytes smaller and operation more
stateless.
Change-Id: I3b69a59e36b27f2cdd076cebd8d27a2a350b9c43
Reviewed-on: https://go-review.googlesource.com/c/go/+/698875
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
WSAMsg parameters should be passed to Windows as heap pointers instead
of stack pointers. This is because Windows might access the memory
after the syscall returned in case of a non-blocking operation (which
is the common case), and if the WSAMsg is on the stack, the Go
runtime might have moved it around.
Use a sync.Pool to cache WSAMsg structures to avoid a heap allocation
every time a WSAMsg is needed.
Fixes#74933
Cq-Include-Trybots: luci.golang.try:x_net-gotip-windows-amd64
Change-Id: I075e2ceb25cd545224ab3a10d404340faf19fc01
Reviewed-on: https://go-review.googlesource.com/c/go/+/698797
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Identify sv39, sv48 and sv57 based on the system stack address.
The current approach to memory allocation is less than ideal on
RISC-V hardware that is using sv39 mode. On sv39 we currently end
up doing around 85 mmap and 66 munmap, since we are trying to map
an unusable range. With this change we do 22 mmap and 0 munmap at
runtime initialisation.
This will also be necessary to support the race detector on sv39.
Updates #64345
Cq-Include-Trybots: luci.golang.try:gotip-linux-riscv64
Change-Id: I4f8ba6763b5ecfedfad5438e025d633820e8265c
Reviewed-on: https://go-review.googlesource.com/c/go/+/690495
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com>
Reviewed-by: Jorropo <jorropo.pgm@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
By implementing Modf using Trunc, rather than the other way round,
we can get a significant performance improvement on platforms where
Trunc is implemented as an intrinsic.
Trunc is implemented as an intrinsic on ppc64x and arm64 so the assembly
implementations of Modf are no longer needed (the compiler can generate
very similar code that can now potentially be inlined).
GOAMD64=v1
goos: linux
goarch: amd64
pkg: math
cpu: 12th Gen Intel(R) Core(TM) i7-12700T
│ sec/op │ sec/op vs base │
Gamma 4.257n ± 0% 3.890n ± 0% -8.61% (p=0.000 n=10)
Modf 1.6110n ± 0% 0.4243n ± 0% -73.67% (p=0.000 n=10)
geomean 2.619n 1.285n -50.94%
GOAMD64=v2
goos: linux
goarch: amd64
pkg: math
cpu: 12th Gen Intel(R) Core(TM) i7-12700T
│ sec/op │ sec/op vs base │
Gamma 4.100n ± 1% 3.717n ± 0% -9.35% (p=0.000 n=10)
Modf 1.6070n ± 0% 0.2158n ± 1% -86.57% (p=0.000 n=10)
geomean 2.567n 0.8957n -65.11%
Change-Id: I689a560c344cf1d39ef002b540749bacc3179786
Reviewed-on: https://go-review.googlesource.com/c/go/+/694896
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Sean Liao <sean@liao.dev>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@google.com>
This small tweak to Signbit improves code generation on riscv64 and
possibly other architectures by removing the need to apply a 64 bit
mask.
Before:
MOV $-9223372036854775808, X6
AND X6, X5, X5
SNEZ X5, X10
After:
SLTI $0, X5, X10
This transformation could also be added to the optimization rules
but it is quite a special case.
goos: linux
goarch: riscv64
pkg: math
cpu: Spacemit(R) X60
│ sec/op │ sec/op vs base │
Signbit 13.05n ± 0% 11.42n ± 0% -12.49% (p=0.000 n=10)
Change-Id: Ic218017c5bbb720ec24c6fe7cc230df539b2630c
Reviewed-on: https://go-review.googlesource.com/c/go/+/698419
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Sean Liao <sean@liao.dev>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Sean Liao <sean@liao.dev>
Reviewed-by: Florian Lehner <lehner.florian86@gmail.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Plugins may be loaded in the user's init code.
If loading fails, md.bad is true, and doInit should not be executed.
If loading succeeds, the plugin must run modulesinit and typelinksinit
before doInit. Here is not protected by pluginsMu, and in concurrent
scenarios it is possible to obtain the moduledata of the plugin that
is still in the loading process.
Any added modules after loop starts will do their own doInit calls.
This fixes the issue introduced by CL 520375.
Fixes#75102
Change-Id: I48e91ae21615a0c54176875a6a2dea8e1dade906
Reviewed-on: https://go-review.googlesource.com/c/go/+/697675
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
On Windows it is not possible to do concurrent I/O on file handles due
to the way FD.Pread and FD.Pwrite are implemented. This serialization is
achieved by having a dedicated mutex locked in the affected FD methods.
This makes the code difficult to reason about, as there is another
layer of locking introduced by the fdMutex. For example, it is not
obvious that concurrent I/O operations are serialized.
This CL removed the dedicated mutex and uses the fdMutex to provide
read/write locking.
Change-Id: I00389662728ce29428a587c3189bab90a0399215
Reviewed-on: https://go-review.googlesource.com/c/go/+/698096
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
The lowercase o_ flags are invented values. These conflict with
constants that will soon be allowed by os.OpenFile, which values will
be mandated by the Windows API. To avoid this overlap, the internal
values have been increased to the 33-63 bit range, as the Windows ones
are in the 0-32 bit range.
Updates #73676
Change-Id: I0f657f3ed3403de150f1730a5a65ae887a18a4e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/697363
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
On AMD64, we reserve the X15 register as the zero register.
Currently we use an SSE instruction to zero it, and we only use
it in SSE contexts. When the machine supports AVX, the high bits
of the register is not necessarily zeroed.
Now that the compiler generates AVX code for SIMD, it would be
great to have a zero register in the AVX context. This CL zeroes
the whole X15 register if AVX is supported.
Change-Id: I4dc803362f2e007b1614b90de435fbb7814cebc7
Reviewed-on: https://go-review.googlesource.com/c/go/+/698237
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Reviewed-by: David Chase <drchase@google.com>
The namings follow the following convention:
- If its indices are from constant, amend "Constant" to the name.
- If its indices are used by multiple groups, mend "Grouped" to the
name.
- If its indexing only the low part, amend "Lo", similarly "Hi".
Change-Id: I6a58f5dae54c882ebd59f39b5288f6f3f14d957f
Reviewed-on: https://go-review.googlesource.com/c/go/+/698296
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
This new API is given the name SumAbsDiff, a slightly-longer name for
its canonical abbreviation SAD(Sum-Absolute-Differences).
This instruction has some similar semantic's one, but their semantic is much more
specific and complex: MPSADBW, VDBPSADBW. They should have a more
specific name given this fact.
Change-Id: Ied9144440f82919c3c2d45ae4ce5b961ae91a020
Reviewed-on: https://go-review.googlesource.com/c/go/+/697776
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This might have been something that prove could be educated
into figuring out, but this also works, and it also helps
prove downstream.
Adjusted the prove test, because this change moved a message.
Change-Id: I5eabe639eff5db9cd9766a6a8666fdb4973829cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/697715
Commit-Queue: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Bypass: David Chase <drchase@google.com>
and adds some tests of size-changing conversions.
IMO the template naming conventions in genfiles
are getting grubby, and I plan to change them in
an immediately following CL.
Change-Id: I4a72e8a8c9e9806fab60570dff4c87a754e427c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/697456
Commit-Queue: David Chase <drchase@google.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
TryBot-Bypass: David Chase <drchase@google.com>
Merge List:
+ 2025-08-20 9de69f6913 errors: mention Is/As in Join docs
+ 2025-08-20 4afd482812 cmd/go/internal/doc: pass URL fragments separately with -http
+ 2025-08-20 509d5f647f internal/poll: don't call Seek for overlapped Windows handles
+ 2025-08-20 853fc12739 internal/poll: set the correct file offset in FD.Seek for Windows overlapped handles
+ 2025-08-19 bd885401d5 runtime: save and restore all fcc registers in async preempt on loong64
+ 2025-08-19 119546ea4f cmd/go: document install outputs to $GOOS_$GOARCH when cross compiling
+ 2025-08-19 ffa882059c unique: deflake TestCanonMap/LoadOrStore/ConcurrentUnsharedKeys
+ 2025-08-19 1f2e8e03e4 os: fix path in MkdirTemp error message
+ 2025-08-19 5024d0d884 cmd/compile: tweak example command in README
+ 2025-08-19 b80ffb64d8 internal/trace: remove redundant info from Event.String
+ 2025-08-19 c7d8bda459 cmd/compile/internal: make function comments match function names
+ 2025-08-19 de2d741667 internal/trace: use RFC3339Nano for wall clock snapshots in Event.String
+ 2025-08-19 c61db5ebd5 syscall: forkAndExecInChild1: don't reuse pid variable
+ 2025-08-19 07ee3bfc63 cmd/go: use modern pprof flags in documentation
+ 2025-08-18 5a56d8848b cmd/compile: ensure we use allowed registers for input-clobbering instructions
+ 2025-08-18 c3927a47f0 runtime: fix comments in tracetype.go
+ 2025-08-15 77f911e31c internal/trace: emit final sync event for generation in Go 1.26+
+ 2025-08-15 786be1d2bf runtime: don't overwrite global stop channel in tests
+ 2025-08-15 4a7fde922f internal/trace: add end-of-generation signal to trace
+ 2025-08-15 cb814bd5bc net: skip TestIPv4WriteMsgUDPAddrPort on plan9
+ 2025-08-15 78a3968c2c runtime/metrics: add metric for current Go-owned thread count
+ 2025-08-15 ab8121a407 runtime/metrics: add metric for total goroutines created
+ 2025-08-15 13df972f68 runtime/metrics: add metrics for goroutine sched states
+ 2025-08-15 bd07fafb0a runtime: disable stack shrinking for all waiting-for-suspendG cases
+ 2025-08-15 a651e2ea47 runtime: remove duff support for amd64
+ 2025-08-15 e4291e484c runtime: remove duff support for arm64
+ 2025-08-15 15d6dbc05c cmd/compile: use generated loops instead of DUFFCOPY on arm64
+ 2025-08-15 bca3e98b8a cmd/go: test barrier actions
+ 2025-08-15 052fcde9fd internal/runtime: cleaner overflow checker
+ 2025-08-15 3871c0d84d syscall: permit nil destination address in sendmsgN{Inet4,Inet6}
+ 2025-08-14 a8564bd412 runtime: make all synctest bubble violations fatal panics
Change-Id: Ibc94566bc69bcb59b1d79b6fa868610ca2d1d223
Windows doesn't keep the file pointer for overlapped file handles.
To work around this, we keep track of the current offset ourselves
and use it on every Read/Write operation.
When the user calls File.Seek with whence == io.SeekCurrent, it expects
that the offset we keep track of is also accounted for, else the
the seek'ed value won't match the file pointer seen by the user.
Updates #74951.
Fixes#75081.
Change-Id: Ieca7c3779e5349292883ffc293a8474088a4dec7
Reviewed-on: https://go-review.googlesource.com/c/go/+/697275
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Right now we can expect the `Op(...).Masked` idiom to lack many parts that will
make the API incomplete. But to make the API sizes smaller, we are removing these ops' frontend types and interfaces for now. We will have the peepholes and a new pass
checking the CPU features check domination relations to make these ops
picked for the right `Op(...).Masked` idiom.
Change-Id: I77f72a198b3d8b1880dcb911470db5e0089ac1ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/697155
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Bypass: Junyang Shao <shaojunyang@google.com>
I do not know yet what's causing this flake, but I've debugged it enough
to be confident that it's not a serious issue; it seems to be a test
flake. There is some path through which the tree nodes or keys might
still be transiently reachable, but I don't yet know what that is.
Details about what I tried and ruled out are in the code.
For #74083.
Change-Id: I97cdaf3f97e8c543fcc2ccde8b7e682893ae2f97
Reviewed-on: https://go-review.googlesource.com/c/go/+/697341
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Remove redundant information from state transition events. They
currently mention the proc and goroutine id that is transitioning twice.
Also reorder the reason to appear after the from->to state transition
information since it is a detail that is not available for all
transition.
Before example:
M=6164541440 P=3 G=17 StateTransition Time=7169014471424 Resource=Goroutine(17) Reason="chan receive" GoID=17 Running->Waiting
M=6166261760 P=3 G=10 StateTransition Time=7169908799040 Resource=Proc(4) Reason="" ProcID=4 Idle->Idle
After example:
M=6164541440 P=3 G=17 StateTransition Time=7169014471424 GoID=17 Running->Waiting Reason="chan receive"
M=6166261760 P=3 G=10 StateTransition Time=7169908799040 ProcID=4 Idle->Idle Reason=""
Change-Id: I6a6a696487ff2905f7c98dae7e887b998a2cb298
Reviewed-on: https://go-review.googlesource.com/c/go/+/697356
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
A named return variable pid is reused in a few places, and while
the code is not wrong, it is somewhat confusing.
This variable used to be called r1 before CL 456516 (which did the right
thing, but slightly added to the confusion).
Now, the code calling SYS_WRITE (initially added by CL 158298) never
checks the number of bytes written, so let's remove the assignment.
In the code that calls SYS_READ it is used, so let's use a different
variable, c, which seems less confusing.
All this hopefully makes the code more readable.
Change-Id: I0d7ec311615100deb7e0aa3f02384eadcc1b47e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/696835
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Stapelberg <stapelberg@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This also required a "always use operation with least
OverrideBase" filter in choosing the machine instructions.
The order of generated HW operations is slightly
modified because the Float version of GetElem
appears earlier in the sorted operations list,
though it is not chosen to generate the HW Op.
Change-Id: I95fa67afca9c8b6f4f18941fdcaf69afdad8055b
Reviewed-on: https://go-review.googlesource.com/c/go/+/696375
Reviewed-by: Junyang Shao <shaojunyang@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
For instructions which clobber their input register, we make a second
copy of the input value so it is still available in a register for
future instructions.
That second copy might not respect the register input restrictions
for the instruction. So the second copy we make here can't actually
be used by the instruction - it should use the first copy, the second
copy is the one that will persist beyond the clobber.
Fixes#75063
Change-Id: I99acdc63f0c4e54567a174ff7ada601ae4e796b7
Reviewed-on: https://go-review.googlesource.com/c/go/+/697015
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
CL 693398 returned the error from reading a generation immediately, but
this is wrong -- a Sync event must be emitted to indicate the end of the
trace before reporting the error. This caused TestCrashWhileTracing
to fail because that test has a high likelihood of producing a truncated
trace, and it expects at least 2 Sync events. The truncated trace error
would be reported before the second Sync event, which is incorrect.
Fixes#75045.
Change-Id: Ia71592c4ec56a544afc85cdb7b575e143f80e048
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/696436
Reviewed-by: Carlos Amedee <carlos@golang.org>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This is used by TestStopTheWorldDeadlock, and the new
TestReadMetricsSched test accidentally modifies this global variable
instead of (as intended) defining a local one.
Change-Id: I7aaece83f285d051ad8b56b7591c76613c39613a
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/696556
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Bypass: Michael Knyszek <mknyszek@google.com>
This change takes the EvEndOfGeneration event and promotes it to a real
event that appears in the trace.
This allows the trace parser to unambiguously identify truncated traces
vs. broken traces. It also makes a lot of the logic around parsing
simpler, because there's no more batch spilling necessary.
Fixes#73904.
Change-Id: I37c359b32b6b5f894825aafc02921adeaacf2595
Reviewed-on: https://go-review.googlesource.com/c/go/+/693398
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently isShrinkStackSafe returns false if a goroutine is put into
_Gwaiting while it actually goes and executes on the system stack.
For a long time, we needed to be robust to the goroutine's stack
shrinking while we're executing on the system stack.
Unfortunately, this has become harder and harder to do over time. First,
the execution tracer might be invoked in these contexts and it may wish
to take a stack trace. We cannot take the stack trace if the garbage
collector might concurrently shrink the stack of the user goroutine we
want to trace. So, isShrinkStackSafe grew the condition that we wouldn't
try to shrink the stack in these cases if execution tracing was enabled.
Today, runtime.mutex may wish to take a stack trace for the mutex
profile, and it can happen in a very similar context. Taking the stack
trace is no longer safe.
This change takes the stance that we stop trying to make this work at
all, and instead guarantee that the stack won't move while we're in
these sensitive contexts.
Change-Id: Ibfad2d7a335ee97cecaa48001df0db9812deeab1
Reviewed-on: https://go-review.googlesource.com/c/go/+/692716
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>
This CL improve its previous CL by implementing
move/load/storeByRegWidth. It should have not touched the compilation
path of complex128, but as a side effect, the move/load/store of
16-byte SIMD vectors in X0 to X15 are now compiled to MOVUPS instead of
VMOVDQU.
These functions could be used in MOV*const, but this CL does not do that
because we haven't seen problems of them yet. But in the future if we
see problems calling these functions to find the right asm might be handy.
Change-Id: I9b76e65eef8155479d3e288402aa96bc29a4f7cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/696255
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
This CL tries to clean up the move/load/store lowering a bit. After CL
695315 the register information for instructions are expected to be
correct for SIMD, but we still need to pick the right instruction during
ssa to asm lowering.
The code before this CL should be working correctly, but MOVSSconst and
MOVSDconst contains duplicated codes, this CL removes that.
This CL also rewrite move/load/storeByTypeAndReg to use only the width
and reg for all non-SIMD types, which is more consistent.
Change-Id: I76c14f3d0140bcbd4fbea0df275fee0202a3b7d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/696175
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Add a barrier action between test run action and it's dependencies.
Run will depend on this barrier action, and the barrier action will depend on:
1. The run action's dependencies
2. The previous barrier action
This will force internal/work to schedule test run actions in-order, preventing potential goroutine starvation from
the channel locking mechanism created to force test run actions to start in-order.
Fixes#73106#61233
Change-Id: I72e9f752f7521093f3c875eef7f2f29b2393fce9
Reviewed-on: https://go-review.googlesource.com/c/go/+/668035
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Michael Matloob <matloob@google.com>
Unblocking a bubbled goroutine from outside the bubble is an error
and panics. Currently, some of those panics are regular panics
and some are fatal. We use fatal panics in cases where its difficult
to panic without leaving something in an inconsistent state.
Change the regular panics (channel and timer operations) to be fatal.
This makes our behavior more consistent: All bubble violations are
always fatal.
More importantly, it avoids introducing new, recoverable panics.
A motivating example for this change is the context package,
which performs channel operations with a mutex held in the
expectation that those operations can never panic. These operations
can now panic as a result of a bubble violation, potentially
leaving a context.Context in an inconsistent state.
Fixes#74837
Change-Id: Ie6efd916b7f505c0f13dde42de1572992401f15c
Reviewed-on: https://go-review.googlesource.com/c/go/+/696195
Auto-Submit: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
This CL implements the check for rematerializeable value's output
regspec at its remateralization site. It has some potential problems,
please see the TODO in regalloc.go.
Fixes#70451.
Change-Id: Ib624b967031776851136554719e939e9bf116b7c
Reviewed-on: https://go-review.googlesource.com/c/go/+/695315
Reviewed-by: David Chase <drchase@google.com>
TryBot-Bypass: David Chase <drchase@google.com>
There is a fast-path optimization for marshaling an any type
that should be semantically identical to when the optimization
is not active (i.e., optimizeCommon is false).
Unfortunately, the optimization accidentally allows NaN,
which this change fixes.
The source of this discrepency is that Encoder.WriteToken(Float(math.NaN()))
emits a JSON string with "NaN", rather than report an error.
The rationale for this behavior is because we needed to decide what to do
with Float(math.NaN()), whether it would return an error, panic, or allow it.
To keep the API simpler (no errors) and less sharp (no panics), we permitted NaN.
The fact that WriteToken allowed it is a logical extension of that decision,
but we could decide to disallow it at least within WriteToken.
As things stand, it is already inconsistent between json/v2 and jsontext, where
json/v2 rejects NaN by default in Marshal, but jsontext allows it in WriteToken.
This only modifies code that is compiled under goexperiment.jsonv2.
Fixes#74797
Change-Id: Ib0708cfbf93c2b059c0a85e4c4544c0604573448
Reviewed-on: https://go-review.googlesource.com/c/go/+/695276
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>
The correction in CL 685755 is incomplete for plan9, where path
search is performed even on file strings containing "/". By
applying filepath.Clean to the argument of validateLookPath,
we can check for bogus file strings containing ".." where the
later call to filepath.Join would transform a path like
"badfile/dir/.." to "badfile" even where "dir" isn't a directory
or doesn't exist.
For #74466Fixes#74892
Change-Id: I3f8b73a1de6bc7d8001b1ca8e74b78722408548e
Reviewed-on: https://go-review.googlesource.com/c/go/+/693935
Reviewed-by: David du Colombier <0intro@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
It is ok to clobber registers that have a copy of a fixedreg value,
as that value is always available in its original location later
if we need it. (See 14 lines below the change.)
This CL will fix the regalloc infinite loop that CL 678620 introduced.
That CL requests that the stack pointer value be materialized in a
non-stack-pointer register, which is atypical. That condition
triggered the infinite loop that this CL fixes. The infinite loop is
the compiler trying to reuse that non-stack-pointer register for
something else, but then refusing to give it up because it thought
that non-stack-pointer register held the last copy of the original SP
value.
Change-Id: Id604d0937fb9d3753ee273bf1917753d3ef2d5d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/696035
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This moves the simdgen tool and its supporting unify package from
golang.org/x/arch/internal as of CL 695619 to simd/_gen in the main repo.
The simdgen tool was started in x/arch to live next to xeddata and a
few other assembler generators that already lived there. However, as
we've been developing simdgen, we've discovered that there's a
tremendous amount of process friction coordinating commits to x/arch
with the corresponding generated files in the main repo.
Many of the existing generators in x/arch were started before modules
existed. In GOPATH world, it was impractical for them to live in the
main repo because they have dependencies that are not allowed in the
main repo. However, now that we have modules and can use small
submodules in the main repo, we can isolate these dependencies to just
the generators, making it practical for them to live in the main repo.
This commit was generated by the following script:
# Checks
set -e
if [[ ! -d src/simd ]]; then
echo >&2 "$PWD is not the root of the main repo on dev.simd"
exit 1
fi
if [[ -z "$XEDDATA" ]]; then
echo >&2 "Must set \$XEDDATA"
exit 1
fi
which go >/dev/null
# Move simdgen from x/arch
xarch=$(mktemp -d)
git clone https://go.googlesource.com/arch $xarch
xarchCL=$(git -C $xarch log -1 --format=%b | awk -F/ '/^Reviewed-on:/ {print $NF}')
echo >&2 "x/arch CL: $xarchCL"
mv $xarch/internal src/simd/_gen
sed --in-place s,golang.org/x/arch/internal/,simd/_gen/, src/simd/_gen/*/*.go
# Create self-contained module
cat > src/simd/_gen/go.mod <<EOF
module simd/_gen
go 1.24
EOF
cd src/simd/_gen
go mod tidy
git add .
git gofmt
# Regenerate file
go run -C simdgen . -xedPath $XEDDATA -o godefs -goroot $(go env GOROOT) go.yaml types.yaml categories.yaml
go run -C ../../cmd/compile/internal/ssa/_gen .
Change-Id: I56dd8473e913a9eb1978d9b3b3518ed632972f6f
Reviewed-on: https://go-review.googlesource.com/c/go/+/695975
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
The tree has opened for Go 1.26 development. 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
# Update a cmd/vet test case.
patch <<EOF
--- src/cmd/vet/testdata/assign/assign.go
+++ src/cmd/vet/testdata/assign/assign.go
@@ -18 +18 @@ func (s *ST) SetX(x int, ch chan int) {
- x = x // ERROR "self-assignment of x to x"
+ x = x // ERROR "self-assignment of x"
@@ -20 +20 @@ func (s *ST) SetX(x int, ch chan int) {
- s.x = s.x // ERROR "self-assignment of s.x to s.x"
+ s.x = s.x // ERROR "self-assignment of s.x"
@@ -22 +22 @@ func (s *ST) SetX(x int, ch chan int) {
- s.l[0] = s.l[0] // ERROR "self-assignment of s.l.0. to s.l.0."
+ s.l[0] = s.l[0] // ERROR "self-assignment of s.l.0."
EOF
Change-Id: I3fc77d49fa7b47803d363287910b0e37bedefb60
Reviewed-on: https://go-review.googlesource.com/c/go/+/694536
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Apparently CL 692996 made the Darwin race builders to be very
flaky. That CL does two things: 1. uses "ld -r" to strip out the
dynamic symbol table; 2. updates to a newer version of LLVM TSAN.
To narrow it down, this CL undoes the second part, restpring the
previous version of LLVM TSAN, but keeps the "ld -r" part.
For #74978.
Change-Id: I0611d733232b18440f249cd5a0b76f7e1ff99a55
Reviewed-on: https://go-review.googlesource.com/c/go/+/695137
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Bypass: Cherry Mui <cherryyz@google.com>
Commit-Queue: Cherry Mui <cherryyz@google.com>
This change imports the AVX512 GC scanning kernel from CL 593938 into a
new package, internal/runtime/gc/scan. Credit to Austin Clements for
most of this work. I did some cleanup, added support for more size
classes to the expanders, and added more testing. I also restructured
the code to make it easier and clearer to add new scan kernels for new
architectures.
For #73581.
Change-Id: I76bcbc889fa6cad73ba0084620fae084a5912e6b
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64_avx512,gotip-linux-amd64_avx512-greenteagc
Reviewed-on: https://go-review.googlesource.com/c/go/+/655280
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
The Indent function preserves trailing whitespace,
while the v1 emulation under v2 implementation accidentally dropped it.
There was prior logic that attempted to preserve it,
but it did not work correctly since it ran in a defer and
accidentally mutated the dst input argument rather than the output argument.
Move the logic to the end and avoid a defer.
Also, add a test to both v1 and v1in2 to codify this behavior.
This only modifies code that is compiled in under goexperiment.jsonv2.
Updates #13520Fixes#74806
Change-Id: I22b1a8da5185eb969e2a8a111b625d3752cfcbe8
Reviewed-on: https://go-review.googlesource.com/c/go/+/692195
Reviewed-by: Sean Liao <sean@liao.dev>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Sean Liao <sean@liao.dev>
This CL fixes some errors in prog generation for imm operations, please
see the changes in ssa.go for details.
This CL also implements the jump table for non-const immediate arg. The
current implementation exhaust 0-255, the bound-checked version will be
in the next CL.
This CL is partially generated by CL 694375.
Change-Id: I75fe9900430b4fca5b39b0c0958a13b20b1104b7
Reviewed-on: https://go-review.googlesource.com/c/go/+/694395
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
When the HashTrieMap expand method runs out of bits, it can be because
the user mutated a key after insertion using unsafe or similar
in violation of the HashTrieMap invariants.
Adjust the panic message to help triage and debugging by
more directly suggesting unsafe code might be at fault.
CL 694635 is a follow-up change that attempts to detect and
report illegally mutated keys sooner and more precisely.
Updates #74948
Updates #73427
Change-Id: Ib2bca067f0e212b8765c61183f59ac229513a823
Reviewed-on: https://go-review.googlesource.com/c/go/+/694376
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
type W struct {
E struct{}
X *byte
}
type W is a "direct" type. That is, it is a pointer-ish type that can
be stored directly as the second word of an interface.
But if we ask reflect for W's first field, that value must *not* be
direct, as zero-sized things cannot be stored directly.
This was a problem introduced in CL 681937. Before that, types like W
were not eligible for directness.
Fixes#74935
Change-Id: Idefb55c23eaa59153009f863bad611593981e5cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/694195
Auto-Submit: 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: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
- Absolute -> Abs
- ApproximateReciprocal -> Reciprocal
- Other derived apis also changed.
- Round -> RoundToEven
- Other derived apis also changed.
- Drop DotProdBroadcast
- Fused(Mul|Add)(Mul|Add)? -> remove the "Fused"
- MulEvenWiden -> remove 64bit
- MulLow -> Mul, add unit
- PairDotProd -> DotProdPairs
- make AddDotProdPairs machine ops only - peepholes will be in another
CL at dev.simd.
- PopCount -> OnesCount
- Saturated* -> *Saturated
- Fix (Add|Sub)Saturated uint mappings.
- UnsignedSignedQuadDotProdAccumulate -> AddDotProdQuadruple
- The "DotProdQuadruple" instruction does not exist, so no peepholes for
this.
This CL is generated by CL 694095.
Change-Id: If4110cc04ab96240cf56f2348d35ed2a719687de
Reviewed-on: https://go-review.googlesource.com/c/go/+/694115
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
On macOS, the script in LLVM TSAN building the race syso files
produces the Mach-O object with a malformed dynamic symbol table,
which new Apple linker doesn't like and emits an annoying warning
(https://github.com/golang/go/issues/61229#issuecomment-1988965927).
The dynamic symbol table isn't really needed, as it is a static
object. Perhaps it should be fixed in TSAN or the C toolchain, but
we can do a simple workaround: pass it through "ld -r", which
produces an equivalent object file with LC_DYSYMTAB removed.
CL 692975 changes racebuild to do this, which produces new syso's
in this CL.
While here, build the syso with a newer version of LLVM TSAN.
Updates #61229.
Change-Id: Ide4b7831eb2cb6877c8ace7b3ec8ff565a9eaf54
Reviewed-on: https://go-review.googlesource.com/c/go/+/692996
Reviewed-by: David Chase <drchase@google.com>
TryBot-Bypass: Cherry Mui <cherryyz@google.com>
Currently, the ImportedSymbols method requires an LC_DYSYMTAB load
command to exist. However, a Mach-O object file may not have an
LC_DYSYMTAB load command, e.g. the one produced by "ld -r".
Support this case by just reading the symbol table and gathers
undefined symbols.
Updates #61229.
Change-Id: I8b4761ac7d99e1f1f378e883e9be75ee4049ffbb
Reviewed-on: https://go-review.googlesource.com/c/go/+/692995
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
The new dynamic loader in macOS 26 beta doesn't like binaries
without LC_UUID. Binaries built by "go build" have LC_UUID by
default. When invoking the linker manually, it has an LC_UUID by
default if a Go buildid is specified. This CL makes it pass
-buildid to link command for the test directory, so the binaries
will have LC_UUID.
Change-Id: I9369aeb7323d211eda80e4f22f459c220085f61d
Reviewed-on: https://go-review.googlesource.com/c/go/+/692876
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
A database/sql/driver.Rows can return database-owned data
from Rows.Next. The driver.Rows documentation doesn't explicitly
document the lifetime guarantees for this data, but a reasonable
expectation is that the caller of Next should only access it
until the next call to Rows.Close or Rows.Next.
Avoid violating that constraint when a query is cancelled while
a call to database/sql.Rows.Scan (note the difference between
the two different Rows types!) is in progress. We previously
took care to avoid closing a driver.Rows while the user has
access to driver-owned memory via a RawData, but we could still
close a driver.Rows while a Scan call was in the process of
reading previously-returned driver-owned data.
Update the fake DB used in database/sql tests to invalidate
returned data to help catch other places we might be
incorrectly retaining it.
Fixes#74831.
Change-Id: Ice45b5fad51b679c38e3e1d21ef39156b56d6037
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/2540
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Neal Patel <nealpatel@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/693735
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Generated by arch/internal/simdgen CL 693175
These methods are not public because of simdgen-induced name/signature
issues, and because their addition was motivated by the need for
emulation tools.
The specific name signature problems are:
1) one set of instructions has the "Masked" suffix (because of how
that is incorporated into names) and the other set does not (though I
suppose the operation could be renamed).
2) because the AVX2 instruction is bytes-only, to get the signature
right, requires "OverwriteBase" but OverwriteBase also requires
OverwriteClass and "simdgen does not support [OverwriteClass] in
inputs".
3) the default operation order is false, true, but we want this in a
"x.Merged(y, mask)" that pairs with "x.Masked(mask)" where the true
case is x and the false case is y/zero, but the default ordering for
VPBLENDVB and VPBLENDMB is false->x and true->y.
4) VPBLENDVB only comes in byte width, which causes problems
for floats.
All this may get fixed in the future, for now it is just an
implementation detail.
Change-Id: I61b655c7011e2c33f8644f704f886133c89d2f15
Reviewed-on: https://go-review.googlesource.com/c/go/+/693155
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Asynchronous preemption must save all registers that could be in use
by Go code. Currently, it saves all of these to the goroutine stack.
As a result, the stack frame requirements of asynchronous preemption
can be rather high. On amd64, this requires 368 bytes of stack space,
most of which is the XMM registers. Several RISC architectures are
around 0.5 KiB.
As we add support for SIMD instructions, this is going to become a
problem. The AVX-512 register state is 2.5 KiB. This well exceeds the
nosplit limit, and even if it didn't, could constrain when we can
asynchronously preempt goroutines on small stacks.
This CL fixes this by moving pure scalar state stored in non-GP
registers off the stack and into an allocated "extended register
state" object. To reduce space overhead, we only allocate these
objects as needed. While in the theoretical limit, every G could need
this register state, in practice very few do at a time.
However, we can't allocate when we're in the middle of saving the
register state during an asynchronous preemption, so we reserve
scratch space on every P to temporarily store the register state,
which can then be copied out to an allocated state object later by Go
code.
This commit only implements this for amd64, since that's where we're
about to add much more vector state, but it lays the groundwork for
doing this on any architecture that could benefit.
This is a cherry-pick of CL 680898 plus bug fix CL 684836 from the
dev.simd branch.
Change-Id: I123a95e21c11d5c10942d70e27f84d2d99bbf735
Reviewed-on: https://go-review.googlesource.com/c/go/+/669195
Auto-Submit: Austin Clements <austin@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This adds detection for the CD and DQ sub-features of x86 AVX-512.
Building on these, we also add a "derived" AVX-512 feature that
bundles together the basic usable subset of subfeatures. Despite the F
in AVX-512-F standing for "foundation", AVX-512-F+BW+DQ+VL together
really form the basic usable subset of AVX-512 functionality. These
have also all been supported together by almost every CPU, and are
guaranteed by GOAMD64=v4, so there's little point in separating them
out.
This is a cherry-pick of CL 680899 from the dev.simd branch.
Change-Id: I34356502bd1853ba2372e48db0b10d55cffe07a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/693396
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Austin Clements <austin@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Remove the special casing for len/cap and rely on the posets.
After removing the special logic, I ran `go build -gcflags='-d
ssa/prove/debug=2' all` to verify my results. During this, I found 2
common cases where the old implicit unsigned->signed domain conversion
made proving a branch possible that shouldn't be strictly possible and
added these.
The 2 cases are shifting a non-negative signed integer and unsigned
comparisons that happen with arguments that fits entirely inside the
unsigned argument
Change-Id: Ic88049ff69efc5602fc15f5dad02028e704f5483
Reviewed-on: https://go-review.googlesource.com/c/go/+/679155
Reviewed-by: Mark Freeman <mark@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Since these functions cast the input to uint64, so the result always
non-negative. The condition should be changed to comparing with zero,
thus maaking it clearer to reader, and open room for simplifying in the
future by using the generic isUnsignedPowerOfTwo function.
Separated this change, so it's easier to do bisecting if there's any
problems happened.
Change-Id: Ibec28c2590f4c52caa36384b710d526459725e49
Reviewed-on: https://go-review.googlesource.com/c/go/+/692915
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
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>
Lots of handwritten/stenciled code is now untouched by human hands
For certain combinations of operation-arity and type, there
is an option to use a flaky version of a test helper, that only
requires "close enough". For example:
testFloat32x4TernaryFlaky(t, simd.Float32x4.FusedMultiplyAdd, fmaSlice[float32], 0.001)
Some of the quirkier operations have their behavior captured
in their test-simulation, for example, ceilResidue regards
infinities as integers (therefore their residue is zero).
Change-Id: I8242914e5ab399edbe226da8586988441cffa83f
Reviewed-on: https://go-review.googlesource.com/c/go/+/690575
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
A test in C has an array bound defined as a "const int", which is
technically a variable. The new version of C compiler in Xcode 26
beta emits a warning "variable length array folded to constant
array as an extension" for this (as an error since we build the
test with -Werror). Work around this by using an enum, which is
syntactically a constant.
Change-Id: Icfa943f293f6eac8f41d0615da40c126330d7d11
Reviewed-on: https://go-review.googlesource.com/c/go/+/692877
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
This pairs with CL 689275 which removes test generation from simdgen
This uses generics and attempts to encode the tests as compactly as
possible.
Some files, *_helpers_test.go, are generated.
Use t.Helper() to get the line number right for a failure.
Adds helper error return values and early exits to only report a
single test failure per operations and vector shape, for the
generated test failures.
Include the entire got and wanted vectors for that failure.
Provide an option to include the input vectors to failures, also
report the type of the test.
Sample failure test output (obtained by intentionally breaking
the "want" value for AndNot):
=== RUN TestAndNot
binary_test.go:214: For int16 vector elements:
binary_test.go:214: got =[0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]
binary_test.go:214: want=[-1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1]
binary_test.go:214: x=[1 -1 0 2 4 8 1024 3 5 7 11 13 3000 5555 7777 11111]
binary_test.go:214: y=[1 -1 0 2 4 8 1024 3 5 7 11 13 3000 5555 7777 11111]
binary_test.go:214: at index 0, got=0, want=-1
binary_test.go:215: For int16 vector elements:
binary_test.go:215: got =[0 0 0 0 0 0 0 0]
binary_test.go:215: want=[-1 -1 -1 -1 -1 -1 -1 -1]
binary_test.go:215: x=[1 -1 0 2 4 8 1024 3]
binary_test.go:215: y=[1 -1 0 2 4 8 1024 3]
binary_test.go:215: at index 0, got=0, want=-1
binary_test.go:216: For int32 vector elements:
binary_test.go:216: got =[0 0 0 0]
binary_test.go:216: want=[-1 -1 -1 -1]
binary_test.go:216: x=[1 -1 0 2]
binary_test.go:216: y=[1 -1 0 2]
binary_test.go:216: at index 0, got=0, want=-1
(etc)
Change-Id: I0f6ee8390ebe7a2333002e9415b4d71527fa3c38
Reviewed-on: https://go-review.googlesource.com/c/go/+/686057
Reviewed-by: Junyang Shao <shaojunyang@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
There is no need to have a dedicated stdcall variant for each
number of arguments. Instead, we can use a variadic function
that accepts any number of arguments and handles them uniformly.
While here, improve documentation of syscall_syscalln to make it clear
that it should not be used within the runtime package.
Change-Id: I022afc7f28d969fd7307bb2b1f4594246ac38d18
Reviewed-on: https://go-review.googlesource.com/c/go/+/691215
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Mark Freeman <mark@golang.org>
The Go toolchain has been copying files instead of moving them on
Windows since CL 72910. It did this because os.Rename doesn't respect
the destination directory ACL permissions, and we want to honor them.
The drawback is that copying files is slower than moving them.
This CL reintroduces the use of os.Rename, but it also sets the
destination file's ACL to inherit the permissions from the
destination directory.
On my computer this change speeds up a simple "go build" (with warm
cache) by 1 second, going from 3 seconds to 2 seconds.
Updates #22343
Change-Id: I65b2b6f301e9e18bf2588959764eb06b9a01dfa2
Reviewed-on: https://go-review.googlesource.com/c/go/+/691255
Reviewed-by: Mark Freeman <mark@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
The module paths "go" and "toolchain" are reserved for the dependency on
the go and toolchain versions. Check for those paths in go mod init to
create modules, go mod edit, and in the module loader and return an
error when attempting to use those paths for a work module. Trying to
init or load a work module with a go.mod that specifies the module path
"go" panics since Go 1.21 (when the toolchain switching logic and the
implicit dependencies on the "go" module was introduced), and this
change returns a proper error instead of panicking.
Fixes#74784
Change-Id: I10e712f8fddbea63edaeb37e14c6d783722e623f
Reviewed-on: https://go-review.googlesource.com/c/go/+/691515
Reviewed-by: Ian Alexander <jitsu@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@google.com>
Add the VECTOR FP (MINIMUM|MAXIMUM) instructions to the assembler and
use them in the compiler to implement min and max.
Note: I've allowed floating point registers to be used with the single
element instructions (those with the W instead of V prefix) to allow
easier integration into the compiler.
Change-Id: I5f80a510bd248cf483cce95f1979bf63fbae7de6
Reviewed-on: https://go-review.googlesource.com/c/go/+/684715
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Mark Freeman <mark@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
The different chacha20-poly1305 cipher suites were renamed to
include the _SHA256 suffix, which is the canonical naming convention.
The occurrences of the old names were still not updated, which can lead
to confusion when searching for the canonical names in the codebase.
Change-Id: I4f90e9cbedc3552c3481c8b0c616b6f915ddd345
Reviewed-on: https://go-review.googlesource.com/c/go/+/689135
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Same as clobbering fixed registers, but which register is clobbered
depends on which register was assigned to the input.
Add code similar to resultInArg0 processing that makes a register
copy before allowing the op to clobber the last available copy of a value.
(Will be used by subsequent CLs in this stack.)
Change-Id: I6bad88b2cb9ac3303d960ff0fb1611727292cfc4
Reviewed-on: https://go-review.googlesource.com/c/go/+/680335
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Jorropo <jorropo.pgm@gmail.com>
Reviewed-by: Mark Freeman <mark@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This info makes more sense in the flags instead of as a high
bit of the kind. This makes kind access simpler because we now
don't need to mask anything.
Cleaned up most direct field accesses to use methods instead.
(reflect making new types is the only remaining direct accessor.)
IfaceIndir -> !IsDirectIface everywhere.
gocore has been updated to handle the new location. So has delve.
TODO: any other tools need updating?
Change-Id: I123f97a4d4bdd0bff1641ee7e276d1cc0bd7e8eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/681936
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Fix incorrect expansion of "" and "." when $PATH contains an executable
file or, on Windows, a parent directory of a %PATH% element contains an
file with the same name as the %PATH% element but with one of the
%PATHEXT% extension (ex: C:\utils\bin is in PATH, and C:\utils\bin.exe
exists).
Fix incorrect expansion of ".." when $PATH contains an element which is
an the concatenation of the path to an executable file (or on Windows
a path that can be expanded to an executable by appending a %PATHEXT%
extension), a path separator and a name.
"", "." and ".." are now rejected early with ErrNotFound.
Fixes CVE-2025-47906
Fixes#74466
Change-Id: Ie50cc0a660fce8fbdc952a7f2e05c36062dcb50e
Reviewed-on: https://go-review.googlesource.com/c/go/+/685755
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Damien Neil <dneil@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Tests on Windows are dependent on the english names of system accounts
and groups.
But on a french install of Windows the system accounts are:
- AUTORITE NT\Système
- AUTORITE NT\SERVICE LOCAL
- AUTORITE NT\SERVICE RÉSEAU
To allow the tests to pass on non-english Windows we only log
differences in user/group names if GetSystemDefaultLCID() reports
a non-english LCID, instead of failing.
Change-Id: Ib81acc2896c45675fa3faf5dc390b57ec5159689
Reviewed-on: https://go-review.googlesource.com/c/go/+/688715
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Mark Freeman <mark@golang.org>
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
Factor out the code related to doing calls using the Windows stdcall
calling convention into a separate package. This will allow us to
reuse it in other low-level packages that can't depend on syscall.
Updates #51087.
Cq-Include-Trybots: luci.golang.try:gotip-windows-arm64,gotip-windows-amd64-longtest,gotip-solaris-amd64
Change-Id: I68640b07091183b50da6bef17406c10a397896e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/689156
Reviewed-by: 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>
The previous algorithm was incorrect, as it reused the dominatedByCall
slice without resetting it. It also used the depth fields even though
they were not yet calculated.
Also, clean up a lot of the loop detector code that we never use.
Always compute depths. It is cheap.
Update #71868
Not really sure how to test this. As it is just an advisory bit,
nothing goes really wrong when the result is incorrect.
Change-Id: Ic0ae87a4d3576554831252d88b05b058ca68af41
Reviewed-on: https://go-review.googlesource.com/c/go/+/680775
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: David Chase <drchase@google.com>
Using Invalid to represent an incomplete alias is problematic since
it implies that an error has been reported somewhere. This causes
confusion for observers of invalid aliases trying not to emit
follow-on errors.
This change uses nil instead to represent an incomplete alias. This
has a mild benefit of making alias memoization more convenient. We
additionally can now memoize Invalid aliases.
This necessitates a minor change to our cycle error reporting for
aliases. Care is taken to separate logic according to gotypesalias.
Otherwise, a cycle as simple as "type T = T" panics.
A test is also added which uses go/types to inspect for Invalid
types. Currently, the problematic Invalid does not cause an error
in type checking, but rather a panic in noding. Thus, we cannot use
the familiar test facilities relying on error reporting.
Fixes#74181
Change-Id: Iea5ebce567a2805f5647de0fb7ded4a96f6c5f8d
Reviewed-on: https://go-review.googlesource.com/c/go/+/683796
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
There is a deadlock issue when calling SetConstraint from a lazy loader
because the loader is called from resolve(), which is holding a lock on
the loaded type.
If the loaded type has a generic constraint which refers back to the
loaded type (such as an argument or result), then we will loop back to
the loaded type and deadlock.
This change postpones calls to SetConstraint and passes them back to
resolve(). At that point, the loaded type is mostly constructed, but
its constraints might be unexpanded.
Similar to how we handle resolved instances, we advance the state for
the loaded type to a, appropriately named, loaded state. When we expand
the constraint, we don't try to acquire the lock on the loaded type.
Thus, no deadlock.
Fixes#63285
Change-Id: Ie0204b58a5b433f6d839ce8fd8a99542246367b7
Reviewed-on: https://go-review.googlesource.com/c/go/+/681875
Commit-Queue: Mark Freeman <mark@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
TestImpersonated and TestGroupIdsTestUser are flaky due to sporadic
failures when creating the test user account when running the tests
from different processes at the same time.
This flakiness can be fixed by using a random name for the test user
account.
Fixes#73523Fixes#74727Fixes#74728Fixes#74729Fixes#74745Fixes#74751
Cq-Include-Trybots: luci.golang.try:gotip-windows-amd64-longtest
Change-Id: Ib2283a888437420502b1c11d876c975f5af4bc03
Reviewed-on: https://go-review.googlesource.com/c/go/+/690175
Auto-Submit: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Bypass: Dmitri Shuralyov <dmitshur@golang.org>
The jsontext.Decoder.ReadToken method reports a non-EOF error,
if the token stream is truncated and does not form a valid JSON value.
In contrast, the v1 json.Decoder.Token method would report EOF
so long as the input was a prefix of some valid JSON value.
Modify json.Decoder.Token to preserve historical behavior.
This only modifies code that is compiled in under goexperiment.jsonv2.
Updates #69449Fixes#74750
Change-Id: Ifd281c46f118f0e748076013fefc7659f77c56ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/689516
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Since CL 682496 we need more stack space to handle bounds checks.
The code modified here normally has no bounds checks, but in -N
builds it still does and thus uses too much stack.
Use unsafe arithmetic to avoid the bounds check.
This will hopefully fix some of the arm64 linux builders.
Change-Id: I5b3096a14b4fb9553e635b7f340e60b8ffba8755
Reviewed-on: https://go-review.googlesource.com/c/go/+/690415
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@google.com>
There were minor and unnecessary error text changes
when v1 was implemented using v2.
Reduce divergences if possible.
Of the cases reported in #74713, there are no more differences for:
v1: json: cannot unmarshal number into Go value of type chan int
v2: json: cannot unmarshal number into Go value of type chan int
and
v1: json: cannot unmarshal number into Go value of type error
v2: json: cannot unmarshal number into Go value of type error
However, there is a difference between:
v1: json: cannot unmarshal string into Go struct field .F.V of type int
v2: json: cannot unmarshal string into Go struct field S.F.V of type int
For reasons unclear, the v1 logic was always inconsistent about
whether it could properly record the root struct type,
while the v1 emulation layer under v2 is always able to.
This only modifies code that is compiled in under goexperiment.jsonv2.
Fixes#74713
Change-Id: I9e87323b1810130cb929288fdd86aff4be82d5f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/689918
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Use stack unwinding instead of keeping incremental track of the argp
of defers that are allowed to recover.
It's much simpler, and it lets us get rid of the incremental tracking
by wrapper code. (Ripped out in a subsequent CL.)
We only need to stack unwind a few frames to get the right answer, and
only when recover()ing in a panic situation. It will be more expensive
in that case, but cheaper in all others.
Change-Id: Id095807db6864b7ac1e1baf09285b77a07c46d19
Reviewed-on: https://go-review.googlesource.com/c/go/+/685355
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
When we see an ASCII character, we will probably see many.
Grab & check increasingly large chunks of the string for ASCII-only-ness.
Also redo some of the non-ASCII code to make it more optimizer friendly.
goos: linux
goarch: amd64
pkg: unicode/utf8
cpu: 12th Gen Intel(R) Core(TM) i7-12700
│ base │ exp │
│ sec/op │ sec/op vs base │
ValidTenASCIIChars-20 3.596n ± 3% 2.522n ± 1% -29.86% (p=0.000 n=10)
Valid100KASCIIChars-20 6.094µ ± 2% 2.115µ ± 1% -65.29% (p=0.000 n=10)
ValidTenJapaneseChars-20 21.02n ± 0% 18.61n ± 2% -11.44% (p=0.000 n=10)
ValidLongMostlyASCII-20 51.774µ ± 0% 3.836µ ± 1% -92.59% (p=0.000 n=10)
ValidLongJapanese-20 102.40µ ± 1% 50.95µ ± 1% -50.24% (p=0.000 n=10)
ValidStringTenASCIIChars-20 2.640n ± 3% 2.526n ± 1% -4.34% (p=0.000 n=10)
ValidString100KASCIIChars-20 5.585µ ± 7% 2.118µ ± 1% -62.07% (p=0.000 n=10)
ValidStringTenJapaneseChars-20 21.29n ± 2% 18.67n ± 1% -12.31% (p=0.000 n=10)
ValidStringLongMostlyASCII-20 52.431µ ± 1% 3.841µ ± 0% -92.67% (p=0.000 n=10)
ValidStringLongJapanese-20 102.66µ ± 1% 50.90µ ± 1% -50.42% (p=0.000 n=10)
geomean 1.152µ 454.8n -60.53%
This is an attempt to see if we can get enough performance that we don't
need to consider assembly like that in CL 681695.
Change-Id: I8250feb797a6b4e7d335c23929f6e3acc8b24840
Reviewed-on: https://go-review.googlesource.com/c/go/+/682778
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: 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>
For all the static bounds checks in cmd/go, we have:
6877 just a single instruction (the call itself)
139 needs an additional reg-reg move
602 needs an additional constant load
25 needs some other instruction
that's ~90% implemented using just a single instruction.
Reduces the text size of cmd/go by ~0.8%.
Total binary size is just barely smaller, ~0.2%. (The difference
is the new pcdata table.)
Change-Id: I416e9c196f5d8d0e8f08e191e6df3045e11dccbe
Reviewed-on: https://go-review.googlesource.com/c/go/+/682496
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Currently we must put the index and length into specific registers so
we can call into the runtime to report a bounds check failure.
So a typical bounds check call is something like:
MOVD R3, R0
MOVD R7, R1
CALL runtime.panicIndex
or, if for instance the index is constant,
MOVD $7, R0
MOVD R9, R1
CALL runtime.panicIndex
Sometimes the MOVD can be avoided, if the value happens to be in the
right register already. But that's not terribly common, and doesn't
work at all for constants.
Let's get rid of those MOVD instructions. They pollute the instruction
cache and are almost never executed.
Instead, we'll encode in a PCDATA table where the runtime should find
the index and length. The table encodes, for each index and length,
whether it is a constant or in a register, and which register or
constant it is.
That way, we can avoid all those useless MOVDs. Instead, we can figure
out the index and length at runtime. This makes the bounds panic path
slower, but that's a good tradeoff.
We can encode registers 0-15 and constants 0-31. Anything outside that
range still needs to use an explicit instruction.
This CL is the foundation, followon CLs will move each architecture
to the new strategy.
Change-Id: I705c511e546e6aac59fed922a8eaed4585e96820
Reviewed-on: https://go-review.googlesource.com/c/go/+/682396
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This allows something like:
if y { x++ }
To be compiled to:
MOVBLZX BX, CX
ADDQ CX, AX
Instead of:
LEAQ 1(AX), CX
MOVBLZX BL, DX
TESTQ DX, DX
CMOVQNE CX, AX
While ./make.bash uniqued per LOC, there is 100 additions and 75 substractions.
See benchmark here: https://go.dev/play/p/DJf5COjwhd_s
Either it's a performance no-op or it is faster:
goos: linux
goarch: amd64
cpu: AMD Ryzen 5 3600 6-Core Processor
│ /tmp/old.logs │ /tmp/new.logs │
│ sec/op │ sec/op vs base │
CmovInlineConditionAddLatency-12 0.5443n ± 5% 0.5339n ± 3% -1.90% (p=0.004 n=10)
CmovInlineConditionAddThroughputBy6-12 1.492n ± 1% 1.494n ± 1% ~ (p=0.955 n=10)
CmovInlineConditionSubLatency-12 0.5419n ± 3% 0.5282n ± 3% -2.52% (p=0.019 n=10)
CmovInlineConditionSubThroughputBy6-12 1.587n ± 1% 1.584n ± 2% ~ (p=0.492 n=10)
CmovOutlineConditionAddLatency-12 0.5223n ± 1% 0.2639n ± 4% -49.47% (p=0.000 n=10)
CmovOutlineConditionAddThroughputBy6-12 1.159n ± 1% 1.097n ± 2% -5.35% (p=0.000 n=10)
CmovOutlineConditionSubLatency-12 0.5271n ± 3% 0.2654n ± 2% -49.66% (p=0.000 n=10)
CmovOutlineConditionSubThroughputBy6-12 1.053n ± 1% 1.050n ± 1% ~ (p=1.000 n=10)
geomean
There are other benefits not tested by this benchmark:
- the math form is usually a couple bytes shorter (ICACHE)
- the math form is usually 0~2 uops shorter (UCACHE)
- the math form has usually less register pressure*
- the math form can sometimes be optimized further
*regalloc rarely find how it can use less registers
As far as pass ordering goes there are many possible options,
I've decided to reorder branchelim before late opt since:
- unlike running exclusively the CondSelect rules after branchelim,
some extra optimizations might trigger on the adds or subs.
- I don't want to maintain a second generic.rules file of only the stuff,
that can trigger after branchelim.
- rerunning all of opt a third time increase compilation time for little gains.
By elimination moving branchelim seems fine.
Change-Id: I869adf57e4d109948ee157cfc47144445146bafd
Reviewed-on: https://go-review.googlesource.com/c/go/+/685676
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: Michael Knyszek <mknyszek@google.com>
Fold a shift through AND when the AND gets a zero-or-one operand (e.g.
from arithmetic shift by 63 of a 64-bit value) for a common case with
slice operations:
ASR $63, R2, R2
AND R3<<3, R2, R2
ADD R2, R0, R2
As the operands are 64-bit, we can transform it to:
AND R2->63, R3, R2
ADD R2<<3, R0, R2
Code size improvement:
compile: .text: 9088004 -> 9086292 (-0.02%)
etcd: .text: 10500276 -> 10498964 (-0.01%)
Change-Id: Ibcd5e67173da39b77ceff77ca67812fb8be5a7b5
Reviewed-on: https://go-review.googlesource.com/c/go/+/679895
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Mark Freeman <mark@golang.org>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Enhance loop rotation of nested loops. Currently, loops are processed independently,
resulting in unnecessary jumps between outer and inner loops. By processing inner
loops before their parent loop, we ensure nested loop blocks are
properly placed within their parent loop's block sequence.
There is some code size improvement (as measured on amd64) due to jumps
to/from inner loop are removed by the updated loopRotate block order:
Executable Old .text New .text Change
-------------------------------------------------------
asm 2147569 2146481 -0.05%
cgo 1977457 1975761 -0.09%
compile 10447345 10441905 -0.05%
cover 2110097 2108977 -0.05%
link 2930289 2929041 -0.04%
preprofile 927345 926769 -0.06%
vet 3279057 3277009 -0.06%
Change-Id: I4b9e993c2be07fad735e6bcf32d062d099d9cfb5
Reviewed-on: https://go-review.googlesource.com/c/go/+/684335
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Optimize ARM64 code generation for slice bounds checking by recognizing
patterns where comparisons to zero involve SUB or SUBconst operations.
This change adds SSA opt rules to simplify:
(CMPconst [0] (SUB x y)) => (CMP x y)
The optimizations apply to EQ, NE, ULE, and UGT comparisons, enabling
more efficient bounds checking for slice operations.
Code size improvement:
compile: .text: 9088004 -> 9065988 (-0.24%)
etcd: .text: 10500276 -> 10497092 (-0.03%)
Change-Id: I467cb27674351652bcacc52b87e1f19677bd46a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/679915
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: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
On RISC-V and MIPS andarchitectures, misaligned load/store is not mandatory for implementations. Therefore, it's important to handle memory operations involving small sizes or data with a remainder when divided by 8 or 4.
This CL add some benchmark for small-size memmory operation, to ensure that SSA rules do not generate unaligned access traps on such architectures.
Change-Id: I6fcdfdb76e9552d5b10df140fa92568ac9468386
Reviewed-on: https://go-review.googlesource.com/c/go/+/682575
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Benchmark:
goos: windows
goarch: amd64
pkg: hash/crc32
cpu: AMD Ryzen 9 9950X 16-Core Processor
benchmark old MB/s new MB/s speedup
BenchmarkCRC32/poly=IEEE/size=15/align=0-32 1081.48 1089.42 1.01x
BenchmarkCRC32/poly=IEEE/size=15/align=1-32 1085.87 1082.61 1.00x
BenchmarkCRC32/poly=IEEE/size=40/align=0-32 2756.33 2752.37 1.00x
BenchmarkCRC32/poly=IEEE/size=40/align=1-32 2758.27 2756.99 1.00x
BenchmarkCRC32/poly=IEEE/size=512/align=0-32 18133.44 18076.52 1.00x
BenchmarkCRC32/poly=IEEE/size=512/align=1-32 18151.05 18055.41 0.99x
BenchmarkCRC32/poly=IEEE/size=1kB/align=0-32 19902.93 48581.07 2.44x
BenchmarkCRC32/poly=IEEE/size=1kB/align=1-32 19966.99 48393.25 2.42x
BenchmarkCRC32/poly=IEEE/size=4kB/align=0-32 21690.33 51679.25 2.38x
BenchmarkCRC32/poly=IEEE/size=4kB/align=1-32 21655.30 51731.22 2.39x
BenchmarkCRC32/poly=IEEE/size=32kB/align=0-32 22046.57 46406.90 2.10x
BenchmarkCRC32/poly=IEEE/size=32kB/align=1-32 21986.22 46250.66 2.10x
AVX512 are enabled above 1KB input size.
This rather high limit is due to AVX512 may be slower to ramp up
than the regular SSE4 implementation for smaller inputs.
This is not reflected in the benchmarks,
since consecutive calls means the CPU is "hot".
The 'HasAVX512VPCLMULQDQ' name mirrors the one in golang.org/x/sys/cpu
Change-Id: Id23685d8e3cc412b6d397a7d70056844bdb79271
Change-Id: Id23685d8e3cc412b6d397a7d70056844bdb79271
GitHub-Last-Rev: 6639f07b9f
GitHub-Pull-Request: golang/go#74701
Reviewed-on: https://go-review.googlesource.com/c/go/+/689435
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
During initialization, allow randomizing the heap base address by
generating a random uint64 and using its bits to randomize various
portions of the heap base address.
We use the following method to randomize the base address:
* We first generate a random heapArenaBytes aligned address that we use
for generating the hints.
* On the first call to mheap.grow, we then generate a random
PallocChunkBytes aligned offset into the mmap'd heap region, which we
use as the base for the heap region.
* We then mark a random number of pages within the page allocator as
allocated.
Our final randomized "heap base address" becomes the first byte of
the first available page returned by the page allocator. This results
in an address with at least heapAddrBits-gc.PageShift-1 bits of
entropy.
Fixes#27583
Change-Id: Ideb4450a5ff747a132f702d563d2a516dec91a88
Reviewed-on: https://go-review.googlesource.com/c/go/+/674835
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
When an untyped operand of a (typically binary) operation does not
match the type of the operand and an implicit conversion is not
possible, the error message should report a "type mismatch".
The type-checkers mostly did so, but not for untyped numeric types
to other types (e.g. an untyped int vs a function); in those cases
it reported that the (impossible) conversion failed.
Fix this for numeric types.
This also improves the position and messages for some incorrect
min/max built-in calls.
Fixes#73428.
Change-Id: I8af071918b73fcc72f16cc61858d7baca57fc259
Reviewed-on: https://go-review.googlesource.com/c/go/+/682495
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Mark Freeman <mark@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
The Decoder.Reset method is not preserving the internal buffer between
resets, causing buffer capacity to be lost and resulting in unnecessary
allocations when reusing decoders. This is particularly problematic when
decoding many small messages.
This commit fixes the Reset method to preserve the internal buffer. It
makes sure aliasing is removed if the buffer currently points to an
internal byte slice of a bytes.Buffer. It adds a TestDecoderReset test
structured into subtests to better validate the different scenarios.
Change-Id: Ia685bff47034598224489173bb7f2ffd48e89da5
GitHub-Last-Rev: 462ddc9364
GitHub-Pull-Request: golang/go#74120
Reviewed-on: https://go-review.googlesource.com/c/go/+/681177
Reviewed-by: Sean Liao <sean@liao.dev>
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
This CL reorderes the param order of PairDotProdAccumulate family to be
dotprod(x, y) + z instead of the old dotprod(y, z) + x.
This CL also updates some documentation of other ML Ops.
This CL added a test to test the behavior is correct.
This CL is partially generated by CL 688115.
Change-Id: I76a6ee55a2ad8e3aff388d7e4fa5218ec0e4800d
Reviewed-on: https://go-review.googlesource.com/c/go/+/688095
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This CL fixes the merge locals error.
The culprit is that liveness analysis wrongly mark SIMD structs fat,
hence making `StoreReg` of SIMD vectors not a varkill effect, making the
liveness range of SIMD vectors not closed correctly, further making
mergelocals merged 2 concurrently-live SIMD vectors.
Is looks like mergelocals will treat the live range as one instruction
if it's not closed: [st, st+1). Should we make it [st, +inf) instead? So
that we won't have similar errors in the future.
Also, I feel we really need to examine every "case types.TSTRUCT" or "if
t.Kind() == types.TSTRUCT" in the codebase correctly for SIMD types...
Change-Id: I2f4f4f36a890bd317d582cfa73a8f6a789382d91
Reviewed-on: https://go-review.googlesource.com/c/go/+/687775
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
It looks like mergelocals pass's liveness analysis does not handle simd
variables well.
The added test forces two vectors to spill in a way that does not work
with mergelocals: if the added check is removed, then `v` and `m` will
be marked merged and spilled to the same location, failing the test.
Change-Id: Ife4e4e939565d817fc24f7180cb791a5084dd191
Reviewed-on: https://go-review.googlesource.com/c/go/+/687375
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Merge List:
+ 2025-07-11 88cf0c5d55 cmd/link: do size fixups after symbol references are loaded
+ 2025-07-10 7a38975a48 os: trivial comment fix
+ 2025-07-10 aa5de9ebb5 synctest: fix comments for time.Now() in synctests
+ 2025-07-10 63ec70d4e1 crypto/cipher: Fix comment punctuation
+ 2025-07-09 8131635e5a runtime: run TestSignalDuringExec in its own process group
+ 2025-07-09 67c1704444 crypto/tls: empty server_name conf. ext. from server
+ 2025-07-08 54c9d77630 cmd/go: disable support for multiple vcs in one module
+ 2025-07-08 fca43a8436 internal: make struct comment match struct name
+ 2025-07-08 bb917bb030 cmd/compile: document that nosplit directive is unsafe
+ 2025-07-08 a5bda585d5 cmd/compile: run fmt on ssa
+ 2025-07-07 86b5ba7310 internal/trace: only test for sync preemption if async preemption is off
+ 2025-07-07 ef46e1b164 cmd/internal/doc: fix GOROOT skew and path joining bugs
+ 2025-07-07 75b43f9a97 runtime: make traceStack testable and add a benchmark
+ 2025-07-07 20978f46fd crypto/rsa: remove another forgotten note to future self
+ 2025-07-07 33fb4819f5 cmd/compile/internal/ssa: skip EndSequence entries in TestStmtLines
+ 2025-07-07 a995269a93 sort: clarify Less doc
+ 2025-07-03 6c3b5a2798 runtime: correct vdsoSP on S390X
+ 2025-07-03 dd687c3860 hash: document that Clone may only return ErrUnsupported or a nil error
+ 2025-07-02 b325151453 cmd/cgo/internal/testsanitizers: skip asan tests when FIPS140 mode is on
+ 2025-07-02 15d9fe43d6 testing/synctest: explicitly state Run will be removed in Go 1.26
+ 2025-07-01 de646d94f7 cmd/go/internal/modindex: apply changes in CL 502615 to modindex package
+ 2025-07-01 2f653a5a9e crypto/tls: ensure the ECDSA curve matches the signature algorithm
+ 2025-07-01 6e95fd96cc crypto/ecdsa: fix crypto/x509 godoc links
+ 2025-07-01 7755a05209 Revert "crypto/internal/fips140/subtle: add assembly implementation of xorBytes for arm"
+ 2025-07-01 d168ad18e1 slices: update TestIssue68488 to avoid false positives
+ 2025-07-01 27ad1f5013 internal/abi: fix comment on NonEmptyInterface
+ 2025-06-30 86fca3dcb6 encoding/json/jsontext: use bytes.Buffer.AvailableBuffer
+ 2025-06-30 6bd9944c9a encoding/json/v2: avoid escaping jsonopts.Struct
+ 2025-06-30 e46d586edd cmd/compile/internal/escape: add debug hash for literal allocation optimizations
+ 2025-06-30 479b51ee1f cmd/compile/internal/escape: stop disabling literal allocation optimizations when coverage is enabled
+ 2025-06-30 8002d283e8 crypto/tls: update bogo version
+ 2025-06-30 fdd7713fe5 internal/goexperiment: fix godoc formatting
Change-Id: I074e6c75778890930975925c016004aabca2b9d1
Currently, there's a write barrier in xRegRestore when it assigns
pp.xRegs.cache = gp.xRegs.state. This is bad because that gets called
on the asyncPreempt return path, where we have really limited stack
space, and we don't currently account for this write barrier.
We can't simply mark xRegState as sys.NotInHeap because it's also
embedded in runtime.p as register scratch space, and runtime.p is heap
allocated.
Hence, to fix this, we rename xRegState to just "xRegs" and introduce
a wrapper "xRegState" type that embeds xRegs and is itself marked
sys.NotInHeap. Then, anywhere we need a manually-managed pointer to
register state, we use the new type.
To ensure this doesn't happen again in the future, we also mark
asyncPreempt2 as go:nowritebarrierrec.
Change-Id: I5ff4841e55ff20047ff7d253ab659ab77aeb3391
Reviewed-on: https://go-review.googlesource.com/c/go/+/684836
Auto-Submit: Austin Clements <austin@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Asynchronous preemption must save all registers that could be in use
by Go code. Currently, it saves all of these to the goroutine stack.
As a result, the stack frame requirements of asynchronous preemption
can be rather high. On amd64, this requires 368 bytes of stack space,
most of which is the XMM registers. Several RISC architectures are
around 0.5 KiB.
As we add support for SIMD instructions, this is going to become a
problem. The AVX-512 register state is 2.5 KiB. This well exceeds the
nosplit limit, and even if it didn't, could constrain when we can
asynchronously preempt goroutines on small stacks.
This CL fixes this by moving pure scalar state stored in non-GP
registers off the stack and into an allocated "extended register
state" object. To reduce space overhead, we only allocate these
objects as needed. While in the theoretical limit, every G could need
this register state, in practice very few do at a time.
However, we can't allocate when we're in the middle of saving the
register state during an asynchronous preemption, so we reserve
scratch space on every P to temporarily store the register state,
which can then be copied out to an allocated state object later by Go
code.
This commit only implements this for amd64, since that's where we're
about to add much more vector state, but it lays the groundwork for
doing this on any architecture that could benefit.
Change-Id: I123a95e21c11d5c10942d70e27f84d2d99bbf735
Reviewed-on: https://go-review.googlesource.com/c/go/+/680898
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Austin Clements <austin@google.com>
This adds support for one ad hoc reordering, which
requires a new intrinsic-to-ssa helper matching the
name that is used in the generator (and this in the
generated code). In this case, it is opLen{2,3}Imm8_2I
which expects the immediate after the self (0) and
first (1) parameters to the method, and before the
mask if there is one. I.e., the immediate is arg 2
in the call.
The changes to simdintrinsics and stubs are generated
by simdgen CL 684019.
Change-Id: Ia54aab9825d469a2f3efa6d1fb079242181c0ca6
Reviewed-on: https://go-review.googlesource.com/c/go/+/684776
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
These changes are required to make gp-returning simd
ops work. amd64/ssa.go includes a new code generator
helper, gc/main.go initializes intrinsics AFTER
the types, ssa/_gen/*AMD64.go add another register
shape to the simd ops function.
This CL should be submitted after simdgen CL 683858
which generated some of the changes.
Change-Id: I0af752ba8882fa131b875ff9c741ef70afbc60d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/683816
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Merge List:
+ 2025-06-25 f8ccda2e05 runtime: make explicit nil check in (*spanInlineMarkBits).init
+ 2025-06-25 f069a82998 runtime: note custom GOMAXPROCS even if value doesn't change
+ 2025-06-24 e515ef8bc2 context: fix typo in context_test.go
+ 2025-06-24 47b941f445 cmd/link: add one more linkname to the blocklist
+ 2025-06-24 34cf5f6205 go/types: add test for interface method field type
+ 2025-06-24 6e618cd42a encoding/json: use zstd compressed testdata
+ 2025-06-24 fcb9850859 net/http: reduce allocs in CrossOriginProtection.Check
+ 2025-06-24 11f11f2a00 encoding/json/v2: support ISO 8601 durations
+ 2025-06-24 62deaf4fb8 doc: fix links to runtime Environment Variables
+ 2025-06-24 2e9bb62bfe encoding/json/v2: reject unquoted dash as a JSON field name
+ 2025-06-23 ed7815726d encoding/json/v2: report error on time.Duration without explicit format
+ 2025-06-23 f866958246 cmd/dist: test encoding/json/... with GOEXPERIMENT=jsonv2
+ 2025-06-23 f77a0aa6b6 internal/trace: improve gc-stress test
+ 2025-06-23 4506796a6e encoding/json/jsontext: consistently use JSON terminology
+ 2025-06-23 456a90aa16 runtime: add missing unlock in sysReserveAlignedSbrk
+ 2025-06-23 1cf6386b5e Revert "go/types, types2: don't register interface methods in Info.Types map"
+ 2025-06-20 49cdf0c42e testing, testing/synctest: handle T.Helper in synctest bubbles
+ 2025-06-20 3bf1eecbd3 runtime: fix struct comment
+ 2025-06-20 8ed23a2936 crypto/cipher: fix link to crypto/aes
+ 2025-06-20 ef60769b46 go/doc: add a golden test that reproduces #62640
+ 2025-06-18 8552bcf7c2 cmd/go/internal/fips140: ignore GOEXPERIMENT on error
+ 2025-06-18 4c7567290c runtime: set mspan limit field early and eagerly
+ 2025-06-18 c6ac736288 runtime: prevent mutual deadlock between GC stopTheWorld and suspendG
+ 2025-06-17 53af292aed encoding/json/jsontext: fix spelling error
+ 2025-06-16 d058254689 cmd/dist: always include variant in package names
+ 2025-06-16 3254c2bb83 internal/reflectlite: fix comment about meaning of flag field
+ 2025-06-16 816199e421 runtime: don't let readTrace spin on trace.shutdown
+ 2025-06-16 ea00461b17 internal/trace: make Value follow reflect conventions
+ 2025-06-13 96a6e147b2 runtime: comment that some linknames are used by runtime/trace
+ 2025-06-13 644905891f runtime: remove unused unique.runtime_blockUntilEmptyFinalizerQueue
+ 2025-06-13 683810a368 cmd/link: block new standard library linknames
+ 2025-06-12 9149876112 all: replace a few user-visible mentions of golang.org and godoc.org
+ 2025-06-12 934d5f2cf7 internal/trace: end test programs with SIGQUIT
+ 2025-06-12 5a08865de3 net: remove some BUG entries
+ 2025-06-11 d166a0b03e encoding/json/jsontext, encoding/json/v2: document experimental nature
+ 2025-06-11 d4c6effaa7 cmd/compile: add up-to-date test for generated files
+ 2025-06-10 7fa2c736b3 os: disallow Root.Remove(".") on Plan 9, js, and Windows
+ 2025-06-10 281cfcfc1b runtime: handle system goroutines later in goroutine profiling
+ 2025-06-10 4f86f22671 testing/synctest, runtime: avoid panic when using linker-alloc WG from bubble
Change-Id: I8bbbf40ce053a80395b08977e21b1f34c67de117
For a compiler intrinsic, if it is used in a non-call context, e.g.
as a function pointer, currently it requires fallback
implementation (e.g. assembly code for atomic operations),
otherwise it will result in a build failure. The fallback
implementation needs to be maintained and tested, albeit rarely
used in practice.
Also, for SIMD, we're currently adding a large number of compiler
intrinsics without providing fallback implementations (we might in
the future). As methods, it is not unlikely that they are used in
a non-call context, e.g. referenced from the type descriptor.
This CL lets the compiler generate the function body for
bodyless intrinsics. The compiler already recognizes a call to
the function as an intrinsic and can directly generate code for it.
So we just fill in the body with a call to the same function.
Change-Id: I2636e3128f28301c9abaf2b48bc962ab56e7d1a9
Reviewed-on: https://go-review.googlesource.com/c/go/+/683096
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The compiler has a logic to print different messages on internal
compiler error depending on whether this is a released version of
Go. It hides the panic stack trace if it is a released version. It
does this by checking the version and see if it has a "go" prefix.
This includes all the released versions. However, for a non-
released build, if there is no explicit version set, cmd/dist now
sets the toolchain version as go1.X-devel_XXX, which makes it be
treated as a released compiler, and causes the stack trace to be
hidden. Change the logic to not match a devel compiler as a
released compiler.
Change-Id: I5d3b2101527212f825b6e4000b36030c4f83870b
Reviewed-on: https://go-review.googlesource.com/c/go/+/682975
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This adds detection for the CD and DQ sub-features of x86 AVX-512.
Building on these, we also add a "derived" AVX-512 feature that
bundles together the basic usable subset of subfeatures. Despite the F
in AVX-512-F standing for "foundation", AVX-512-F+BW+DQ+VL together
really form the basic usable subset of AVX-512 functionality. These
have also all been supported together by almost every CPU, and are
guaranteed by GOAMD64=v4, so there's little point in separating them
out.
Change-Id: I34356502bd1853ba2372e48db0b10d55cffe07a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/680899
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Merge List:
+ 2025-06-10 773701a853 internal/trace: pass GOTRACEBACK=crash to testprogs
+ 2025-06-10 fb0c27c514 os: do not follow dangling symlinks in Root when O_CREATE|O_EXCL on AIX
+ 2025-06-10 1cafdfb63b net/http: make the zero value of CrossOriginProtection work
+ 2025-06-10 a35701b352 cmd/dist: only install necessary tools when doing local test
+ 2025-06-10 a189516d3a runtime: don't do a direct G handoff in semrelease on systemstack
+ 2025-06-10 f18d046568 all.{bash,rc}: use "../bin/go tool dist" instead of "%GOTOOLDIR%/dist" print build info
+ 2025-06-09 ee7bfbdbcc cmd/compile/internal/ssa: fix PPC64 merging of (AND (S[RL]Dconst ...)
+ 2025-06-09 985d600f3a runtime: use small struct TestSynctest to ensure cleanups run
+ 2025-06-09 848a768ba7 runtime: clarify stack traces for bubbled goroutines
+ 2025-06-09 049a5e6036 runtime: return a different bubble deadlock error when main goroutine is done
+ 2025-06-09 ac1686752b cmd/internal/doc: increase version of pkgsite doc command that's run
+ 2025-06-09 da0e8c4517 cmd/compile: relax reshaping condition
+ 2025-06-09 7800f4f0ad log/slog: fix level doc on handlers
+ 2025-06-07 d184f8dc02 runtime: check for gsignal in racecall on loong64
+ 2025-06-06 0ccfbc834a os/signal: doc link to syscall.EPIPE
+ 2025-06-06 78eadf5b3d all: update vendored dependencies [generated]
+ 2025-06-05 4d1c255f15 net/http: strip sensitive proxy headers from redirect requests
+ 2025-06-04 3432c68467 runtime: make bubbled timers more consistent with unbubbled
+ 2025-06-04 1aa3362093 Revert "cmd/compile: Enable inlining of tail calls"
+ 2025-06-04 f537061e1b cmd/trace: handle Sync event at the beginning of the trace
+ 2025-06-04 d4bf716793 runtime: reduce per-P memory footprint when greenteagc is disabled
+ 2025-06-04 1f2a4d192d test: add another regression test for issue 73309
+ 2025-06-04 5b748eed9c cmd/compile: better error message when import embed package
+ 2025-06-03 cfb4e9bc4a cmd/dist: don't install tools that won't be shipped in distribution
+ 2025-06-03 94764d0938 cmd/doc: build cmd/doc directly into the go command
+ 2025-06-03 74b70eead7 go/token: remove unreachable code
+ 2025-06-03 0c0094c893 go/token: tweak comment
+ 2025-06-03 792548a483 cmd/go/internal/cfg: fix GOROOT setting when forcing host config
+ 2025-06-02 49f6304724 runtime: additional memmove benchmarks
+ 2025-06-02 eebae283b6 go/token: FileSet: hold Files in a balanced tree
+ 2025-06-02 3bd0eab96f runtime: randomize order of timers at the same instant in bubbles
+ 2025-06-02 a379698521 go/{ast,parser,types}: add signpost to golang.org/x/tools/go/packages
+ 2025-06-02 497cb7c0c3 cmd/compile/internal/noder: document quirk of string elements
+ 2025-06-02 cc119ee391 cmd/compile/internal/noder: stub type section and adjust others
+ 2025-06-02 25ca686a0b cmd/compile/internal/noder: begin filling in SectionObj
+ 2025-06-02 11660d537b cmd/compile/internal/noder: fill in SectionName
Change-Id: I7c0a7c56105f1a6912f4ed122d615d12b1ea7877
Merge List:
+ 2025-06-02 711ff943af testing: add Output method to TB
+ 2025-06-02 e9d3b030ed slices,sort: explicitly discard results in benchmarks
+ 2025-05-30 a8e99ab19c internal/trace: expose the go version read by the reader
+ 2025-05-30 68b51e99f9 cmd/distpack: add test case for pack tool being excluded
+ 2025-05-30 67f052121e cmd/distpack: don't keep the pack tool
+ 2025-05-30 1947c4233a runtime: set HeapGoal to zero when the GC is disabled
+ 2025-05-30 8cd7f17248 testing, testing/synctest: report correct duration after panics
+ 2025-05-30 29782bd347 os: add implementation of fs.ReadLinkFS to *rootFS
+ 2025-05-29 78e86297f5 cmd/compile/internal/noder: rename RelIndex to match codebase
+ 2025-05-29 fece9871bb cmd/compile: update default PGO profile
+ 2025-05-29 9f3dd846e2 cmd/internal/obj/s390x: fix potential recursive String call
+ 2025-05-29 21b7e60c6b runtime, testing/synctest: breaking bubble isolation with Cond is fatal
+ 2025-05-29 555d425d17 testing, testing/synctest: write bubble errors to parent test log
+ 2025-05-29 f14f3aae1c internal/pkgbits: explain the rationale for reference tables
+ 2025-05-29 4878b4471b slices: document and test nilness behavior of all functions
+ 2025-05-29 7b4d065267 runtime: add vgetrandom lock rank
+ 2025-05-29 e481a08e0e runtime: guarantee no GOMAXPROCS update syscalls after GOMAXPROCS call
+ 2025-05-29 dd678172e3 doc/next: delete
+ 2025-05-29 c2f0fe5854 internal/synctest: speed up TestWeak
+ 2025-05-29 b170c7e94c runtime, internal/synctest, sync: associate WaitGroups with bubbles
+ 2025-05-29 3b77085b40 runtime: increment updatemaxprocs metric only when disabled
+ 2025-05-29 f8c51b1a6c go/doc: NewFromFiles: fix panic on Files with SkipObjectResolution
+ 2025-05-29 263bc50c90 api: promote next to go1.25
+ 2025-05-28 dbaa2d3e65 cmd/compile: do nil check before calling duff functions, on arm64 and amd64
+ 2025-05-28 6160fa59b6 runtime: rename updateGOMAXPROCS to updateMaxProcsG
+ 2025-05-28 ae6c098f48 doc/next: add release note for riscv64 plugin build mode
+ 2025-05-28 18ad74dd36 go/types, types2: dump position stack for non-bailout panics
+ 2025-05-28 70109eb326 cmd/link: allow linkname reference to a TEXT symbol regardless of size
+ 2025-05-28 eff3288042 doc/next: tweak runtime release notes
+ 2025-05-28 c61e5e7244 lib/time: update to 2025b/2025b
+ 2025-05-27 ed08d2ad09 os: don't follow symlinks on Windows when O_CREATE|O_EXCL and read-only
+ 2025-05-27 fce9d4515d runtime, testing/synctest: verify cleanups/finalizers run outside bubbles
+ 2025-05-27 b78e38065e runtime: define lock ranking between weak pointers and synctest
+ 2025-05-27 961818e013 cmd/compile/internal/walk: use original type for composite literals in addrTemp
+ 2025-05-27 c8c3d661b0 runtime/trace: add a trace validation test for different trace orders
+ 2025-05-27 0e1b14bc2e cmd/go: fix get with the new 'work' pattern
+ 2025-05-27 09f1546cba log/slog: fix longtests with empty source
+ 2025-05-27 de05282a2c doc/next: add small header to TODO
+ 2025-05-27 c146a61d4c go/token: benchmark FileSet.{Position,AddExistingFiles}
+ 2025-05-27 ae0824883e go/ast: deprecate FilterPackage, PackageExports, MergePackageFiles
+ 2025-05-27 8dd7d2111b runtime: skip nil Ps in allp during cleanup flush
+ 2025-05-27 3a3c006ac0 crypto/tls: enable signature algorithm BoGo tests (and fix two bugs)
+ 2025-05-27 ed70477909 errors: add joinError Unwrap example
+ 2025-05-27 787362327f io/fs: add examples for Glob,ReadFile and ValidPath
+ 2025-05-24 3fd729b2a1 log/slog: make TextHandler discard empty Source
+ 2025-05-24 c07ffe980a testing/synctest: correct duration in doc example
+ 2025-05-24 3db50924e2 hash: mention the new Cloner interface in Hash docs.
+ 2025-05-23 aca9f4e484 crypto/tls: signature_algorithms in CertificateRequest can't be empty
+ 2025-05-23 8cb0941a85 net: use runtime.AddCleanup instead of runtime.SetFinalizer
+ 2025-05-23 68f4434df0 runtime/trace: match traceClockNow types
+ 2025-05-23 8b1978f614 doc/next: add crudely processed todos
+ 2025-05-23 c0e149b6b1 net/http: document that ServeMux.Handler can also synthetize a 405
+ 2025-05-23 db3e02994c runtime/trace: fix flaky test for SetMinAge
+ 2025-05-22 db55b83ce4 doc: fix TBD mark
+ 2025-05-22 aec96d686b doc: mention stack allocation of variable-sized make calls
+ 2025-05-22 c684dfcb8a runtime: don't spin looking for a tiny alloc address with asan or race
+ 2025-05-22 bfbf736564 cmd/compile: do not shapify when reading reshaping expr
+ 2025-05-22 b1f259b1b4 cmd/compile: fix ICE with recursive alias type parameter
+ 2025-05-22 155ba387a9 cmd/doc: properly set GOPROXY to avoid deprecation checks
+ 2025-05-22 ef3bb638de Revert "cmd/doc: better support for no network"
+ 2025-05-22 a0dc7bf084 cmd/compile: fix ICE when transforming loopvar
Change-Id: I9010808984e73ed2de6041127a222f725f0f52e6
ENABLE when simd experiment is off, to be sure intrinsics
do not leak past the experiment.
DISABLE when simd is on, because all this does is cause tests to
fail, then whoever failed the test regenerates the simd, doesn't look
at the mountain of new intrinsics, and just rubber-stamps the change.
All friction, no benefit.
Change-Id: I2ef7e0c246aaddd4a52c1d6108cb587adc1b8366
Reviewed-on: https://go-review.googlesource.com/c/go/+/677555
Auto-Submit: Junyang Shao <shaojunyang@google.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
this is a multistep operation between two repos to coordinate
this move. First copy internal/simd top simd (and adjust so
that it works with future generated SIMD), after this lands,
update golang/arch/internal/simdgen to target this directory
and add it to the end-to-end test (which will also be added
once it works and is truly end-to-end), finally remove internal/simd
once the updated generator has been submitted.
Change-Id: If372baadc0c02e47cc32bc55b39ac19d551b2b21
Reviewed-on: https://go-review.googlesource.com/c/go/+/676955
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
This combines several CLs into a single patch of "glue"
for the generated SIMD extensions.
This glue includes GOEXPERIMENT checks that disable
the creation of user-visible "simd" types and
that disable the registration of "simd" intrinsics.
The simd type checks were changed to work for either
package "simd" or "internal/simd" so that moving that
package won't be quite so fragile.
cmd/compile, internal/simd: glue for adding SIMD extensions to Go
cmd/compile: theft of Cherry's sample SIMD compilation
Change-Id: Id44e2f4bafe74032c26de576a8691b6f7d977e01
Reviewed-on: https://go-review.googlesource.com/c/go/+/675598
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
