The motivating example I created for #73137 still seems
to heap allocate in go1.26rc2 when used in a b.Loop body.
│ go1.25 │ go1.26rc2 │
│ allocs/op │ allocs/op vs base │
NewX/b.Loop-basic-4 1.000 ± 0% 1.000 ± 0% ~ (p=1.000 n=10) ¹
I suspect it is because the temps are by default declared
outside the loop body, which escape analysis will determine is
an escaping value and result in a heap allocation. (I've seen
this problem before, including in my older CL 546023 that attempts
to help PGO with a similar issue.)
This is an attempt to address that by placing ODCLs within the
b.Loop body for the temps that are created so that they can be
marked keepalive.
There are two cases handled in the CL: function return values
and function arguments. The first case is what affects my example
from #73137, and is also illustrated via the NewX test case in
the new test/escape_bloop.go file.
Without this CL, the NewX call in the BenchmarkBloop test is inlined,
which is an improvement over Go 1.25, but the slice still escapes
because the temporary used for the return value is declared outside
the loop body.
With this CL, the slice does not escape.
The second case is illustrated via the new BenchmarkBLoopFunctionArg
test, which shows a function argument that escapes without this CL
but does not escape with this CL.
We can also make the two new b.Loop tests in testing/benchmark_test.go
individually pass or fail as expected based on individually
reverting the two changes in this CL.
While we are here, we add a note to typecheck.TempAt to help
make people aware of this behavior.
Updates #73137Fixes#77339
Reviewed-on: https://go-review.googlesource.com/c/go/+/738822
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Change-Id: I80e89ca95ba297b0d95f02782e6f4ae901a4361a
Reviewed-on: https://go-review.googlesource.com/c/go/+/740600
Reviewed-by: Austin Clements <austin@google.com>
Auto-Submit: Junyang Shao <shaojunyang@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
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>
(cherry picked from commit 83b232b0af)
Reviewed-on: https://go-review.googlesource.com/c/go/+/739922
Reviewed-by: Junyang Shao <shaojunyang@google.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>
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-internal-review.googlesource.com/c/go/+/3346
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/736708
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Bypass: Michael Pratt <mpratt@google.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-internal-review.googlesource.com/c/go/+/3345
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/736707
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Bypass: Michael Pratt <mpratt@google.com>
Reviewed-by: Junyang Shao <shaojunyang@google.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-internal-review.googlesource.com/c/go/+/3341
Reviewed-by: Neal Patel <nealpatel@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/736705
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Bypass: Michael Pratt <mpratt@google.com>
Reviewed-by: Junyang Shao <shaojunyang@google.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-internal-review.googlesource.com/c/go/+/3340
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/736704
TryBot-Bypass: Michael Pratt <mpratt@google.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Auto-Submit: Michael Pratt <mpratt@google.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>
Merge List:
+ 2026-01-07 f6ebd91129 all: update vendored x/tools
+ 2026-01-06 d1d0fc7a97 os/exec: avoid atomic.Bool for Cmd.startCalled
+ 2026-01-05 9b2e3b9a02 simd/archsimd: use V(P)MOVMSK for mask ToBits if possible
+ 2026-01-02 f8ee0f8475 cmd/go/testdata/vcstest/git: use git commands that work on older git versions
+ 2026-01-02 b094749bad test/codegen: codify bit related code generation for arm64
+ 2026-01-02 e84983fa40 cmd/compile: optimize SIMD IsNaN.Or(IsNaN)
+ 2026-01-02 8244b85677 simd/archsimd: add tests for IsNaN
+ 2026-01-02 13440fb518 simd/archsimd: make IsNaN unary
+ 2026-01-02 c3550b3352 simd/archsimd: correct documentation of Mask types
+ 2026-01-02 34ad26341d net/rpc: correct comment for isExportedOrBuiltinType function
+ 2025-12-30 b28808d838 cmd/go/internal/modindex: fix obvious bug using failed type assertion
+ 2025-12-30 d64add4d60 simd/archsimd: adjust documentations slightly
+ 2025-12-30 1843cfbcd6 runtime/secret: make tests more sturdy
+ 2025-12-30 fd45d70799 all: fix some minor grammatical issues in the comments
+ 2025-12-30 df4e08ac65 test/codegen: fix a tab in comparisons.go to ensure pattern works
+ 2025-12-30 cd668d744f cmd/compile: disable inlining for functions using runtime.deferrangefunc
+ 2025-12-29 06eff0f7c3 simd/archsimd: add tests for Saturate-Concat operations
+ 2025-12-29 110aaf7137 simd/archsimd: add tests for Saturate operations
+ 2025-12-29 22e7b94e7f simd/archsimd: add tests for ExtendLo operations
+ 2025-12-29 76dddce293 simd/archsimd: remove redundant suffix of ExtendLo operations
+ 2025-12-29 6ecdd2fc6e simd/archsimd: add more tests for Convert operations
+ 2025-12-29 e0c99fe285 simd/archsimd: add more tests for Truncate operations
+ 2025-12-29 08369369e5 reflect: document Call/CallSlice panic when v is unexported field
+ 2025-12-29 ca8effbde1 internal/coverage/decodemeta: correct wording in unknown version error
+ 2025-12-29 0b06b68e21 encoding/gob: clarify docs about pointers to zero values not being sent
+ 2025-12-29 9cb3edbfe9 regexp: standardize error message format in find_test.go
+ 2025-12-29 b3ed0627ce tests: improve consistency and clarity of test diagnostics
+ 2025-12-29 3dcb48d298 test: follow got/want convention in uintptrescapes test
+ 2025-12-29 f7b7e94b0a test: clarify log message for surrogate UTF-8 check
+ 2025-12-29 e790d59674 simd/archsimd: add tests for Truncate operations
+ 2025-12-27 f4cec7917c cmd: fix unused errors reported by ineffassign
+ 2025-12-27 ca13fe02c4 simd/archsimd: add more tests for Convert operations
+ 2025-12-27 037c047f2c simd/archsimd: add more tests for Extend operations
+ 2025-12-26 7971fcdf53 test/codegen: tidy tests for bits
+ 2025-12-24 0f620776d7 simd/archsimd: fix "go generate" command
+ 2025-12-24 a5fe8c07ae simd/archsimd: guard test helpers with amd64 tag
+ 2025-12-23 a23d1a4ebe bytes: improve consistency in split test messages
+ 2025-12-23 866e461b96 cmd/go: update pkgsite doc command to v0.0.0-20251223195805-1a3bd3c788fe
+ 2025-12-23 08dc8393d7 time: skip test that will fail with GO111MODULE=off
+ 2025-12-23 43ebed88cc runtime: improve a log message in TestCleanupLost
+ 2025-12-23 81283ad339 runtime: fix nGsyscallNoP accounting
+ 2025-12-23 3e0e1667f6 test/codegen: codify bit related code generation for riscv64
+ 2025-12-23 3faf988f21 errors: add a test verifying join does not flatten errors
+ 2025-12-23 2485a0bc2c cmd/asm/internal/asm: run riscv64 end-to-end tests for each profile
+ 2025-12-23 8254d66eab cmd/asm/internal/asm: abort end to end test if assembly failed
+ 2025-12-23 1b3db48db7 Revert "errors: optimize errors.Join for single unwrappable errors"
+ 2025-12-23 b6b8b2fe6e cmd/compile: handle propagating an out-of-range jump table index
+ 2025-12-22 2cd0371a0a debug/pe: avoid panic in File.ImportedSymbols
+ 2025-12-22 91435be153 runtime: revert entry point on freebsd/arm64
+ 2025-12-22 c1efada1d2 simd/archsimd: correct documentation for pairwise operations
+ 2025-12-22 3d77a0b15e os/exec: second call to Cmd.Start is always an error
+ 2025-12-20 7ecb1f36ac simd/archsimd: add HasAVX2() guards to tests that need them
+ 2025-12-19 70c22e0ad7 simd/archsimd: delete DotProductQuadruple methods for now
+ 2025-12-19 42cda7c1df simd/archsimd: add Grouped for 256- and 512-bit SaturateTo(U)Int16Concat, and fix type
+ 2025-12-19 baa0ae3aaa simd/archsimd: correct type and instruction for SaturateToUint8
+ 2025-12-19 d46c58debb go/doc: link to struct fields in the same package
+ 2025-12-19 25ed6c7f9b cmd/go/internal/doc: update pkgsite version
+ 2025-12-19 4411edf972 simd/archsimd: reword documentation for some operations
+ 2025-12-19 7d9418a19c simd/archsimd: reword documentation of comparison operations
+ 2025-12-18 d00e96d3ae internal/cpu: repair VNNI feature check
+ 2025-12-18 cfc024daeb simd/archsimd: reword documentation for conversion ops
+ 2025-12-17 ad91f5d241 simd/archsimd: reword documentation of shfit operations
+ 2025-12-17 b8c4cc63e7 runtime: keep track of secret allocation size
+ 2025-12-17 8564fede89 cmd/go: remove reference to no longer existing -i flag
+ 2025-12-17 eecdb61eeb crypto: rename fips140v2.0 to fips140v1.26
+ 2025-12-17 05e41225f6 simd/archsimd: reword documentation of As methods
+ 2025-12-17 516699848b runtime/secret: warn users about allocations, loosen guarantees
+ 2025-12-16 8c28ab936a cmd/cgo: don't emit C local if it is not used
+ 2025-12-16 65b71c11d4 crypto/internal/fips140only: test fips140=only mode
+ 2025-12-16 ea1aa76554 go/doc: exclude examples with results
+ 2025-12-16 5046bdf8a6 crypto/tls: reject trailing messages after client/server hello
+ 2025-12-16 3f6eabdf09 cmd/compile: use unsigned constant when folding loads for SIMD ops with constants
+ 2025-12-16 a4b5b92055 cmd/dist: preserve existing GOEXPERIMENTs when running tests with additional experiments
Change-Id: I84ad4ceba344761142b98587c07d186cf2d638ff
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>
Merge List:
+ 2025-12-15 d14b6427cf cmd/link: set canUsePlugins only on platforms that support plugin
+ 2025-12-15 9ba0948172 cmd/link: don't create __x86.get_pc_thunk symbol if it already exists
+ 2025-12-15 b7944a5f80 text/template: fix slice builtin for pointers to arrays
+ 2025-12-15 6713f46426 archive/tar, compress/bzip2: base64 some troublesome testdata files
+ 2025-12-15 388eb10f50 cmd/go: show comparable in go doc interface output
+ 2025-12-13 1b291b70df simd/archsimd: skip tests if AVX is not available
+ 2025-12-12 d30884ba1f cmd/dist: test GOEXPERIMENT=simd on AMD64
+ 2025-12-12 ee0275d15b runtime, cmd/link: tighten search for stackObjectRecord
+ 2025-12-12 63fced531c runtime/secret: restore goroutine behavior to proposal
+ 2025-12-12 6455afbc6f runtime: dropg after emitting trace event in preemptPark
+ 2025-12-12 8f45611e78 runtime/pprof: deflake TestGoroutineLeakProfileConcurrency
+ 2025-12-12 34af879dde cmd/link: add new linknames to blocked linkname list
+ 2025-12-12 8d31244562 runtime/secret: guard files with goexperiment
+ 2025-12-12 e8a83788a4 go/doc: reuse import name logic for examples
+ 2025-12-11 927c89bbc5 cmd/compile: update ABI document for riscv64
+ 2025-12-11 245bcdd478 runtime: add extra subtest layer to TestFinalizerOrCleanupDeadlock
+ 2025-12-11 ae62a1bd36 Revert "database/sql: allow drivers to override Scan behavior"
+ 2025-12-11 89614ad264 runtime/trace: fix broken TestSubscribers
+ 2025-12-11 bb2337f24c cmd/go: set GOOS in vet_asm test
+ 2025-12-11 2622d2955b go/types, types2: remove indirection of Named.finite
+ 2025-12-11 5818c9d714 encoding/json/jsontext: add symbolic Kind constants
+ 2025-12-11 9de6468701 json/jsontext: normalize all invalid Kinds to 0
+ 2025-12-11 00642ee23b encoding/json: report true from v2 Decoder.More when an error is pending
+ 2025-12-11 7b60d06739 lib/time: update to 2025c/2025c
+ 2025-12-11 1de9585be2 runtime: prevent calls to GOMAXPROCS while clearing P trace state
+ 2025-12-11 e38c38f0e5 internal/trace: correctly handle GoUndetermined for GoroutineSummary
+ 2025-12-11 c0ba519764 simd/archsimd: rename Mask.AsIntMxN to Mask.ToIntMxN
+ 2025-12-11 f110ba540c simd/archsimd: define ToMask only on integer vectors
+ 2025-12-11 1da0c29c2a simd/archsimd: add package doc
+ 2025-12-11 f105dfd048 lib/fips140: freeze v1.1.0-rc1 FIPS 140 module zip file
+ 2025-12-11 af14f67911 runtime: make goroutines inherit DIT state, don't lock to OS thread
+ 2025-12-11 72c83bcc80 go/types, types2: put Named.finite behind Named.mu
+ 2025-12-10 b2a697bd06 all: update to x/crypto@7dacc380ba
+ 2025-12-10 fc66a5655b crypto: clean up subprocess-spawning tests
+ 2025-12-10 b130dab792 crypto/hpke: apply fips140.WithoutEnforcement to ML-KEM+X25519 hybrid
+ 2025-12-10 c39fe18fea crypto/mlkem/mlkemtest: error out in fips140=only mode
+ 2025-12-10 db0ab834d6 crypto/hpke: don't corrupt enc's excess capacity in DHKEM decap
+ 2025-12-10 cd873cf7e9 crypto/internal/fips140/aes/gcm: don't panic on bad nonces out of FIPS 140-3 mode
+ 2025-12-10 550c0c898b crypto/hpke: use new gcm.NewGCMForHPKE for FIPS 140-3 compliance
+ 2025-12-10 d349854de6 crypto/internal: ACVP test data migrated to Geomys repo
+ 2025-12-10 cd9319ff8e runtime: use correct function name in methodValueCallFrameObjs comment
+ 2025-12-10 0d71bd57c9 runtime: VZEROUPPER at the end of FilterNilAVX512
+ 2025-12-09 36bca3166e cmd: fix some issues in the comments
+ 2025-12-09 b9693a2d9a runtime: on AIX check isarchive before calling libpreinit
+ 2025-12-09 1274d58dac go/types, types2: add check for finite size at value observance
+ 2025-12-08 9e09812308 all: REVERSE MERGE dev.simd (c456ab7) into master
+ 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 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 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 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 3417b48b17 [dev.simd] simd: add carryless multiply
+ 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 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: Iaf3a44bb5ada83b0f056032839f5dd0fcdb2294f
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>
CL 687815 recently added TestDebugLines_74576.
The pre-existing debug_lines_test.go file generally restricts the
tested architectures and contains multiple warnings that the
testing approach is useful but fragile, such as:
"These files must all be short because this is super-fragile."
Despite that, initially I wanted to see what happened on the
different architectures on the trybots in case it might show something
surprising, and I let TestDebugLines_74576 run on all architectures.
That seemed to initially work, but the test is now failing on a
linux/risc64 builder (#74669), so it is likely more prudent to be
more conservative and restrict the platforms like many of the
other pre-existing tests, which is what this CL now does.
Fixes#74669
Change-Id: I9e5a7d3ee901f58253cf72e03c2239df338479e6
Reviewed-on: https://go-review.googlesource.com/c/go/+/688856
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: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
The type-checking logic for append has a special case for
append(bytes, s...) where the typeset for s contains string.
However, this case was triggering even when the typeset contained
only []byte, causing the creation of Signature types of the form
func([]byte, Y) []byte, with the variadic flag set, where Y
is the type of Y (e.g. a type parameter constrained to ~[]byte).
This is an illegal combination: a variadic signature's last
parameter must be a slice, or its typeset must contain string.
This caused x/tools/go/ssa to crash.
This CL narrows the special case to only typesets that contain
string, and adds a test for the inferred signature.
(There's little point in testing that a subsequent NewSignatureType
call would succeed, because the inferred type plainly has
no free type parameters.)
Fixes#73871
Change-Id: Id7641104133371dd6b0077f281cdaa9db84cc1c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/688815
Reviewed-by: Mark Freeman <mark@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
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>
The literal rewriting optimizations to reduce user allocations
that were implemented in CL 649079 and related CLs like CL 684116
could produce .debug_line tables such that the line numbers
sometimes jumped back to a variable's declaration.
This CL adjusts the positions of the IR nodes to avoid this.
For the first test added here in i74576a.go:
11 func main() {
12 a := 1
13 runtime.Breakpoint()
14 sink = a
15 }
Without this fix, the test reports debug lines of 12, 13, 13, 12, 14.
Note it goes backwards from 13 to a second 12.
With this fix, the test reports debug lines of 12, 13, 13, 14
without going backwards.
The test added in i74576b.go creates a slice via make with a
non-constant argument, which similarly shows debug lines going backwards
before this fix but not after. To address the slice make case, we
create a new BasicLit node to then set its position.
There were some related allocation optimizations for struct literals
such as CL 649555 during the Go 1.25 dev cycle, but at least in some
basic test cases, those optimizations did not seem to produce
debug line issues. The struct literal interface conversion test
added in i74576c.go has the same behavior before and after this change.
Finally, running 'go test ./...' in the delve repo root (4a2a6e1aeb)
seems to have many failures with go1.25rc2, but seems to pass with
this CL.
Fixes#74576
Updates #71359
Change-Id: I31faf5fe4bb352fdcd06bdc8606dbdbc4bbd65f0
Reviewed-on: https://go-review.googlesource.com/c/go/+/687815
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Alessandro Arzilli <alessandro.arzilli@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
Escape analysis examines functions in batches. In some cases, closures
are in the same batch as their parent function, but in other cases,
the closures are in different batches. This can mean the per-batch
ir.ReassignOracle cache is not as effective.
For example, #74615 has 4,000 closures in a single function that
are all in different batches. For that example, these caches
had an ~80% hit rate.
This CL makes the ir.ReassignOracle cache more broadly scoped, instead
of per batch.
This speeds up escape analysis when a function has many closures
that end up in different batches, including this resolves#74615.
For that example, this cache now has a ~100% hit rate.
In addition, in (*batch).rewriteWithLiterals, we also slightly delay
checking the ir.ReassignOracle cache, which is more natural to do now
compared to when rewriteWithLiterals was first merged. This means we can
avoid consulting or populating the cache in more cases. (We also leave
a new type-related TODO there. If we were to also implement that TODO, a
quick test suggests we could independently resolve the specific example
in #74615 even without making the cache more broadly scoped,
though other conceivable examples would not be helped; the scoping of
the cache is the more fundamental improvement.)
If we look at cumulative time spent via pprof for the #74615 example
using this CL, the work of ir.ReassignOracle escape analysis
cache now typically shows zero cpu samples.
This CL passes "go build -toolexec 'toolstash -cmp' -a std cmd".
Fixes#74615
Change-Id: I3c17c527fbb546ffb8a4fa52cd61e41ff3cdb869
Reviewed-on: https://go-review.googlesource.com/c/go/+/688075
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Mui <cherryyz@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>
In the type descriptor's method table, it contains relative PCs of
the methods (relative to the start of the text section) stored as
32-bit offsets. On Wasm, a PC is PC_F<<16 + PC_B, where PC_F is
the function index, and PC_B is the block index. When there are
more than 65536 functions, the PC will not fit into 32-bit (and
relative to the section start doesn't help). Since there are no
more bits for the function index, and the method table always
targets the entry of a method, we put just the PC_F there, and
rewrite back to a full PC at run time when we need the PC. This
way we can have more than 65536 functions.
The func table also contains 32-bit relative PCs, and it also
always points to function entries. Do the same there, as well
as other places where we use relative text offsets.
Also add the relocation type in the relocation overflow error
message.
Also add check for function too big on Wasm. If a function has
more than 65536 blocks, PC_B will overflow and PC = PC_F<<16 + PC_B
will points to the wrong function.
Fixes#64856.
Change-Id: If9c307e9fb1641f367a5f19c39f88f455805d0bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/552835
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently, on Wasm, an indirect call is compiled to
// function index = PC>>16, PC is already on stack
I32WrapI64
I32Const $16
ShrU
// set PC_B to 0
...
// actual call
CallIndirect
Specifically, the function index is extracted from bits 16-31 of
the "PC". When there are more than 65536 functions, this will
overflow and wrap around, causing wrong function being called.
This CL changes it to use 64-bit operations to extract the
function index from the "PC", so there are enough bits to for it.
For #64856.
Change-Id: I83c11db4b78cf66250e88ac02a82bd13730a8914
Reviewed-on: https://go-review.googlesource.com/c/go/+/567896
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Clearing the inline mark bits with memclrNoHeapPointers is slightly
better than having the compiler insert, e.g. duffzero, since it can take
advantage of wider SIMD instructions. duffzero is likely going away, but
we know things the compiler doesn't, such as the fact that this memory
is nicely aligned. In this particular case, memclrNoHeapPointers does a
better job.
For #73581.
Change-Id: I3918096929acfe6efe6f469fb089ebe04b4acff5
Reviewed-on: https://go-review.googlesource.com/c/go/+/687938
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>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
This is conceptually simpler, as the sweeper doesn't have to worry about
clearing them separately. It also doesn't have a use for them.
This will also be useful to avoiding unnecessary zeroing in
initInlineMarkBits at allocation time. Currently, because it's used in
both span allocation and at sweep time, we cannot blindly trust
needzero.
This change also renames mergeInlineMarkBits to moveInlineMarkBits to
make this change in semantics clearer from the name.
For #73581.
Change-Id: Ib154738a945633b7ff5b2ae27235baa310400139
Reviewed-on: https://go-review.googlesource.com/c/go/+/687936
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>
Currently, with Green Tea GC, we need to copy (really bitwise-or) mark
bits back into mspan.gcmarkBits, so that it can propagate to
mspan.allocBits at sweep time. This function does actually seem to make
sweeping small spans a good bit more expensive, though sweeping is still
relatively cheap. There's some low-hanging fruit here though, in that
the merge is performed one byte at a time, but this is pretty
inefficient. We can almost as easily perform this merge one word at a
time instead, which seems to make this operation about 33% faster.
For #73581.
Change-Id: I170d36e7a2193199c423dcd556cba048ebd698af
Reviewed-on: https://go-review.googlesource.com/c/go/+/687935
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>
Expand the GOMAXPROCS documentation to include details of how defaults
are selected, as this is something that inquisitive minds will want to
know. I've added an additional warning that these details may changed.
While we are here, add a bit more structure to make it easier to find
the relevant parts of the documentation.
For #73193.
Change-Id: I6a6a636cae93237e3e3174822490d51805e70990
Reviewed-on: https://go-review.googlesource.com/c/go/+/685318
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Sean Liao <sean@liao.dev>
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>
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>
WARNING: This commit contains breaking changes
for those already using GOEXPERIMENT=jsonv2.
This decomposes FormatBytesWithLegacySemantics as:
* FormatBytesWithLegacySemantics
* FormatByteArrayAsArray
* ParseBytesWithLooseRFC4648
This decomposes FormatTimeWithLegacySemantics as:
* FormatDurationAsNano
* ParseTimeWithLooseRFC3339
In particular, it splits out specific behaviors from the option
that may need to be specified on a finer-grain level.
FormatByteArrayAsArray and FormatDurationAsNano are targeted
to just the default representation of a [N]byte or time.Duration type.
Both of these are not necessary if the `format` tag is explicitly specified.
However, we want to isolate their behavior from other behaviors that used to
be part of FormatBytesWithLegacySemantics and FormatTimeWithLegacySemantics.
ParseBytesWithLooseRFC4648 and ParseTimeWithLooseRFC3339 are targeted
to just historically buggy parsing according to the relevant RFCs,
which may need to be enabled by some services for backwards compatibility.
While FormatTimeWithLegacySemantics is deleted, we still need
FormatBytesWithLegacySemantics to configure highly esoteric
aspects of how v1 used to handle byte slices.
We rename OmitEmptyWithLegacyDefinition as OmitEmptyWithLegacySemantics
to be consistent with other options with the WithLegacySemantics suffix.
Updates #71497
Change-Id: Ic660515fb086fe3af237135f195736de99c2bd33
Reviewed-on: https://go-review.googlesource.com/c/go/+/685395
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
In the presence of invalid UTF-8, the AllowInvalidUTF8 option
allows such bytes to be present, but silently mangles them
using the Unicode replacement character.
The v2 default is to emit the replacement character verbatim
(which is valid UTF-8 and exactly what it is for).
However, the v1 behavior has historically been to emit
the escaped form of the replacement character.
This behavior was introduced in https://go.dev/cl/11211045
where the documentation says that it is:
replacing invalid bytes with the Unicode replacement rune U+FFFD
but the implementation actually replaces it with
the escaped form of the Unicode replacement rune.
Given that the documentation differs from the implementation,
the actual behavior is likely an oversight.
Given how esoteric of behavior this is,
we change the v1in2 behavior to avoid the unnecesary escaping
and drop support for EscapeInvalidUTF8.
This does not violate the Go compatibility agreement since
we do not document what the exact syntactic output is.
Also, there has already been prior precedence for changing the output:
* [encoding/json: encode \b and \f as '\b' and '\f' in JSON strings](https://go.dev/cl/521675)
* [encoding/json: encode \n in strings as "\n", not "\u000A"](https://go.dev/cl/4678046)
* [encoding/json: encode \t as \t instead of \u0009](https://go.dev/cl/162340043)
* [encoding/json: use standard ES6 formatting for numbers during marshal](https://go.dev/cl/30371)
Fixes#74551
Change-Id: Ib59a873c44713d302f1f6ab103ffba2520d63276
Reviewed-on: https://go-review.googlesource.com/c/go/+/687116
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
In the event that the input is just JSON whitespace,
the underlying jsontext.Decoder treats this as an empty stream
and reports io.EOF.
The logic in unmarshalFull simply casted io.EOF as io.ErrUnexpectedEOF,
which is inconsistent with how all other io.ErrUnexpectedEOF are reported,
which are wrapped within a jsontext.SyntacticError.
Do the same thing for consistency.
We add a v1 test (without goexperiment.jsonv2) to verify that
the behavior is identical to how v1 has always behaved.
We add a v1in2 test (with goexperiment.jsonv2) to verify that
the v1in2 behavior correctly replicates historical v1 behavior.
We also fix a faulty check in v1 Decoder.Decode,
where it tried to detect errUnexpectedEnd and
return an unwrapped io.ErrUnexpectedEOF error.
This is the exact semantic that v1 has always done
in streaming Decoder.Decode (but not non-streaming Unmarshal).
There is a prior bug reported in #25956 about this inconsistency,
but we aim to preserve historical v1 behavior to reduce
the probability of churn when v1 is re-implemented in terms of v2.
Fixes#74548
Change-Id: Ibca52c3699ff3c09141e081c85f853781a86ec8e
Reviewed-on: https://go-review.googlesource.com/c/go/+/687115
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
We claim to treat N as secret (and indeed bigmod is constant time in
relation to the modulus) but at the same time we warn that all inputs to
VerifyPKCS1v15 and Verify are public:
> The inputs are not considered confidential, and may leak through
> timing side channels, or if an attacker has control of part of the
> inputs.
See #67043 (which focuses on the inverse, recovering signatures by
controlling the public key input to Verify), and in particular
https://github.com/golang/go/issues/67043#issuecomment-2079335804.
Stopping the Verify adaptive attack would require significantly more
complexity, the kind that has caused vulnerabilities in the past (e.g.
CVE-2016-2107). On the other hand, assuming that a public key is
confidential is unlikely to work in practice, since it can be recovered
from just two valid (message, signature) pairs. See for example
https://keymaterial.net/2024/06/15/reconstructing-public-keys-from-signatures/.
This comment was introduced in CL 552935, not really due to a need to
specify that N was secret, but rather to clarify that E is not (so it
could be used in variable-time exponentiation).
Change-Id: I6a6a6964f3f8d2dc2fcc13ce938b271c9de9666b
Reviewed-on: https://go-review.googlesource.com/c/go/+/687616
Reviewed-by: Roland Shoemaker <roland@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
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
When we do a size fixup, we need to clone the symbol to an
external symbol so we can modify it. This includes cloning the
relocations, which includes resolving the relocations. If the
symbol being fixed has a relocation referencing a non-Go symbol,
that symbol has not yet been created, it will be resolved to an
empty symbol. Load the references first, so the referenced symbol,
even if it is a non-Go symbol, exists.
Fixes#74537.
Change-Id: I81525bd7c3e232b80eefeb0f18e13ba5331e1510
Reviewed-on: https://go-review.googlesource.com/c/go/+/687315
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
TestSignalDuringExec sends a SIGWINCH to the whole process group.
However, it may execute concurrently with other copies of the runtime
tests, especially through `go tool dist`, and gdb version <12.1 has a
bug in non-interactive mode where recieving a SIGWINCH causes a crash.
This change modifies SignalDuringExec in the testprog to first fork
itself into a new process group. To avoid issues with Ctrl+C and the new
process group hanging, the new process blocks on a pipe that is passed
down to it. This pipe is automatically closed when its parent exits,
which should ensure that the subprocess also exits.
Fixes#58932.
Change-Id: I3906afa28cf8b15d22ae612d071bce7f30fc3e6c
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest-noswissmap,gotip-linux-amd64-longtest-aliastypeparams,gotip-linux-amd64-longtest,gotip-linux-386-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/686875
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
When a TLS server uses the information from the server_name extension in
a client hello, and the connection isn't resuming, it should return an
empty server_name extension in its server hello (or encrypted extensions
for TLS 1.3).
For TLS <1.3 we we do this in doFullHandshake(), by setting the
pre-existing serverHelloMsg.serverNameAck bool. We know that the
connection isn't resuming based on the context where this function is
called.
For TLS 1.3, a new encryptedExtensionsMsg.serverNameAck bool is added,
and populated as appropriate in sendServerParameters() based on whether
the conn was resumed or not. The encryptedExtensionsMsg marshalling is
updated to emit the encrypted extension based on that field.
These changes allow enabling the ServerNameExtensionServer-* bogo tests
that verify both the presence and absence of the server_name extension
based on the relevant specifications.
Resolves#74282
Updates #72006
Change-Id: I703bc2ec916b50906bdece7b7483a7faed7aa8e4
Reviewed-on: https://go-review.googlesource.com/c/go/+/684795
TryBot-Bypass: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Auto-Submit: Daniel McCarney <daniel@binaryparadox.net>
Removes the somewhat redundant vcs.FromDir, "allowNesting" argument,
which was always enabled, and disallow multiple VCS metadata folders
being present in a single directory. This makes VCS injection attacks
much more difficult.
Also adds a GODEBUG, allowmultiplevcs, which re-enables this behavior.
Thanks to RyotaK (https://ryotak.net) of GMO Flatt Security Inc for reporting this issue.
Fixes#74380
Fixes CVE-2025-4674
Change-Id: I5787d90cdca8deb3aca6f154efb627df1e7d2789
Reviewed-on: https://go-review.googlesource.com/c/go/+/686515
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Commit-Queue: Carlos Amedee <carlos@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Currently, the test change made for the fix to #68090 is flaky. This is
because the sync-point-only goroutine that we expect to be sync
preempted might only ever get async preempted in some circumstances.
This change adds a variant to all trace tests to run with
asyncpreemptoff=1, and the stacks test, the flaky one, only actually
checks for the sync-point in the trace when async preemption is
disabled.
Fixes#74417.
Change-Id: Ib6341bbc26921574b8f0fff6dd521ce83f85499c
Reviewed-on: https://go-review.googlesource.com/c/go/+/686055
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Use the goCmd() function to get the go command to invoke, so that when
GOROOT is set, the go command that's invoked uses the same GOROOT.
Otherwise there will be skew between the go command and the tools and
runtime. Also use the environment when determining GOPROXY and
GOMODCACHE, and use url.Join so the slashes in 'http://' aren't
collapsed into one.
Change-Id: Ie36ca2fffdb015a7f5f9bd7f514850e41fad2c1a
Reviewed-on: https://go-review.googlesource.com/c/go/+/685319
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>
In CL 226937 I refactored the RSA-PSS implementation, and apparently
left behind a note to think a bit harder about whether this bytes.Equal
check should be constant time or not. It snuck through code review, so
it's 2018 again, no one is worried about pandemics, I have just joined
Google, and I am mailing CL 147637 again.
Anyway, as discussed in #67043 and documented in CL 587277, the inputs
to signature verification functions are not secret, and are allowed to
leak through timing side channels. This means an attacker can already
compute h (from signature and public key) and h0 (from message hash and
public key). What the attacker can't do is produce a signature that
yields the correct h (since that requires the private key).
Change-Id: I6a6a4656d6255bdad628a94f48f7ea878a304263
Reviewed-on: https://go-review.googlesource.com/c/go/+/685255
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
The TestStmtLines test has been accessing a nil pointer when it
tries to look up LineEntry.File.Name on a line entry with
EndSequence set to true. The doc for EndSequence specifies that if
EndSequence is set, only it and the Address field are meaningful. Skip
the entries with EndSequence set when building the set of files.
I've reproduced this issue locally.
Probably also fixes#49372, but will leave that for a follow-up CL.
Fixes#74475
Updates #49372
Change-Id: Ic0664f7652b52a0a20239d13fe16454622740821
Reviewed-on: https://go-review.googlesource.com/c/go/+/685835
Reviewed-by: Than McIntosh <thanm@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Bypass: Dmitri Shuralyov <dmitshur@golang.org>
Auto-Submit: Quim Muntal <quimmuntal@gmail.com>
CL 502615 modified go/build to check for invalid import paths, but did
not make those changes to the corresponding code in the modindex
package. Apply those changes here.
We should try to deduplicate the code to prevent this from happening
again.
For #73976
For #74446
Change-Id: I69fc5e2c829efb818c9974ec8126807a1c8f7913
Reviewed-on: https://go-review.googlesource.com/c/go/+/685317
TryBot-Bypass: Michael Matloob <matloob@google.com>
Auto-Submit: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Matloob <matloob@google.com>
The jsonopts.Struct.join method unfortunately escapes
the receiver because it is passed to JoinUnknownOption,
which is a dynamically implemented function.
This affects jsontext.Encoder.reset and jsontext.Decoder.reset,
which relied on a local jsonopts.Struct to temporarily store
prior options such that it would have to be heap allocated.
Adjust the signature of JoinUnknownOption to avoid pointers
so that nothing escape.
This is a regression from
https://github.com/go-json-experiment/json/pull/163
Performance:
name old time/op new time/op delta
Marshal/Bool-32 72.1ns ± 2% 51.3ns ± 1% -28.77% (p=0.000 n=10+9)
name old allocs/op new allocs/op delta
Marshal/Bool-32 2.00 ± 0% 1.00 ± 0% -50.00% (p=0.000 n=10+10)
Updates #71845
Change-Id: Ife500d82d3d2beb13652553a4ffdf882c136f5a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/685135
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
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>
Several CLs earlier in this stack added optimizations to reduce
user allocations by recognizing and taking advantage of literals,
including CL 649555, CL 649079, and CL 649035.
This CL adds debug hashing of those changes, which enables use of the
bisect tool, such as 'bisect -compile=literalalloc go test -run=Foo'.
This also allows these optimizations to be manually disabled via
'-gcflags=all=-d=literalallochash=n'.
Updates #71359
Change-Id: I854f7742a6efa5b17d914932d61a32b2297f0c88
Reviewed-on: https://go-review.googlesource.com/c/go/+/675415
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>
CL 649079 and CL 649035 updated escape analysis to rewrite certain
expressions in OMAKE and OCONVIFACE nodes as optimizations to
reduce user allocations.
Part of the change in CL 649079 disabled those optimzations when
coverage instrumentation was enabled under an incorrect possible theory
of how those optimizations might be "expected" to change coverage
results -- in particular, the cover_build_pkg_select.txt testscript
failed with different coverage results. I now realize that the proper
explanation is that my fix in CL 684116 was needed.
Now that CL 684116 is merged, we should no longer disable these
optimizations when coverage is enabled, which is what this CL does.
This has not been reported as a problem to my knowledge, but without
this CL, one could imagine for example a test using testing.AllocsPerRun
might start failing when coverage was enabled if the result relied on
these optimizations.
As expected, if we place this CL just before the necessary fix in
CL 684116, the cover_build_pkg_select.txt testscript fails with a
changed coverage result. If we place this CL just after CL 684116,
the test passes, also as expected.
Updates #71359
Change-Id: Ib5ff00c267acd85dd423c238d177e91a4d881f9e
Reviewed-on: https://go-review.googlesource.com/c/go/+/684777
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This commit updates the pinned revision of BoringSSL that's used for the
BoGo integration test.
Doing this requires a few categories of config changes:
* ignoring a few new tests for features crypto/tls doesn't implement
* ignoring a few new tests that require further
investigation/classification, or that already have an associated
tracking issue
* updating the error map syntax to accommodate the upstream change that
allows a one-to-many mapping
One code change is required in the shim test process to adjust how we
tear down a connection after an error to account for an upstream change
in the test runner.
Previously, for error conditions we would immediately close the
connection when exiting the shim process. We instead need to do this in
a multi-step process:
1. Flush any pending TLS writes to surface any alerts the error
condition may have generated.
2. Close the write side of the TCP connection to signal we're not
writing anymore.
3. Read and discard any pending data from the peer.
4. Close the read side of the TCP connection to fully close the socket.
Without doing this unpredictable timing factors may result in spurious
test failures where:
1. The runner sends us data that produces an error.
2. We send an alert, and immediately tear down the connection.
3. The runner tries to perform a write, and hits an error because the
pipe is closed.
4. The runner fails the test with the pipe write error, before it reads
from the connection to see the expected alert.
With the new code we instead swallow the unrelated writes and the runner
sees our alert after its ignored write when it tries to read from the
conn. The alert is the expected test outcome, and so the test passes.
This was previously not an issue because the runner was discarding the
write errors.
Updates #72006
Change-Id: Ib72a1c5e693aac92144696c8bae888d5f3f6c32f
Reviewed-on: https://go-review.googlesource.com/c/go/+/683456
Auto-Submit: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
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>
findRunnable takes a snapshot of allp prior to dropping the P because
afterwards procresize may mutate allp without synchronization.
procresize is careful to never mutate the contents up to cap(allp), so
findRunnable can still safely access the Ps in the slice.
Unfortunately, growing allp is problematic. If procresize grows the allp
backing array, it drops the reference to the old array. allpSnapshot
still refers to the old array, but allpSnapshot is on the system stack
in findRunnable, which also likely no longer has a P at all.
This means that a future GC will not find the reference and can free the
array and use it for another allocation. This would corrupt later reads
that findRunnable does from the array.
The fix is simple: the M struct itself is reachable by the GC, so we can
stash the snapshot in the M to ensure it is visible to the GC.
The ugliest part of the CL is the cleanup when we are done with the
snapshot because there are so many return/goto top sites. I am tempted
to put mp.clearAllpSnapshot() in the caller and at top to make this less
error prone, at the expensive of extra unnecessary writes.
Fixes#74414.
Change-Id: I6a6a636c484e4f4b34794fd07910b3fffeca830b
Reviewed-on: https://go-review.googlesource.com/c/go/+/684460
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Fix a race condition in disassociating a WaitGroup in a synctest
bubble from its bubble. We previously disassociated the WaitGroup
when count becomes 0, but this causes problems when an Add call
setting count to 0 races with one incrementing the count.
Instead, disassociate a WaitGroup from its bubble when Wait returns.
Wait must not be called concurrently with an Add call with a
positive delta and a 0 count, so we know that the disassociation
will not race with an Add call trying to create a new association.
Fixes#74386
Change-Id: I9b519519921f7691869a64a245a5ee65d071d054
Reviewed-on: https://go-review.googlesource.com/c/go/+/684635
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.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>
On Windows, GOMODCACHE almost never starts with a slash, and
"go doc -http" constructs a GOPROXY URL by doing "file://" + GOMODCACHE,
resulting in an invalid file URI.
For example, if GOMODCACHE is "C:\foo", then the file URI should be
"file:///C:/foo", but it becomes "file://C:/foo" instead, where "C:" is
understood as a host name, not a drive letter.
Fixes#74137.
Change-Id: I23e776e0f649a0062e01d1a4a6ea8268ba467331
Reviewed-on: https://go-review.googlesource.com/c/go/+/684575
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Michael Matloob <matloob@google.com>
The NeedmDeadlock test program currently has a 5-second timeout,
which is sort of arbitrary. It is long enough in regular mode
(which usually takes 0.0X seconds), but not quite so for
configurations like ASAN. Instead of using an arbitrary timeout,
just use the test's deadline. The test program is invoked with
testenv.Command, which will send it a SIGQUIT before the deadline
expires.
Fixes#56420 (at least for the asan builder).
Change-Id: I0b13651cb07241401837ca2e60eaa1b83275b093
Reviewed-on: https://go-review.googlesource.com/c/go/+/684697
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
In the Go language a type assertion of a nil interface value
will always report false:
var err error
v, ok := err.(error) // always reports (nil, false)
Consequently, assertion on a reflect.Value.Interface()
will also report false:
var err error
rv := ValueOf(&err).Elem()
v, ok := rv.Interface().(error) // reports (nil, false)
However, prior to this change, a TypeAssert would report true:
var err error
rv := ValueOf(&err).Elem()
v, ok := TypeAssert[error](rv) // reports (nil, true)
when it should report false.
This fixes TypeAssert to match the Go language by
pushing the typ != v.typ check to the very end after
we have validated that neither v nor T are interface kinds.
Fixes#74404
Change-Id: Ie14d5cf18c8370c3e27ce4bdf4570c89519d8a16
Reviewed-on: https://go-review.googlesource.com/c/go/+/684675
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Mateusz Poliwczak <mpoliwczak34@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
On Windows, the process might not have read permission on the parent
directory, but still can delete files in it. This change allows
RemoveAll to open the parent directory with minimal permissions, which
is sufficient for deleting child files.
Fixes#74134.
Cq-Include-Trybots: luci.golang.try:gotip-windows-amd64-longtest,gotip-windows-arm64
Change-Id: I5d5c5977caaebf6e0f93fb2313b0ceb346f70e05
Reviewed-on: https://go-review.googlesource.com/c/go/+/684515
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>
Add a section to the package doc which details the security
considerations of using encoding/json, in particular with respect to
parser misalignment issues.
Additionally, clarify previously ambiguous statement in the Unmarshal
doc about how case is used when matching keys in objects, and add a note
about how duplicate keys are handled.
Fixes#14750
Change-Id: I66f9b845efd98c86a684d7333b3aa8a456564922
Reviewed-on: https://go-review.googlesource.com/c/go/+/684315
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
Auto-Submit: Roland Shoemaker <roland@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
If a goroutine is synchronously preempted, then taking a
frame-pointer-based stack trace at that preemption will skip PC of the
caller of the function which called into morestack. This happens because
the frame pointer is pushed to the stack after the preamble, leaving the
stack in an odd state for frame pointer unwinding.
Deal with this by marking a goroutine as synchronously preempted and
using that signal to load the missing PC from the stack. On LR platforms
this is available in gp.sched.lr. On non-LR platforms like x86, it's at
gp.sched.sp, because there are no args, no locals, and no frame pointer
pushed to the SP yet.
For #68090.
Change-Id: I73a1206d8b84eecb8a96dbe727195da30088f288
Reviewed-on: https://go-review.googlesource.com/c/go/+/684435
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Nick Ripley <nick.ripley@datadoghq.com>
The existing js/wasm implementation of RoundTrip calls abort() on the
fetch() call when the context is canceled but does not wait for for the
resulting promise to be rejected. The result is the failure callback for the
promise will be called at some later point in time when the promise
rejection is handled. In some case this callback may be called after the Go
program has exited resulting in "Go program has already exited" errors.
Fixes#57098
Change-Id: Ia37fd22cb9f667dbb0805ff5db0ceb8fdba7246b
Reviewed-on: https://go-review.googlesource.com/c/go/+/680937
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Currently, if there is a BSS reference and a DATA symbol
definition with the same name, we pick the DATA symbol, as it
contains the right content. In this case, if the BSS reference
has a larger size, we error out, because it is not safe to access
a smaller symbol as if it has a larger size.
Sometimes code declares a global variable in Go and defines it
in assembly with content. They are expected to be of the same
size. However, in ASAN mode, we insert a red zone for the variable
on the Go side, making it have a larger size, whereas the assembly
symbol is unchanged. This causes the Go reference (BSS) has a
larger size than the assembly definition (DATA). It results in an
error currently. This code is valid and safe, so we should permit
that.
We support this case by increasing the symbol size to match the
larger size (of the BSS side). The symbol content (from the DATA
side) is kept. In some sense, we merge the two symbols. When
loading symbols, it is not easy to change its size (as the object
file may be mapped read-only), so we add it to a fixup list, and
fix it up later after all Go symbols are loaded. This is a very
rare case, so the list should not be long.
We could limit this to just ASAN mode. But it seems okay to allow
this in general. As long as the symbol has the larger size, it is
safe to access it with the larger size.
Fixes#74314.
Change-Id: I3ee6e46161d8f59500e2b81befea11e563355a57
Reviewed-on: https://go-review.googlesource.com/c/go/+/684236
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
CL 649035 and CL 649079 updated escape analysis to rewrite
certain operands in OMAKE and OCONVIFACE nodes from non-constant
expressions to basic literals that evaluate to the same value.
However, when doing that rewriting, we need to evaluate any
side effects prior to replacing the expression, which is what
this CL now does.
Issue #74379 reported a problem with OCONVIFACE nodes due to CL 649079.
CL 649035 has essentially the same issue with OMAKE nodes. To illustrate
that, we add a test for the OMAKE case in fixedbugs/issue74379b.go,
which fails without this change. To avoid introducing an unnecessary
temporary for OMAKE nodes, we also conditionalize the main work of
CL 649035 on whether the OMAKE operand is already an OLITERAL.
CL 649555 and CL 649078 were related changes that created read-only
global storage for composite literals used in an interface conversion.
This CL adds a test in fixedbugs/issue74379c.go to illustrate
that they do not have the same problem.
Updates #71359Fixes#74379
Change-Id: I6645575ef34f1fe2b0241a22dc205875d66b7ada
Reviewed-on: https://go-review.googlesource.com/c/go/+/684116
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Keith Randall <khr@google.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>
This follows the precedent set by:
bufio.Writer.AvailableBuffer
bytes.Buffer.AvailableBuffer
both with methods that return a zero-length buffer that
is intended to only be used with a following Write call.
This keeps the older UnusedBuffer method around so that
at least one commit that has both methods for migration purposes.
Updates #71497
Change-Id: I3815f593e09f645280ae5ad9cbdd63a6c147123b
Reviewed-on: https://go-review.googlesource.com/c/go/+/683896
Reviewed-by: Damien Neil <dneil@google.com>
TryBot-Bypass: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@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
The hugo binary gets slower, potentially dramatically so, with
GOEXPERIMENT=greenteagc. The root cause is page mapping churn. The Green
Tea code introduced a new implicit nil check on value in a
freshly-allocated span to clear some new heap metadata. This nil check
would read the fresh memory, causing Linux to back that virtual address
space with an RO page. This would then be almost immediately written to,
causing Linux to possibly flush the TLB and find memory to replace that
read-only page (likely deduplicated as just the zero page).
This CL fixes the issue by replacing the implicit nil check, which is a
memory read expected to fault if it's truly nil, with an explicit one.
The explicit nil check is a branch, and thus makes no reads to memory.
The result is that the hugo binary no longer gets slower.
No regression test because it doesn't seem possible without access to OS
internals, like Linux tracepoints. We briefly experimented with RSS
metrics, but they're inconsistent. Some system RSS metrics count the
deduplicated zero page, while others (like those produced by
/proc/self/smaps) do not.
Instead, we'll add a new benchmark to our benchmark suite, separately.
For #73581.
Fixes#74375.
Change-Id: I708321c14749a94ccff55072663012eba18b3b91
Reviewed-on: https://go-review.googlesource.com/c/go/+/684015
Reviewed-by: Keith Randall <khr@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: Keith Randall <khr@google.com>
When an application calls runtime.GOMAXPROCS(runtime.GOMAXPROCS(0)), the
runtime does not need to change the actual GOMAXPROCS value (via STW).
However, this call must still transition from "automatic" to "custom"
GOMAXPROCS state, thus disabling background updates.
Thus this case shouldn't return quite as early as it currently does.
Change-Id: I6a6a636c42f73996532bd9f7beb95e933256c9e7
Reviewed-on: https://go-review.googlesource.com/c/go/+/683815
Reviewed-by: 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>
Auto-Submit: Michael Pratt <mpratt@google.com>
There is a non-public zstd decoder in the stdlib (CL 473356) and
also zstd compressed testdata already present.
Delete testdata/code.json.gz and
instead use internal/jsontest/testdata/golang_source.json.zst,
which has exactly the same content:
$ cat internal/jsontest/testdata/golang_source.json.zst | zstd -d | sha1sum
3f70b6fd429f4aba3e8e1c3e5a294c8f2e219a6e -
$ cat testdata/code.json.gz | zstd -d | sha1sum
3f70b6fd429f4aba3e8e1c3e5a294c8f2e219a6e -
This will reduce the size of the final Go release by 118KB.
Updates #71845
Change-Id: I6da2df27bd260befc0a44c6bc0255365be0a5b0f
Reviewed-on: https://go-review.googlesource.com/c/go/+/525516
Auto-Submit: Damien Neil <dneil@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Bypass: Damien Neil <dneil@google.com>
Based on the discussion in #71631, it is hotly contested
whether the default JSON representation for a Go time.Duration
should be the time.Duration.String format or
a particular profile of ISO 8601.
Regardless of the default, it seems clear that we should
at least support ISO 8601 if specified via a format flag.
Note that this CL does not alter the default representation.
Unfortunately, ISO 8601 is a large and evolving standard
with many optional extensions and optional restrictions.
Thus, the term "ISO 8601 duration" unfortunately does not
resolve to a particular grammar, nor one that is stable.
However, there is precedence that we can follow in this matter.
JSON finds its heritage in JavaScript and
JavaScript is adding a Temporal.Duration type whose default
JSON representation is ISO 8601.
There is a well-specified grammar for their particular
profile of ISO 8601, which is documented at:
https://tc39.es/proposal-temporal/#prod-Duration
This particular CL adds support for ISO 8601 according to
the exact same grammar that JavaScript uses.
While Temporal.Duration is technically still a proposal,
it is already in stage 3 of the TC39 proposal process
(i.e., "no changes to the proposal are expected"
and "has been recommended for implementation")
and therefore close to final adoption.
One major concern with ISO 8601 is that it supports
nominal date units like years, months, weeks, and days
that do not have an accurate meaning without being
anchored to a particular point in time and place on Earth.
Fortunately, JavaScript (by default) avoids producing
Temporal.Duration values with nominal units unless
arithmetic in JavaScript explicitly sets a largestUnits
value that is larger than "hours". In the Go implementation,
we support syntactically parsing the full ISO 8601 grammar
(according to JavaScript), but semantically report an error if
nominal units are present. This ensures that ISO 8601 durations
remain accurate so long as they only use the accurate units
of hours, minutes, or seconds.
Updates #71631
Change-Id: I983593662f2150461ebc486a5acfeb72f0286939
Reviewed-on: https://go-review.googlesource.com/c/go/+/682403
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
In this blog:
https://blog.trailofbits.com/2025/06/17/unexpected-security-footguns-in-gos-parsers/
the concern was raised that whenever "-" is combined with other options,
the "-" is intepreted as as a name, rather than an ignored field,
which may go contrary to user expectation.
Static analysis demonstrates that there are ~2k instances of `json:"-,omitempty"
in the wild, where almost all of them intended for the field to be ignored.
To prevent this footgun, reject any tags that has "-," as a prefix
and warn the user to choose one of the reasonable alternatives.
The documentation of json/v2 already suggests `json:"'-'"`
as the recommended way to explicitly specify dash as the name.
See Example_fieldNames for example usages of the single-quoted literal.
Update the v1 json documentation to suggest the same thing.
Updates #71497
Change-Id: I7687b6eecdf82a5d894d057c78a4a90af4f5a6e4
Reviewed-on: https://go-review.googlesource.com/c/go/+/683175
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
This also updates wasip1_wasm to use a 8MiB stack, which is
the same stack size as what is used by go_js_wasm_exec.
The increase of stack size is necessary because the jsonv2
tests exercise that the jsonv2 and jsontext packages support
a hard limit of a maximum JSON nesting depth of 10000.
However, even with a depth limit of 10000, this still exceeds
the previously specified maximum stack size of 1 MiB.
For use of JSON with untrusted inputs in WASM,
we really need to support #56733 as there is no right answer
for the default max depth limit to use since the max wasm
stack size is determined on a per-system basis.
Updates #71845
Change-Id: I3b32c58cc9f594a5c59bb3e4b20f5e86d85d8209
Reviewed-on: https://go-review.googlesource.com/c/go/+/683575
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The gc-stress test is useful for trying to exercise GC-related trace
events by producing a lot of them in many different situations.
Unfortunately this test is flaky, because allocating in a loop can
easily out-run the GC when it's trying to preempt the allocating
goroutine.
It's been a long standing problem that a program that allocates in a
loop can outrun a GC. The problem isn't the GC persay, it's consistently
correlated with a high STW time (likely a high 'stopping' time, not a
'stopped' time), suggesting that in the window of time when the garbage
collector is trying to stop all goroutines, they continue to allocate.
This should probably be fixed in general, but for now, let's focus on
this flaky test.
This CL changes the gc-stress test to (1) set a memory limit and (2) do
more work in between allocations. (2) is really what makes things less
flaky, but (2) unfortunately also means the GC is less exercised. That's
where (1) comes in. By setting a low memory limit, we increase GC
activity (in particular, assist activity). The memory limit also helps
prevent the heap from totally blowing up due to the heap goal inflating
from floating garbage, but it's not perfect.
After this change, under stress2, this test exceeds a heap size of 500
MiB only 1 in 5000 runs on my 64-vCPU VM. Before this change, it got
that big about 1/4th of the time.
Fixes#74052.
Change-Id: I49233c914c8b65b1d593d3953891fddda6685aec
Reviewed-on: https://go-review.googlesource.com/c/go/+/683515
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>
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>
During toolchain selection, the GOEXPERIMENT value may not be valid for
the current version (but it is valid for the selected version). In this
case, cfg.ExperimentErr is set and cfg.Experiment is nil.
Normally cmd/go main exits when ExperimentErr is set, so Experiment is
~never nil. But that is skipped during toolchain selection, and
fips140.Init is used during toolchain selection.
Fixes#74111.
Change-Id: I6a6a636c65ee5831feaf3d29993a60613bbec6f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/680976
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Currently the mspan limit field is set after allocSpan returns, *after*
the span has already been published to the GC (including the
conservative scanner). But the limit field is load-bearing, because it's
checked to filter out invalid pointers. A stale limit value could cause
a crash by having the conservative scanner access allocBits out of
bounds.
Fix this by setting the mspan limit field before publishing the span.
For large objects and arena chunks, we adjust the limit down after
allocSpan because we don't have access to the true object's size from
allocSpan. However this is safe, since we first initialize the limit to
something definitely safe (the actual span bounds) and only adjust it
down after. Adjusting it down has the benefit of more precise debug
output, but the window in which it's imprecise is also fine because a
single object (logically, with arena chunks) occupies the whole span, so
the 'invalid' part of the memory will just safely point back to that
object. We can't do this for smaller objects because the limit will
include space that does *not* contain any valid objects.
Fixes#74288.
Change-Id: I0a22e5b9bccc1bfdf51d2b73ea7130f1b99c0c7c
Reviewed-on: https://go-review.googlesource.com/c/go/+/682655
Reviewed-by: Keith Randall <khr@google.com>
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>
Almost everywhere we stop the world we casGToWaitingForGC to prevent
mutual deadlock with the GC trying to scan our stack. This historically
was only necessary if we weren't stopping the world to change the GC
phase, because what we were worried about was mutual deadlock with mark
workers' use of suspendG. And, they were the only users of suspendG.
In Go 1.22 this changed. The execution tracer began using suspendG, too.
This leads to the possibility of mutual deadlock between the execution
tracer and a goroutine trying to start or end the GC mark phase. The fix
is simple: make the stop-the-world calls for the GC also call
casGToWaitingForGC. This way, suspendG is guaranteed to make progress in
this circumstance, and once it completes, the stop-the-world can
complete as well.
We can take this a step further, though, and move casGToWaitingForGC
into stopTheWorldWithSema, since there's no longer really a place we can
afford to skip this detail.
While we're here, rename casGToWaitingForGC to casGToWaitingForSuspendG,
since the GC is now not the only potential source of mutual deadlock.
Fixes#72740.
Change-Id: I5e3739a463ef3e8173ad33c531e696e46260692f
Reviewed-on: https://go-review.googlesource.com/c/go/+/681501
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>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Our attempt to evenly distribute tests across shards struggles a bit
because certain long-running targets are very difficult to distinguish
in ResultDB, namely racebench and the test directory tests. These are
the only tests where the JSON output from dist omits the variant from
the package, making it impossible to distinguish them in the test result
data. My current suspicion is that this is preventing the load balancing
from being effective for the race builders in particular, though I worry
the longtest builders have a similar situation with the test directory
tests.
For #65814.
Change-Id: I5804c2af092ff9aa4a3f0f6897b4a57c4628f837
Reviewed-on: https://go-review.googlesource.com/c/go/+/681955
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Bypass: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Issue #74045 describes a scenario in which gopark is inlined into
readTrace, such that there are no preemption points. This is only a
problem because readTrace spins if trace.shutdown is set, through
traceReaderAvailable. However, trace.shutdown is almost certainly
overkill for traceReaderAvailable. The first condition, checking whether
the reader gen and the flushed gen match, should be sufficient to ensure
the reader wakes up and finishes flushing all buffers. The first
condition is also safe because it guarantees progress. In the case of
shutdown, all the trace work that will be flushed has been flushed, and
so the trace reader will exit into a regular goroutine context when
it's finished. If not shutting down, then the trace reader will release
doneSema, increase readerGen, and then the gopark unlockf will let it
block until new work actually comes in.
Fixes#74045.
Change-Id: Id9b15c277cb731618488771bd484577341b68675
Reviewed-on: https://go-review.googlesource.com/c/go/+/680738
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Nick Ripley <nick.ripley@datadoghq.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
A previous change renamed Value.Uint64 to Value.ToUint64 to accomodate
string values. The method for a string value is then Value.ToString,
while the method for a debug string (for example, for fmt) is just
called String, as per fmt.Stringer.
This change follows a request from Dominik Honnef, maintainer of
gotraceui, to make Value follow the conventions of the reflect package.
The Value type there has a method String which fulfills both purposes:
getting the string for a String Value, and as fmt.Stringer. It's
not exactly pretty, but it does make sense to just stick to convention.
Change-Id: I55b364be88088d2121527bffc833ef03dbdb9764
Reviewed-on: https://go-review.googlesource.com/c/go/+/680978
Reviewed-by: Florian Lehner <lehner.florian86@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
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>
This change switches from using testenv.Command to
testenv.CommandContext which is a little bit friendlier. It also
switches away from using 'go run' to 'go build' and running the
resulting binary explicitly. This helps eliminate any questions about
signal handling and propagation.
For #72740.
Change-Id: Ife8010da89a7bc439e061fe0c9c6b1f5620d90f1
Reviewed-on: https://go-review.googlesource.com/c/go/+/680977
Reviewed-by: Carlos Amedee <carlos@golang.org>
TryBot-Bypass: Michael Knyszek <mknyszek@google.com>
This runs the ssa/_gen generator writing files into
a temporary directory, and then checks that there are
no differences with what is currently in the ssa directory,
and also checks that any file with the "generated from
_gen/..." header was actually generated, and checks that
the headers on the generated file match the expected
header prefix.
Change-Id: Ic8eeb0b06cf6f2e576a013e865b331a12d3a77aa
Reviewed-on: https://go-review.googlesource.com/c/go/+/680615
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>
Windows already forbids this, since removing the root causes a
sharing violation (can't delete the directory while the os.Root
has a handle open to it), but add a more explicit check for
attempts to delete "." and return EINVAL.
Note that this change to Windows doesn't affect operations like
Root.Remove("dir/."), since the path is cleaned into just "dir"
before attempting the deletion.
Fixes#73863
Change-Id: I0f45ccb6c9f171d3a52831632c134150388d77b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/679377
Auto-Submit: Damien Neil <dneil@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Before CL 650697, there was only one system goroutine that could
dynamically change between being a user goroutine and a system
goroutine, and that was the finalizer/cleanup goroutine. In goroutine
profiles, it was handled explicitly. It's status would be checked during
the first STW, and its stack would be recorded. This let the goroutine
profiler completely ignore system goroutines once the world was started
again.
CL 650697 added dedicated cleanup goroutines (there may be more than
one), and with this, the logic for finalizer goroutines no longer
scaled. In that CL, I let the isSystemGoroutine check be dynamic and
dropped the special case, but this was based on incorrect assumptions.
Namely, it's possible for the scheduler to observe, for example, the
finalizer goroutine as a system goroutine and ignore it, but then later
the goroutine profiler itself sees it as a user goroutine. At that point
it's too late and already running. This violates the invariant of the
goroutine profile that all goroutines are handled by the profiler before
they start executing. In practice, the result is that the goroutine
profiler can crash when it checks this invariant (not checking the
invariant means racily reading goroutine stack memory).
The root cause of the problem is that these system goroutines do not
participate in the goroutine profiler's state machine. Normally, when
profiling, goroutines transition from 'absent' to 'in-progress' to
'satisfied'. However with system goroutines, the state machine is
ignored entirely. They always stay in the 'absent' state. This means
that if a goroutine transitions from system to user, it is eligible for
a profile record when it shouldn't be. That transition shouldn't be
allowed to occur with respect to the goroutine profiler, because the
goroutine profiler is trying to snapshot the state of every goroutine.
The fix to this problem is simple: don't ignore system goroutines. Let
them participate in the goroutine profile state machine. Instead, decide
whether or not to record the stack after the goroutine has been acquired
for goroutine profiling. This means if the scheduler observes the
finalizer goroutine as a system goroutine, it will get promoted in the
goroutine profiler's state machine, and no other part of the goroutine
profiler will observe the goroutine again. Simultaneously, the
stack record for the goroutine will be correctly skipped.
Fixes#74090.
Change-Id: Icb9a164a033be22aaa942d19e828e895f700ca74
Reviewed-on: https://go-review.googlesource.com/c/go/+/680477
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>
We associate WaitGroups with synctest bubbles by attaching a
special to the WaitGroup. It is not possible to attach a special
to a linker-allocated value, such as:
var wg sync.WaitGroup
Avoid panicking when accessing a linker-allocated WaitGroup
from a bubble. We have no way to associate these WaitGroups
with a bubble, so just treat them as always unbubbled.
This is probably fine, since the WaitGroup was always
created outside the bubble in this case.
Fixes#74005
Change-Id: Ic71514b0b8d0cecd62e45cc929ffcbeb16f54a55
Reviewed-on: https://go-review.googlesource.com/c/go/+/679695
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Damien Neil <dneil@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
The failures in #70310 are hard to decipher. The cases where the lock is
being held either don't really make sense (the STW failures) or the
goroutine that fails is 'running on another thread' and we don't get a
stack trace. In fact, such a goroutine exists even in the STW cases.
Since reproducing this is going to be hard (very few failures over a 2
year span) let's set GOTRACEBACK=crash for these testprogs so next time
it happens we can see why.
For #70310.
Change-Id: I81a780aa82b173d42973f06911cb243f33352be1
Reviewed-on: https://go-review.googlesource.com/c/go/+/680476
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>
OpenFile with O_CREATE|O_EXCL should not follow dangling symlinks.
On AIX it does, because AIX's openat(2) apparently returns ELOOP
in this case. Most Unices return EEXIST.
Ensure that we never follow symlinks in the final component of
the path when opening a file with O_CREATE|O_EXCL.
Fixes#73924
Change-Id: I869afb7faefccb0bb29d155553a7d7e5be80467d
Reviewed-on: https://go-review.googlesource.com/c/go/+/677735
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Damien Neil <dneil@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Currently, CrossOriginProtection must be constructed by
NewCrossOriginProtection. If you try to use the zero value, most
methods will panic with a nil dereference.
This CL makes CrossOriginProtection use on-demand initialization
instead, so the zero value has the same semantics as the value
currently returned by NewCrossOriginProtection. Now,
NewCrossOriginProtection just constructs the zero value.
We keep NewCrossOriginProtection by analogy to NewServeMux.
Updates #73626Fixes#74089.
Change-Id: Ia80183eb6bfdafb0e002271c0b25c2d6230a159a
Reviewed-on: https://go-review.googlesource.com/c/go/+/680396
Auto-Submit: Austin Clements <austin@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
semrelease is safe to call on the system stack (since it just readies
goroutines) except for the fact that it might perform a direct G
handoff and call into the scheduler. If handoff is set to false this is
exceptionally rare, but could happen, and has happened for the trace
reader goroutine which releases a trace.doneSema.
Fixes#73469.
Change-Id: I37ece678bc4721bbb6e5879d74daac762b7d742a
Reviewed-on: https://go-review.googlesource.com/c/go/+/680315
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>
After CL 677558, when running all.bash, the binaries of commands such
as dist, nm, and pprof are no longer built by default, so when running
all.bash, "./all.bash: line 13: /home/golang/pkg/tool/linux_amd64/dist:
No such file or directory" will be printed, and the return result of
the all.bash script is non-zero.
Although the "dist" command won't be installed in $GOTOOLDIR anymore,
but it will be built and cached, and ../bin/go tool dist will reuse the
cached binary.
For #71867
Change-Id: I802eeafdb866e7d80c42da3e0955bb32def7b037
Reviewed-on: https://go-review.googlesource.com/c/go/+/680135
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Use the synctest bubble ID to identify bubbles in traces,
rather than the goroutine ID of the bubble's root goroutine.
Some waitReasons include a "(synctest)" suffix to distinguish
a durably blocking state from a non-durable one. For example,
"chan send" vs. "chan send (synctest)". Change this suffix
to "(durable)".
Always print a "(durable)" sufix for the state of durably
blocked bubbled goroutines. For example, print "sleep (durable)".
Drop the "[not] durably blocked" text from goroutine states,
since this is now entirely redundant with the waitReason.
Old:
goroutine 8 [chan receive (synctest), synctest bubble 7, durably blocked]:
goroutine 9 [select (no cases), synctest bubble 7, durably blocked]:
New:
goroutine 8 [chan receive (durable), synctest bubble 1]:
goroutine 9 [select (no cases) (durable), synctest bubble 1]:
Change-Id: I89112efb25150a98a2954f54d1910ccec52a5824
Reviewed-on: https://go-review.googlesource.com/c/go/+/679376
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>
The synctest.Test function waits for all goroutines in a bubble to
exit before returning. If there is ever a point when all goroutines
in a bubble are durably blocked, it panics and reports a deadlock.
Panic with a different message depending on whether the bubble's
main goroutine has returned or not. The main goroutine returning
stops the bubble clock, so knowing whether it is running or not
is useful debugging information.
The new panic messages are:
deadlock: all goroutines in bubble are blocked
deadlock: main bubble goroutine has exited but blocked goroutines remain
Change-Id: I94a69e79121c272d9c86f412c1c9c7de57ef27ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/679375
Auto-Submit: Damien Neil <dneil@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The Go 1.25 RC is due soon. This is the time to once again 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
cat << EOF | patch
diff --git a/src/cmd/go/testdata/script/test_json_build.txt b/src/cmd/go/testdata/script/test_json_build.txt
index df8863ae03..2a572ace72 100644
--- a/src/cmd/go/testdata/script/test_json_build.txt
+++ b/src/cmd/go/testdata/script/test_json_build.txt
@@ -56,7 +56,7 @@ stdout '"Action":"fail","Package":"m/cycle/p","Elapsed":.*,"FailedBuild":"m/cycl
! go test -json -o=$devnull ./veterror
stdout '"ImportPath":"m/veterror \[m/veterror.test\]","Action":"build-output","Output":"# m/veterror\\n"'
stdout '"ImportPath":"m/veterror \[m/veterror.test\]","Action":"build-output","Output":"# \[m/veterror\]\\n"'
-stdout '"ImportPath":"m/veterror \[m/veterror.test\]","Action":"build-output","Output":"veterror(/|\\\\)main_test.go:9:9: fmt.Printf format %s reads arg #1, but call has 0 args\\n"'
+stdout '"ImportPath":"m/veterror \[m/veterror.test\]","Action":"build-output","Output":"veterror(/|\\\\)main_test.go:9:21: fmt.Printf format %s reads arg #1, but call has 0 args\\n"'
stdout '"ImportPath":"m/veterror \[m/veterror.test\]","Action":"build-fail"'
stdout '"Action":"start","Package":"m/veterror"'
stdout '"Action":"output","Package":"m/veterror","Output":"FAIL\\tm/veterror \[build failed\]\\n"'
EOF
Change-Id: I6a8d35acdeab90c3bbd6395b8b1abb021673b5cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/678556
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
This CL makes two changes to reduce the predictability
with which bubbled timers fire.
When asynctimerchan=0 (the default), regular timers with an associated
channel are only added to a timer heap when some channel operation
is blocked on that channel. This allows us to garbage collect
unreferenced, unstopped timers. Timers in a synctest bubble, in
contrast, are always added to the bubble's timer heap.
This CL changes bubbled timers with a channel to be handled the
same as unbubbled ones, adding them to the bubble's timer heap only
when some channel operation is blocked on the timer's channel.
This permits unstopped bubbled timers to be garbage collected,
but more importantly it makes all timers past their deadline
behave identically, regardless of whether they are in a bubble.
This CL also changes timer scheduling to execute bubbled timers
immediately when possible rather than adding them to a heap.
Timers in a bubble's heap are executed when the bubble is idle.
Executing timers immediately avoids creating a predictable
order of execution.
For #73850Fixes#73934
Change-Id: If82e441546408f780f6af6fb7f6e416d3160295d
Reviewed-on: https://go-review.googlesource.com/c/go/+/678075
Auto-Submit: Damien Neil <dneil@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
There are two additional sources of memory overhead per P that come from
greenteagc. One is for ptrBuf, but on platforms other than Windows it
doesn't actually cost anything due to demand-paging (Windows also
demand-pages, but the memory is 'committed' so it still counts against
OS RSS metrics). The other is for per-sizeclass scan stats. However when
greenteagc is disabled, most of these scan stats are completely unused.
The worst-case memory overhead from these two sources is relatively
small (about 10 KiB per P), but for programs with a small memory
footprint running on a machine with a lot of cores, this can be
significant (single-digit percent).
This change does two things. First, it puts ptrBuf initialization behind
the greenteagc experiment, so now that memory is never allocated by
default. Second, it abstracts the implementation details of scan stat
collection and emission, such that we can have two different
implementations depending on the build tag. This lets us remove all the
unused stats when the greenteagc experiment is disabled, reducing the
memory overhead of the stats from ~2.6 KiB per P to 536 bytes per P.
This is enough to make the difference no longer noticable in our
benchmark suite.
Fixes#73931.
Change-Id: I4351f1cbb3f6743d8f5922d757d73442c6d6ad3f
Reviewed-on: https://go-review.googlesource.com/c/go/+/678535
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
We shouldn't be installing these tools because we will remove them in
distpack. Installing the tools will also prevent us from testing what
happens when the tools are missing.
The changes below this on the stack, CL 677775 (cmd/doc: build cmd/doc
directly into the go command) and CL 677636 (cmd/go/internal/cfg: fix
GOROOT setting when forcing host config) are needed for this change to
pass tests. The doc change is being done so we preserve the properties
in the tests that doc can be invoked without doing a build. It's not
strictly necessary (we could just remove the tests) but it's nice to
have. The GOROOT setting is a significant bug in switching the
configuration to host mode: the value of GOROOT wasn't being reset,
which caused issues for go commands built with trimpath, because
runtime.GOROOT wouldn't have the correct goroot value.
For #71867
Change-Id: I4181711ba117066b7d62d7d013ad4b186871cfb7
Reviewed-on: https://go-review.googlesource.com/c/go/+/677558
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Michael Matloob <matloob@google.com>
There are a couple of places where our tests expect that 'go doc'
doesn't need to do a build. Invoke the cmd/doc code directly by the go
command instead of starting the doc tool in a separate process so we can
preserve that property.
This change moves most of the doc code into the package
cmd/internal/doc, and exposes a Main function from that function that's
called both by the cmd/doc package, and by go doc.
This change makes couple of additional changes to intergrate doc into
the go command:
The counter.Open call and the increment of invocations counter are only
needed by cmd/doc. The go command will open the counters file and
increment a counter for the doc subcommand.
We add a cmd_go_bootstrap tagged variant of the file that defines go doc
so that we don't end up linking net into the bootstrap version of the go
command. We don't need doc in that version of the command.
We create a new flagSet rather than using flag.CommandLine because when
running as part of the go command, the flags to "go doc" won't be the top
level flags.
We change TestGoListTest in go_test.go to use gofmt instead of doc as an
example of a main package in cmd with an in-package test.
For #71867
Change-Id: I3e3df83e5fa266559606fdc086b461165e09f037
Reviewed-on: https://go-review.googlesource.com/c/go/+/677775
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Matloob <matloob@google.com>
We manage the state using a bunch of global config, so we need to make
sure we're doing things in the right order. In this case, the SetGOROOT
function was being called in init, setting the GOROOT on the global
Context, but when we reset the context in ForceHost we lost the goroot
configuration. We need to call SetGOROOT in ForceHost to re-set the
GOROOT on the new context.
This was uncovered by CL 677558 because a go command that was built with
trimpath would try to use its runtime.GOROOT(), which wouldn't be valid
in trimpath mode. Setting GOROOT properly with SetGOROOT will use the
value from findGOROOT, assuming GOROOT isn't set in the environment,
and findGOROOT will try to determine GOROOT using the path of the go
command executable.
For #71867
Change-Id: I731b6c5d859b4504fc128b29ab904e3a2886ff3c
Reviewed-on: https://go-review.googlesource.com/c/go/+/677636
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
This CL changes the representation of FileSet from a slice
to a tree, specifically an AVL tree keyed by the File's
base-end range. This makes a sequence of insertions using
AddExistingFiles much more efficient: creating a FileSet
of size n by a sequence of calls costs O(n log n), whereas
before it was O(n^2 log n) because of the repeated sorting.
The AVL tree is based on Russ' github.com/rsc/omap,
simplified for clarity and to reduce unnecessary dynamism.
We use an AVL tree as it is more strongly balanced than an
RB tree, optimising lookups at the expense of insertions.
The CL includes a basic unit test of the tree using
operations on pseudorandom values.
Benchmarks of Position lookups actually improve because
the tree avoids BinarySearchFunc's dynamic dispatch to cmp,
and the benchmark of AddExistingFiles is about 1000x (!) faster:
goos: darwin
goarch: arm64
pkg: go/token
cpu: Apple M1 Pro
│ old.txt │ new.txt │
│ sec/op │ sec/op vs base │
FileSet_Position/random-8 51.60n ± 1% 39.99n ± 1% -22.50% (p=0.000 n=9)
FileSet_Position/file-8 27.10n ± 3% 26.64n ± 1% ~ (p=0.168 n=9)
FileSet_Position/manyfiles-8 209.9n ± 17% 154.1n ± 9% -26.58% (p=0.000 n=9)
FileSet_AddExistingFiles/sequence-8 395930.3µ ± 4% 280.8µ ± 10% -99.93% (p=0.000 n=9)
Updates #73205
Change-Id: Iea59c624a6cedadc2673987a5eb0ebece67af9e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/675736
Reviewed-by: Robert Findley <rfindley@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
In synctest bubbles, fire timers scheduled for the same instant
in a randomized order.
Pending timers are added to a heap ordered by the timer's wakeup time.
Add a per-timer random value, set when the timer is added to a heap,
to break ties between timers scheduled for the same instant.
Only inject this randomness in synctest bubbles. We could do so
for all timers at the cost of one cheaprand call per timer,
but given that it's effectively impossible to create two timers
scheduled for the same instant outside of a fake-time environment,
don't bother.
Fixes#73876
For #73850
Change-Id: Ie96c86a816f548d4c31e4e014bf9293639155bd4
Reviewed-on: https://go-review.googlesource.com/c/go/+/677276
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Damien Neil <dneil@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
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
This change adds a function to expose the version set by the trace
reader after reading the trace header (in tests). The trace validator
needs to be able to determine what version of the trace it needs to
validate against. Clock snapshot checks have been disabled for
Windows and WASM.
For #63185
Change-Id: Ia3d63e6ed7a5ecd87e63292b84cc417d982aaa5a
Reviewed-on: https://go-review.googlesource.com/c/go/+/677695
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Carlos Amedee <carlos@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
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 String method can potentially recurse infinitely, since %#x will
apparently call String if the method exists. This isn't well documented,
but cmd/vet will be updated soon to check this (when we update the
vendored x/tools dependency) so cut off the recursion by converting to
the underlying type first.
Change-Id: Ia6fc046c9eb56a5dd6a33772afd23da443a06116
Reviewed-on: https://go-review.googlesource.com/c/go/+/677261
Auto-Submit: 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>
sync.Cond.Wait is durably blocking. Waking a goroutine out of Cond.Wait
from outside its bubble panics.
Make this panic a fatal panic, since it leaves the notifyList in an
inconsistent state. We could do some work to make this a recoverable
panic, but the complexity doesn't seem worth the outcome.
For #67434
Change-Id: I88874c1519c2e5c0063175297a9b120cedabcd07
Reviewed-on: https://go-review.googlesource.com/c/go/+/675617
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
The primary benefit of reference tables is to the linker, though they
are also reasonably compact as compared to absolute element indices. It
is worth also checking if reference table structure is similarly
exploited past the IR linking stage.
Ideally, the reference table definition would live in / near the linker.
As it stands, it's a bit hard to infer the purpose of the reference
tables when looking at pkgbits in isolation.
Change-Id: I496aca5a4edcf28e66fa7863ddfa4d825e1b2e89
Reviewed-on: https://go-review.googlesource.com/c/go/+/675596
Auto-Submit: 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>
We already guarantee that no automatic updates to GOMAXPROCS occur after
a GOMAXPROCS call returns. This is easily achieved by having the update
goroutine double-check that updates are still allowed during STW before
committing the new value.
However, it is possible for sysmon to concurrently run defaultGOMAXPROCS
to compute a new GOMAXPROCS value after GOMAXPROCS returns. This new
value will be discarded later, but we'll still perform the system calls
necessary to compute the new value.
Normally this distinction doesn't matter, but if you want to sandbox a
Go program, then you may want to disable GOMAXPROCS updates to reduce
the system call footprint. A call to GOMAXPROCS will disable updates,
but without a guarantee on when sysmon will observe the change it is
somewhat fragile.
Add explicit synchronization between GOMAXPROCS and sysmon to guarantee
that sysmon won't run defaultGOMAXPROCS after GOMAXPROCS returns.
The synchronization is a bit complex because we can't hold a mutex
across STW, nor take a semaphore from sysmon, but the result isn't too
bad.
One oddity is that sched.customGOMAXPROCS and gomaxprocs are no longer
updated in lockstep (even though both are protected by sched.lock), but
I don't believe anything should depend on that.
For #73193.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-staticlockranking
Change-Id: I6a6a636cff243a9b69ac1b5d2f98925648e60236
Reviewed-on: https://go-review.googlesource.com/c/go/+/677037
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Add support to internal/synctest for managing associations between
arbitrary pointers and synctest bubbles. (Implemented internally to
the runtime package by attaching a special to the pointer.)
Associate WaitGroups with bubbles.
Since WaitGroups don't have a constructor,
perform the association when Add is called.
All Add calls must be made from within the same bubble,
or outside any bubble.
When a bubbled goroutine calls WaitGroup.Wait,
the wait is durably blocking iff the WaitGroup is associated
with the current bubble.
Change-Id: I77e2701e734ac2fa2b32b28d5b0c853b7b2825c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/676656
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>
Auto-Submit: Damien Neil <dneil@google.com>
The updatemaxprocs metric logic is currently backwards. We only
increment the metric when we update GOMAXPROCS, but that only occurs if
updatemaxprocs is enabled.
Instead, the metric is supposed to increment when updatemaxprocs is
disabled and there would be different behavior if it were enabled.
Theoretically we should run the entire update system in a dry run mode,
and only bail out right before committing updates. But that is an awful
lot of effort for a feature that is disabled. Plus some users (like
sandboxes) want to completely disable the update syscalls
(sched_getaffinity and pread64). If we still do dry run updates then we
need an additional GODEBUG for completely disabling functionality.
This CL also avoids starting the update goroutine at all if disabled,
since it isn't needed.
For #73193.
Change-Id: I6a6a636ceec8fced44e36cb27dcb1b4ba51fce33
Reviewed-on: https://go-review.googlesource.com/c/go/+/677036
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>
This CL fixes a panic in NewFromFiles when it is provided files
produced by the parser in SkipObjectResolution mode, which skips
the step of connecting ast.Idents to (deprecated) ast.Objects.
Instead of calling ast.NewPackage, which performs a number of
unnecessary steps, we just construct the ast.Package directly.
Fixes#66290
Change-Id: Id55bd30d8afb9d396c3901070e7607c5a22030d5
Reviewed-on: https://go-review.googlesource.com/c/go/+/675036
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
On these platforms, we set up a frame pointer record below
the current stack pointer, so when we're in duffcopy or duffzero,
we get a reasonable traceback. See #73753.
But because this frame pointer record is below SP, it is vulnerable.
Anything that adds a new stack frame to the stack might clobber it.
Which actually happens in #73748 on amd64. I have not yet come across
a repro on arm64, but might as well be safe here.
The only real situation this could happen is when duffzero or duffcopy
is passed a nil pointer. So we can just avoid the problem by doing the
nil check outside duffzero/duffcopy. That way we never add a frame
below duffzero/duffcopy. (Most other ways to get a new frame below the
current one, like async preempt or debugger-generated calls, don't
apply to duffzero/duffcopy because they are runtime functions; we're
not allowed to preempt there.)
Longer term, we should stop putting stuff below SP. #73753 will
include that as part of its remit. But that's not for 1.25, so we'll
do the simple thing for 1.25 for this issue.
Fixes#73748
Change-Id: I913c49ee46dcaee8fb439415a4531f7b59d0f612
Reviewed-on: https://go-review.googlesource.com/c/go/+/676916
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>
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>
In CL 660696, we made the linker to choose the symbol of the
larger size in case there are multiple contentless declarations of
the same symbol. We also made it emit an error in the case that
there are a contentless declaration of a larger size and a
definition with content of a smaller size. In this case, we should
choose the definition with content, but the code accesses it
through the declaration of the larger size could fall into the
next symbol, potentially causing data corruption. So we disallowed
it.
There is one spcial case, though, that some code uses a linknamed
variable declaration to reference a function in assembly, in order
to take its address. The variable is often declared as uintptr.
The function symbol is the definition, which could sometimes be
shorter. This would trigger the error case above, causing existing
code failing to build.
This CL allows it as a special case. It is still not safe to
access the variable's content. But it is actually okay to just
take its address, which the existing code often do.
Fixes#73617.
Change-Id: I467381bc5f6baa16caee6752a0a824c7185422f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/676636
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.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>
Cleanup functions and finalizers must not run in a synctest bubble.
If they did, a function run by the GC at an unpredictable time
could unblock a bubble that synctest believes is durably
blocked.
Add a test verifying that cleanups and finalizers are always
run by non-bubbled goroutines. (This is already the case because
we never add system goroutines to a bubble.)
For #67434
Change-Id: I5a48db2b26f9712c3b0dc1f425d99814031a2fc1
Reviewed-on: https://go-review.googlesource.com/c/go/+/675257
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Damien Neil <dneil@google.com>
When creating a new *ir.Name or *ir.LinksymOffsetExpr to represent
a composite literal stored in the read-only data section, we should
use the original type of the expression that was found via
ir.ReassignOracle.StaticValue. (This is needed because the StaticValue
method can traverse through OCONVNOP operations to find its final
result.)
Otherwise, the compilation may succeed, but the linker might erroneously
conclude that a type is not used and prune an itab when it should not,
leading to a call at execution-time to runtime.unreachableMethod, which
throws "fatal error: unreachable method called. linker bug?".
The tests exercise both the case of a zero value struct literal that
can be represented by the read-only runtime.zeroVal, which was the case
of the simplified example from #73888, and also modifies that example to
test the non zero value struct literal case.
This CL makes two similar changes for those two cases. We can get either
of the tests we are adding to fail independently if we only make
a single corresponding change.
Fixes#73888
Updates #71359
Change-Id: Ifd91f445cc168ab895cc27f7964a6557d5cc32e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/676517
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
This adds a test which validates the traces generated by the execution
tracer and the flight recorder depending on the order where they are
stopped and started. This test uncovered that under certain
circumstances, the traces which were produced would possibly be
missing the trace header. All traces have the trace headers included
now. Clock snapshot checks have been disabled for Windows and WASM.
Change-Id: I5be719d228300469891fc56817fbce4ba5453fff
Reviewed-on: https://go-review.googlesource.com/c/go/+/675975
Auto-Submit: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Before this change, go get didn't have support for the work pattern. The
work pattern is new in Go 1.25 and evaluates to the packages in the work
(also called main) modules. 'go get work' would cause a panic because
'work' would be incorrectly considered a path pattern and then queryPath
would would try to query a metapackage pattern (resulting in the
internal error panic). This change properly supports the work pattern in
go get.
It's pretty simple: First, we need to seprate the work pattern from the
other patterns. Then in performWorkQueries, which maps queries to the
modules that satisfy them, we return the single main module because by
definition the work pattern is the set of packages in the work modules,
and go get always runs in single module mode. (The exception is when the
work module contains no packages, in which case we report a warning, and
return no candidates because nothing is needed to resolve nothing).
The rest of the work is already done by loading the packages matching
the query and finding missing imports in the call to
findAndUpgradeImports in runGet.
Change-Id: I3c4610878b3d930a1d106cc59d9a0be194d966cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/675895
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
cleanupQueue.Flush is reachable from mallocgc via sweepAssist. Normally
allp will continue all valid Ps, but procresize itself increases the
size of allp and then allocates new Ps to place in allp. If we get
perfectly unlucky, the new(p) allocations will complete sweeping and
cleanupQueue.Flush will dereference a nil pointer from allp. Avoid this
by skipping nil Ps.
I've looked through every other use of allp and none of them appear to
be reachable from procresize.
Change-Id: I6a6a636cab49ef268eb8fcd9ff9a96790d9c5685
Reviewed-on: https://go-review.googlesource.com/c/go/+/676515
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>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
CL 585399 fixed an initialization loop during IR contruction that
involving alias type, by avoiding publishing alias declarations until
the RHS type expression has been constructed.
There's an assertion to ensure that the alias's type must be the same
during the initialization. However, that assertion is too strict, since
we may construct different instances of the same type, if the type is an
instantination of generic type.
To fix this, we could use types.IdenticalStrict to ensure that these
types matching exactly.
Updates #66873.
Updates #73309.
Change-Id: I2559bed37e21615854333fb1057d7349406e6a1b
Reviewed-on: https://go-review.googlesource.com/c/go/+/668175
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
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: Keith Randall <khr@google.com>
When transforming for loop variables, the compiler does roughly
following steps:
(1) prebody = {z := z' for z in leaked}
...
(4) init' = (init : s/z/z' for z in leaked)
However, the definition of z is not updated to `z := z'` statement,
causing ReassignOracle incorrectly use the new init statement with z'
instead of z, trigger the ICE.
Fixing this by updating the correct/new definition statement for z
during the prebody initialization.
Fixes#73823
Change-Id: Ice2a6741be7478506c58f4000f591d5582029136
Reviewed-on: https://go-review.googlesource.com/c/go/+/675475
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: Keith Randall <khr@google.com>
Reviewed-by: David Chase <drchase@google.com>
unique.Make always copies strings passed into it, so it's safe to not
copy byte slices converted to strings either. Handle this just like map
accesses with string(b) as keys.
This CL only handles unique.Make(string(b)), not nested cases like
unique.Make([2]string{string(b1), string(b2)}); this could be done in a
followup CL but the map lookup code in walk is sufficiently different
than the call handling code that I didn't attempt it. (SSA is much
easier).
Fixes#71926
Change-Id: Ic2f82f2f91963d563b4ddb1282bd49fc40da8b85
Reviewed-on: https://go-review.googlesource.com/c/go/+/672135
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently, hash/maphash.Comparable escapes its parameter if it
contains non-string pointers, but does not escape strings or types
that contain strings but no other pointers. This is achieved by a
compiler intrinsic.
unique.Make does something similar: it stores its parameter to a
central map, with strings cloned. So from the escape analysis's
perspective, the non-string pointers are passed through, whereas
string pointers are not. We currently cannot model this type of
type-dependent data flow directly in Go. So we do this with a
compiler intrinsic. In fact, we can unify this and the intrinsic
above.
Tests are from Jake Bailey's CL 671955 (thanks!).
Fixes#73680.
Change-Id: Ia6a78e09dee39f8d9198a16758e4b5322ee2c56a
Reviewed-on: https://go-review.googlesource.com/c/go/+/675156
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Jake Bailey <jacob.b.bailey@gmail.com>
This was the first CL in a series of CLs aimed at reducing
how often interface arguments escape for the print functions in fmt.
This CL makes some small improvements to the escape analysis logging.
Here is a sample snippet of the current -m=2 logs:
./print.go:587:7: parameter p leaks to {heap} with derefs=0:
./print.go:587:7: flow: p = p:
./print.go:587:7: from (*pp).printArg(p, err, 'v') (call parameter) at ./print.go:613:13
./print.go:587:7: flow: p = p:
./print.go:587:7: from (*pp).handleMethods(p, verb) (call parameter) at ./print.go:749:22
[..]
If we attempt to tease apart some reasons why the -m=2 logs can be
challenging to understand for the uninitiated:
- The "flow" lines are very useful, but contain more-or-less abstracted
pseudocode. The "from" lines most often use actual code. When first
looking at the logs, that distinction might not be apparent, which can
result in looking back to the original code to hunt for pseudocode
that doesn't exist there. (The log example shows 'p = p', but there is
no 'p = p' in the original source).
- Escape analysis can be most interesting with inlining, but that can
result in seeing overlapping short variable names (e.g., p, b, v...).
- The directionality of the "flow" lines might not be obvious,
including whether they build top-to-bottom or bottom-to-top.
- The use of '{' and '}' in the -m=2 logs somewhat intersects with Go
literals (e.g., if the log says "{temp}", an initial thought might
be that represents some temp inside of some Go literal).
- And of course, escape analysis itself is subtle.
This CL:
- Adds the function name to the first -m=2 line to provide more context
and reduce how often the reader needs to lookup line numbers.
- Uses the Unicode left arrow '←' rather than '=' on the flow lines
to make it clearer that these lines are abstracted away from the
original Go code and to help the directionality jump out.
In the future, we can consider changing "{heap}", "{temp}",
"{storage for foo}" to something else, but we leave them as is for now.
Two examples with the modifications:
./f1.go:3:9: parameter inptr leaks to outptr for func1 with derefs=0:
./f1.go:3:9: flow: localptr ← inptr:
./f1.go:3:9: from localptr := inptr (assign) at ./f1.go:4:11
./f1.go:3:9: flow: outptr ← localptr:
./f1.go:3:9: from return localptr (return) at ./f1.go:5:2
./b.go:14:20: []byte{...} escapes to heap in byteOrderExample:
./b.go:14:20: flow: b ← &{storage for []byte{...}}:
./b.go:14:20: from []byte{...} (spill) at ./byteorder.go:14:20
./b.go:14:20: from b := []byte{...} (assign) at ./byteorder.go:14:11
./b.go:14:20: flow: <heap> ← b:
./b.go:14:20: from byteOrder.Uint32(b) (call parameter) at ./byteorder.go:15:32
These changes only affect the -m=2 output and leave the -m=1 output
as is.
Updates #8618
Updates #62653
Change-Id: Ic082a371c3d3fa0d8fd8bfbe4d64ec3e1e53c173
Reviewed-on: https://go-review.googlesource.com/c/go/+/524937
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
This change adds the flight recorder to the trace package.
Flight recording is a technique in which trace data is kept
in a circular buffer and can be flushed upon request. The
implementation will be added in follow-up CLs.
The flight recorder has already been implemented inside of the
golang.org/x/exp/trace package. This copies the current implementation
and modifies it to work within the runtime/trace package.
The changes include:
This adds the ability for multiple consumers (both the execution
tracer and the flight recorder) to subscribe to tracing events. This
change allows us to add multiple consumers without making major
modifications to the runtime. Future optimizations are planned
for this functionality.
This removes the use of byte readers from the process that
parses and processes the trace batches.
This modifies the flight recorder to not parse out the trace
clock frequency, since that requires knowledge of the format that's
unfortunate to encode in yet another place. Right now, the trace clock
frequency is considered stable for the lifetime of the program, so just
grab it directly from the runtime.
This change adds an in-band end-of-generation signal to the internal
implementation of runtime.ReadTrace. The internal implementation is
exported via linkname to runtime/trace, so the flight recorder can
identify exactly when a generation has ended. This signal is also useful
for ensuring that subscribers to runtime trace data always see complete
generations, by starting or stopping data streaming only at generation
boundaries.
For #63185
Change-Id: I5c15345981a6bbe9764a3d623448237e983c64ec
Reviewed-on: https://go-review.googlesource.com/c/go/+/673116
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
When a TLS 1.3 client processes the server's encryptedExtensionsMsg it
should reject instances that contain duplicate extension types.
RFC 8446 §4.2 says:
There MUST NOT be more than one extension of the same type in a given
extension block.
This update matches enforcement done in the client hello unmarshalling,
but applied to the TLS 1.3 encrypted extensions message unmarshalling.
Making this change also allows enabling the
DuplicateExtensionClient-TLS-TLS13 BoGo test.
Updates #72006
Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/673757
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Previously if instances of the handshakeMessage interface returned false
from unmarshal(), indicating an umarshalling error, the crypto/tls
package would emit an unexpected_message alert. This commit changes to
use a decode_error alert for this condition instead.
The usage-pattern of the handshakeMessage interface is that we switch on
the message type, invoke a specific concrete handshakeMessage type's
unmarshal function, and then return it to the caller on success. At this
point the caller looks at the message type and can determine if the
message was unexpected or not. If it was unexpected, the call-sites emit
the correct error for that case. Only the caller knows the current
protocol state and allowed message types, not the generic handshake
decoding logic.
With the above in mind, if we find that within the unmarshal logic for
a specific message type that the data we have in hand doesn't match the
protocol syntax we should emit a decode_error. An unexpected_message
error isn't appropriate because we don't yet know if the message is
unexpected or not, only that the message can't be decoded based on the
spec's syntax for the type the message claimed to be.
Notably one unit test, TestQUICPostHandshakeKeyUpdate, had to have its
test data adjusted because it was previously not testing the right
thing: it was double-encoding the type & length prefix data for a key
update message and expecting the QUIC logic to reject it as an
inappropriate post-handshake message. In reality it was being rejected
sooner as an invalid key update message from the double-encoding and
this was masked by the previous alert for this condition matching the
expected alert.
Finally, changing our alert allows enabling a handful of BoGo tests
related to duplicate extensions of the form
"DuplicateExtension[Server|Client]-TLS-[TLS1|TLS11|TLS12|TLS13]". One
test remains skipped (DuplicateExtensionClient-TLS-TLS13), as it
requires additional follow-up.
Updates #72006
Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/673738
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Daniel McCarney <daniel@binaryparadox.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
This implements RFC 9155 by removing support for SHA-1 algorithms:
- we don't advertise them in ClientHello and CertificateRequest
(where supportedSignatureAlgorithms is used directly)
- we don't select them in our ServerKeyExchange and CertificateVerify
(where supportedSignatureAlgorithms filters signatureSchemesForCertificate)
- we reject them in the peer's ServerKeyExchange and CertificateVerify
(where we check against the algorithms we advertised in ClientHello
and CertificateRequest)
Fixes#72883
Change-Id: I6a6a4656e2aafd2c38cdd32090d3d8a9a8047818
Reviewed-on: https://go-review.googlesource.com/c/go/+/658216
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
WORD and BYTE usage in crypto assembly cores is an anti-pattern which
makes extremely sensitive code significantly harder to understand, and
can result in unexpected behavior.
Because of this, we've decided to ban their usage in the crypto/ tree
(as part of the cryptography assembly policy).
This test walks the crypto/ tree looking for assembly files (those with
the filetype .s) and look for lines that match the regular rexpression
"(^|;)\s(BYTE|WORD)\s".
Change-Id: I60b5283e05e8588fa53273904a9611a411741f72
Reviewed-on: https://go-review.googlesource.com/c/go/+/671099
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Auto-Submit: Roland Shoemaker <roland@golang.org>
If a ClientHello only supports TLS 1.3, or if a CertificateRequest is
sent after selecting TLS 1.3, we should not advertise TLS 1.2-only
signature_algorithms like PKCS#1 v1.5 or SHA-1.
However, since crypto/x509 still supports PKCS#1 v1.5, and a direct
CertPool match might not care about the signature in the certificate at
all, start sending a separate signature_algorithms_cert extension to
indicate support for PKCS#1 v1.5 and SHA-1 in certificates.
We were already correctly rejecting these algorithms if the peer
selected them in a TLS 1.3 connection.
Updates #72883
Change-Id: I6a6a4656ab60e1b7fb20fdedc32604dc156953ae
Reviewed-on: https://go-review.googlesource.com/c/go/+/658215
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Go 1.25 will require macOS 12 Monterey or later, so macOS 11 will be
unsupported. The comment here suggests using a supported macOS version,
and that it can be the most recent one.
For now, make a minimal change of going from 11.0.0 to 12.0.0 so that
the chosen version is a supported one (although not the most recent).
However, it looks like even in CL 460476 (where the comment was added)
we were staying with the macOS version that matched Go's oldest, so we
might not have have recent experience with going beyond that. Update
the comment accordingly.
For #69839.
Change-Id: I90908971b0d5a8235ce77dc6bc9649e86008270a
Cq-Include-Trybots: luci.golang.try:gotip-darwin-amd64-longtest,gotip-darwin-arm64-longtest,gotip-darwin-amd64_12,gotip-darwin-amd64_14,gotip-darwin-arm64_12,gotip-darwin-arm64_15
Reviewed-on: https://go-review.googlesource.com/c/go/+/675095
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Allow skipping the deprecation check when GOPROXY=off. The deprecation
check is an informational message so this doesn't affect the success of
the command. We should probably skip the check in more cases when
GOPROXY=off but that's a bigger change that should be made in a later
release.
There are still some deps.dev log messages that we should try to
suppress.
For #68106
Change-Id: Ifa0efd01ed623bb68c7ad7c5cfb6705547d157a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/675155
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Matloob <matloob@google.com>
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
Just like we do in cmd/doc when we start pkgsite, ignore SIGINT (and
SIGQUIT on unix) when we start cmd/doc so that it's handled by cmd/doc
(if pkgsite is not started, and before it is started) or pkgsite, if it
is started. Also exit with the exit status of the command, rather than
using base.Errorf so that we don't print an extra error message to the
terminal.
For #68106
Change-Id: If968e88b95031761432d13dc47c5febe3391945d
Reviewed-on: https://go-review.googlesource.com/c/go/+/675076
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Auto-Submit: Michael Matloob <matloob@google.com>
This is part of a series of CLs that aim to help allocations
in reflect and reduce how often interface arguments escape
for the print functions in fmt.
Before this change, the reflect.Value parameter for packEface leaks
immediately to the heap due to the various ODOTPTR operations on the
*emptyInterface. The -m=2 logs report:
parameter v leaks to <heap> for packEface with derefs=0:
flow: <heap> ← v:
from v.ptr (dot) at .\value.go:145:13
from e.word = v.ptr (assign) at .\value.go:145:10
After this change, the input leaks to the result, which is what
we want:
parameter v leaks to ~r0 with derefs=0:
flow: e = v:
from v.ptr (dot) at .\value.go:143:13
from e.Data = v.ptr (assign) at .\value.go:143:10
flow: ~r0 = e:
from &e (address-of) at .\value.go:147:32
from *(*any)(unsafe.Pointer(&e)) (indirection) at .\value.go:147:9
from return *(*any)(unsafe.Pointer(&e)) (return) at .\value.go:147:2
This change here is needed, but reflect.Value.Interface still leaks its
input to the heap for other reasons having to do with method values,
which we attempt to address in CL 530097, CL 530095, and CL 530096.
Updates #8618
Updates #71349
Change-Id: Ie77bc850ff261212eeafe190bd6f9a879676a51d
Reviewed-on: https://go-review.googlesource.com/c/go/+/528535
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: qiu laidongfeng2 <2645477756@qq.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Updates the skip reason for the following BoGo tests:
* TLS-ECH-Client-TLS12SessionID
* SupportTicketsWithSessionID
* ResumeTLS12SessionID-TLS13
The crypto/tls package does not support session ID based resumption at
this time, and so any tests that rely on this support need to be
skipped.
Updates #72006
Updates #25228
Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5d0
Reviewed-on: https://go-review.googlesource.com/c/go/+/673737
TryBot-Bypass: 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>
The crypto/tls package produces the expected error for this test case,
and so it can be enabled.
Looking at the history of the relevant code it appears the TLS 1.3
implementation has always had the correct behaviour for HRR changing to
an unsupported group after the initial hello.
I think this test was skipped initially because at the time of
initial BoGo config commit we hadn't implemented the -curves argument
for the test shim yet, and this test relies on it. We later added
support for that flag alongside X25519Kyber768Draft00 KX and I think we
missed the chance to enable the test then.
Updates #72006
Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/673756
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Bypass: Daniel McCarney <daniel@binaryparadox.net>
When a pre-TLS 1.3 server processes a client hello message that
indicates compression methods that don't include the null compression
method, send an illegal parameter alert.
Previously we did this for TLS 1.3 server handshakes only, and the
legacy TLS versions used alertHandshakeFailure for this circumstance. By
switching this to alertIllegalParameter we use a consistent alert across
all TLS versions, and can also enable the NoNullCompression-TLS12 BoGo
test we were skipping.
Updates #72006
Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5ce
Reviewed-on: https://go-review.googlesource.com/c/go/+/673736
TryBot-Bypass: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: David Chase <drchase@google.com>
When a crypto/tls client using TLS < 1.3 sends supported elliptic_curves
in a client hello message the server must limit itself to choosing one
of the supported options from our message. If we process a server key
exchange message that chooses an unadvertised curve, abort the
handshake w/ an error.
Previously we would not note that the server chose a curve we didn't
include in the client hello message, and would proceed with the
handshake as long as the chosen curve was one that we've implemented.
However, RFC 8422 5.1 makes it clear this is a server acting
out-of-spec, as it says:
If a server does not understand the Supported Elliptic Curves
Extension, does not understand the Supported Point Formats Extension,
or is unable to complete the ECC handshake while restricting itself
to the enumerated curves and point formats, it MUST NOT negotiate the
use of an ECC cipher suite.
Changing our behaviour to enforce this also allows enabling the
UnsupportedCurve BoGo test.
Updates #72006
Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/673735
TryBot-Bypass: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Our prior CL 649078 teaches the compiler to use a pointer to
runtime.zeroVal as the data pointer for an interface in cases it where
it can see that a zero value struct or array is being used in
an interface conversion.
This applies to some uses with reflect, such as:
s := S{}
v := reflect.ValueOf(s)
This CL builds on that to do a cheap pointer check in reflect.IsZero
to see if the Value points to runtime.zeroVal, which means it is a zero
value.
An alternative might be to do an initial pointer check in the typ.Equal
function for types where it makes sense to do but doesn't already.
This CL gives a performance boost of -51.71% geomean for
BenchmarkZero/IsZero, with most of the impact there on
arrays of structs. (The left column is CL 649078 and the right column
is this CL).
goos: linux
goarch: amd64
pkg: reflect
cpu: Intel(R) Xeon(R) CPU @ 2.80GHz
│ find-zeroVal │ check-zeroVal │
│ sec/op │ sec/op vs base │
Zero/IsZero/ByteArray/size=16-4 4.171n ± 0% 3.123n ± 0% -25.13% (p=0.000 n=20)
Zero/IsZero/ByteArray/size=64-4 3.864n ± 0% 3.129n ± 0% -19.02% (p=0.000 n=20)
Zero/IsZero/ByteArray/size=1024-4 3.878n ± 0% 3.126n ± 0% -19.39% (p=0.000 n=20)
Zero/IsZero/BigStruct/size=1024-4 5.061n ± 0% 3.273n ± 0% -35.34% (p=0.000 n=20)
Zero/IsZero/SmallStruct/size=16-4 4.191n ± 0% 3.275n ± 0% -21.87% (p=0.000 n=20)
Zero/IsZero/SmallStructArray/size=64-4 8.636n ± 0% 3.127n ± 0% -63.79% (p=0.000 n=20)
Zero/IsZero/SmallStructArray/size=1024-4 80.055n ± 0% 3.126n ± 0% -96.10% (p=0.000 n=20)
Zero/IsZero/Time/size=24-4 3.865n ± 0% 3.274n ± 0% -15.29% (p=0.000 n=20)
geomean 6.587n 3.181n -51.71%
Note these are of course micro benchmarks with easily predicted
branches. The extra branch we introduce in the CL might hurt if there
was for example a tight loop where 50% of the values used the
global zeroVal and 50% didn't in a way that is not well predicted,
although if the typ.Equal for many types already does an initial
pointer check, it might not matter much.
For the older BenchmarkIsZero in reflect, this change does not help.
(The compiler does not use the global zeroVal as the data word for the
interfaces in this benchmark because values are part of a larger value
that is too big to be used in the global zeroVal, and also a piece of
the larger value is mutated and is not zero).
│ find-zeroVal │ check-zeroVal │
│ sec/op │ sec/op vs base │
IsZero/ArrayComparable-4 14.58n ± 0% 14.59n ± 0% ~ (p=0.177 n=20)
IsZero/ArrayIncomparable-4 163.8n ± 0% 167.5n ± 0% +2.26% (p=0.000 n=20)
IsZero/StructComparable-4 6.847n ± 0% 6.847n ± 0% ~ (p=0.703 n=20)
IsZero/StructIncomparable-4 35.41n ± 0% 35.10n ± 0% -0.86% (p=0.000 n=20)
IsZero/ArrayInt_4-4 8.631n ± 0% 8.363n ± 0% -3.10% (p=0.000 n=20)
IsZero/ArrayInt_1024-4 265.5n ± 0% 265.4n ± 0% ~ (p=0.288 n=20)
IsZero/ArrayInt_1024_NoZero-4 135.8n ± 0% 136.2n ± 0% +0.33% (p=0.000 n=20)
IsZero/Struct4Int-4 8.451n ± 0% 8.386n ± 0% -0.77% (p=0.000 n=20)
IsZero/ArrayStruct4Int_1024-4 265.2n ± 0% 266.0n ± 0% +0.30% (p=0.000 n=20)
IsZero/ArrayChanInt_1024-4 265.5n ± 0% 265.4n ± 0% ~ (p=0.605 n=20)
IsZero/StructInt_512-4 135.8n ± 0% 135.8n ± 0% ~ (p=0.396 n=20)
geomean 55.22n 55.12n -0.18%
Updates #71323
Change-Id: Ie083853a5bff03856277a293d94532a681f4a8d5
Reviewed-on: https://go-review.googlesource.com/c/go/+/654135
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>
Reviewed-by: Keith Randall <khr@golang.org>
This is a small-ish adjustment to the change earlier in our
stack in CL 649555, which started creating read-only global storage
for a composite literal used in an interface conversion and setting
the interface data pointer to point to that global storage.
In some cases, there are execution-time performance benefits to point
to runtime.zeroVal in particular. In reflect, pointer checks against
the runtime.zeroVal memory address are used to side-step some work,
such as in reflect.Value.Set and reflect.Value.IsZero.
In this CL, we therefore dig up the zeroVal symbol, and we use the
machinery from earlier in our stack to use a pointer to zeroVal for
the interface data pointer if we see examples like:
sink = S{}
or:
s := S{}
sink = s
CL 649076 (also earlier in our stack) added most of the tests
along with debug diagnostics in convert.go to make it easier
to test this change.
We add a benchmark in reflect to show examples of performance benefit.
The left column is our immediately prior CL 649555, and the right is
this CL. (The arrays of structs here do not seem to benefit, which
we attempt to address in our next CL).
goos: linux
goarch: amd64
pkg: reflect
cpu: Intel(R) Xeon(R) CPU @ 2.80GHz
│ cl-649555 │ new │
│ sec/op │ sec/op vs base │
Zero/IsZero/ByteArray/size=16-4 4.176n ± 0% 4.171n ± 0% ~ (p=0.151 n=20)
Zero/IsZero/ByteArray/size=64-4 6.921n ± 0% 3.864n ± 0% -44.16% (p=0.000 n=20)
Zero/IsZero/ByteArray/size=1024-4 21.210n ± 0% 3.878n ± 0% -81.72% (p=0.000 n=20)
Zero/IsZero/BigStruct/size=1024-4 25.505n ± 0% 5.061n ± 0% -80.15% (p=0.000 n=20)
Zero/IsZero/SmallStruct/size=16-4 4.188n ± 0% 4.191n ± 0% ~ (p=0.106 n=20)
Zero/IsZero/SmallStructArray/size=64-4 8.639n ± 0% 8.636n ± 0% ~ (p=0.973 n=20)
Zero/IsZero/SmallStructArray/size=1024-4 79.99n ± 0% 80.06n ± 0% ~ (p=0.213 n=20)
Zero/IsZero/Time/size=24-4 7.232n ± 0% 3.865n ± 0% -46.56% (p=0.000 n=20)
Zero/SetZero/ByteArray/size=16-4 13.47n ± 0% 13.09n ± 0% -2.78% (p=0.000 n=20)
Zero/SetZero/ByteArray/size=64-4 14.14n ± 0% 13.70n ± 0% -3.15% (p=0.000 n=20)
Zero/SetZero/ByteArray/size=1024-4 24.22n ± 0% 20.18n ± 0% -16.68% (p=0.000 n=20)
Zero/SetZero/BigStruct/size=1024-4 24.24n ± 0% 20.18n ± 0% -16.73% (p=0.000 n=20)
Zero/SetZero/SmallStruct/size=16-4 13.45n ± 0% 13.10n ± 0% -2.60% (p=0.000 n=20)
Zero/SetZero/SmallStructArray/size=64-4 14.12n ± 0% 13.69n ± 0% -3.05% (p=0.000 n=20)
Zero/SetZero/SmallStructArray/size=1024-4 24.62n ± 0% 21.61n ± 0% -12.26% (p=0.000 n=20)
Zero/SetZero/Time/size=24-4 13.59n ± 0% 13.40n ± 0% -1.40% (p=0.000 n=20)
geomean 14.06n 10.19n -27.54%
Finally, here are results from the benchmark example from #71323.
Note however that almost all the benefit shown here is from our earlier
CL 649555, which is a more general purpose change and eliminates
the allocation using a different read-only global than this CL.
│ go1.24 │ new │
│ sec/op │ sec/op vs base │
InterfaceAny 112.6000n ± 5% 0.8078n ± 3% -99.28% (p=0.000 n=20)
ReflectValue 11.63n ± 2% 11.59n ± 0% ~ (p=0.330 n=20)
│ go1.24.out │ new.out │
│ B/op │ B/op vs base │
InterfaceAny 224.0 ± 0% 0.0 ± 0% -100.00% (p=0.000 n=20)
ReflectValue 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=20) ¹
│ go1.24.out │ new.out │
│ allocs/op │ allocs/op vs base │
InterfaceAny 1.000 ± 0% 0.000 ± 0% -100.00% (p=0.000 n=20)
ReflectValue 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=20) ¹
Updates #71359
Updates #71323
Change-Id: I64d8cf1a7900f011d2ec59b948388aeda1150676
Reviewed-on: https://go-review.googlesource.com/c/go/+/649078
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: David Chase <drchase@google.com>
Today, this interface conversion causes the struct literal
to be heap allocated:
var sink any
func example1() {
sink = S{1, 1}
}
For basic literals like integers that are directly used in
an interface conversion that would otherwise allocate, the compiler
is able to use read-only global storage (see #18704).
This CL extends that to struct and array literals as well by creating
read-only global storage that is able to represent for example S{1, 1},
and then using a pointer to that storage in the interface
when the interface conversion happens.
A more challenging example is:
func example2() {
v := S{1, 1}
sink = v
}
In this case, the struct literal is not directly part of the
interface conversion, but is instead assigned to a local variable.
To still avoid heap allocation in cases like this, in walk we
construct a cache that maps from expressions used in interface
conversions to earlier expressions that can be used to represent the
same value (via ir.ReassignOracle.StaticValue). This is somewhat
analogous to how we avoided heap allocation for basic literals in
CL 649077 earlier in our stack, though here we also need to do a
little more work to create the read-only global.
CL 649076 (also earlier in our stack) added most of the tests
along with debug diagnostics in convert.go to make it easier
to test this change.
See the writeup in #71359 for details.
Fixes#71359Fixes#71323
Updates #62653
Updates #53465
Updates #8618
Change-Id: I8924f0c69ff738ea33439bd6af7b4066af493b90
Reviewed-on: https://go-review.googlesource.com/c/go/+/649555
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>
Previously the common Config.mutualVersion() code prioritized the
selected version based on the provided peerVersions being sent in peer
preference order.
Instead we would prefer to see TLS 1.3 used whenever it is
supported, even if the peer would prefer an older protocol version.
This commit updates mutualVersions() to implement this policy change.
Our new behaviour matches the behaviour of other TLS stacks, notably
BoringSSL, and so also allows enabling the IgnoreClientVersionOrder BoGo
test that we otherwise must skip.
Updates #72006
Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/673236
Auto-Submit: Daniel McCarney <daniel@binaryparadox.net>
TryBot-Bypass: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Drop the entire pre-AVX2 assembly implementation of SHA-1, SHA-256, and
SHA-512. This also technically impacts the SHA-1 AVX2 implementation,
since it previously called the pre-AVX2 implementation for the last
block if the number of blocks wasn't a multiple of 2.
Instead of keeping the entire implementation just for that case, we
just call the generic implementation for the last block. This will be a
little slower, but still seems like a win.
Updates #69587
Change-Id: Id5234c42910d8c6ec6b8df700a721c0953dff02b
Reviewed-on: https://go-review.googlesource.com/c/go/+/657716
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: 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>
Currently, the integer value in the following interface conversion gets
heap allocated:
v := 1000
fmt.Println(v)
In contrast, this conversion does not currently cause the integer value
to be heap allocated:
fmt.Println(1000)
The second example is able to avoid heap allocation because of an
optimization in walk (by Josh in #18704 and related issues) that
recognizes a literal is being used. In the first example, that
optimization is currently thwarted by the literal getting assigned
to a local variable prior to use in the interface conversion.
This CL propagates constants to interface conversions like
in the first example to avoid heap allocations, instead using
a read-only global. The net effect is roughly turning the first example
into the second.
One place this comes up in practice currently is with logging or
debug prints. For example, if we have something like:
func conditionalDebugf(format string, args ...interface{}) {
if debugEnabled {
fmt.Fprintf(io.Discard, format, args...)
}
}
Prior to this CL, this integer is heap allocated, even when the
debugEnabled flag is false, and even when the compiler
inlines conditionalDebugf:
v := 1000
conditionalDebugf("hello %d", v)
With this CL, the integer here is no longer heap allocated, even when
the debugEnabled flag is enabled, because the compiler can now see that
it can use a read-only global.
See the writeup in #71359 for more details.
CL 649076 (earlier in our stack) added most of the tests
along with debug diagnostics in convert.go to make it easier
to test this change.
Updates #71359
Updates #62653
Updates #53465
Updates #8618
Change-Id: I19a51e74b36576ebb0b9cf599267cbd2bd847ce4
Reviewed-on: https://go-review.googlesource.com/c/go/+/649079
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>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Using the new-ish ir.ReassignOracle is more efficient than calling
ir.StaticValue repeatedly.
This CL now uses an ir.ReassignOracle for the recent
make constant propagation introduced in CL 649035.
We also pull the main change from CL 649035 into a new function,
which we will update later in our stack. We will also use the
ReassignOracles introduced here later in our stack.
(We originally did most of this work in CL 649077, but we abandoned
that in favor of CL 649035).
We could also use an ir.ReassignOracle in the older processing of
ir.OCALLFUNC in (*escape).call, but for now, we just leave that
as a TODO.
Updates #71359
Change-Id: I6e02eeac269bde3a302622b4dfe0c8dc63ec9ffc
Reviewed-on: https://go-review.googlesource.com/c/go/+/673795
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>
Reviewed-by: David Chase <drchase@google.com>
Uses the new weak package to replace the existing custom intern cache
with a map of weak.Pointers instead. This simplifies the cache, and
means we don't need to store a slice of handles on the Conn anymore.
Change-Id: I5c2bf6ef35fac4255e140e184f4e48574b34174c
Reviewed-on: https://go-review.googlesource.com/c/go/+/644176
TryBot-Bypass: Roland Shoemaker <roland@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Roland Shoemaker <roland@golang.org>
This CL adds two related features enabled by default via compatibility
GODEBUGs containermaxprocs and updatemaxprocs.
On Linux, containermaxprocs makes the Go runtime consider cgroup CPU
bandwidth limits (quota/period) when setting GOMAXPROCS. If the cgroup
limit is lower than the number of logical CPUs available, then the
cgroup limit takes precedence.
On all OSes, updatemaxprocs makes the Go runtime periodically
recalculate the default GOMAXPROCS value and update GOMAXPROCS if it has
changed. If GOMAXPROCS is set manually, this update does not occur. This
is intended primarily to detect changes to cgroup limits, but it applies
on all OSes because the CPU affinity mask can change as well.
The runtime only considers the limit in the leaf cgroup (the one that
actually contains the process), caching the CPU limit file
descriptor(s), which are periodically reread for updates. This is a
small departure from the original proposed design. It will not consider
limits of parent cgroups (which may be lower than the leaf), and it will
not detection cgroup migration after process start.
We can consider changing this in the future, but the simpler approach is
less invasive; less risk to packages that have some awareness of runtime
internals. e.g., if the runtime periodically opens new files during
execution, file descriptor leak detection is difficult to implement in a
stable way.
For #73193.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest
Change-Id: I6a6a636c631c1ae577fb8254960377ba91c5dc98
Reviewed-on: https://go-review.googlesource.com/c/go/+/670497
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Add build tag gated Valgrind annotations to the runtime which let it
understand how the runtime manages memory. This allows for Go binaries
to be run under Valgrind without emitting spurious errors.
Instead of adding the Valgrind headers to the tree, and using cgo to
call the various Valgrind client request macros, we just add an assembly
function which emits the necessary instructions to trigger client
requests.
In particular we add instrumentation of the memory allocator, using a
two-level mempool structure (as described in the Valgrind manual [0]).
We also add annotations which allow Valgrind to track which memory we
use for stacks, which seems necessary to let it properly function.
We describe the memory model to Valgrind as follows: we treat heap
arenas as a "pool" created with VALGRIND_CREATE_MEMPOOL_EXT (so that we
can use VALGRIND_MEMPOOL_METAPOOL and VALGRIND_MEMPOOL_AUTO_FREE).
Within the pool we treat spans as "superblocks", annotated with
VALGRIND_MEMPOOL_ALLOC. We then allocate individual objects within spans
with VALGRIND_MALLOCLIKE_BLOCK.
It should be noted that running binaries under Valgrind can be _quite
slow_, and certain operations, such as running the GC, can be _very
slow_. It is recommended to run programs with GOGC=off. Additionally,
async preemption should be turned off, since it'll cause strange
behavior (GODEBUG=asyncpreemptoff=1).
Running Valgrind with --leak-check=yes will result in some errors
resulting from some things not being marked fully free'd. These likely
need more annotations to rectify, but for now it is recommended to run
with --leak-check=off.
Updates #73602
[0] https://valgrind.org/docs/manual/mc-manual.html#mc-manual.mempools
Change-Id: I71b26c47d7084de71ef1e03947ef6b1cc6d38301
Reviewed-on: https://go-review.googlesource.com/c/go/+/674077
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
go doc tries to find a package to display documentation for. In the case
that no package is provided, it uses "." just like go list does. So if
go doc -http is run without any arguments, it tries to show the
documentation for the package in the current directory. As a special
case, if no arguments are provided, allow no package to match the
current directory and just open the root pkgsite page.
For #68106
Change-Id: I6d65b160a838591db953fac630eced6b09106877
Reviewed-on: https://go-review.googlesource.com/c/go/+/675075
Reviewed-by: Alan Donovan <adonovan@google.com>
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently the checkfinalizers test (TestDetectCleanupOrFinalizerLeak)
only *tries* to ensure the tiny alloc with a cleanup attached shares a
block with other objects. However, what it does is insufficient, because
it could get unlucky and have the last object allocated be the first
object of a new block.
This change changes the test to guarantee that a tiny object is not at
the start of a fresh block by looking at the alignment of the object's
pointer. If the object's pointer is odd, then that's good enough to know
that it shares a block with something else, since the blocks themselves
are aligned to a much higher power of two.
This fixes a failure I've seen on the builders.
Fixes#73810.
Change-Id: Ieafdbb9cccb0d2dc3659a9a5d9d9233718461635
Reviewed-on: https://go-review.googlesource.com/c/go/+/674655
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
The types being hoisted are those which cannot be referenced; that is,
where Ref[T] is illegal. These are most clearly owned by pkgbits. The
types which follow are those which can be referenced.
Referenceable types are more hazy due to the reference mechanism of UIR
- sections. These are a detail of the UIR file format and are surfaced
directly to importers.
I suspect that pkgbits would benefit from a reference mechanism not
dependent on sections. This would permit us to push down many types
from the noder into pkgbits, reducing the interface surface without
giving up deduplication.
Change-Id: Ifaf5cd9de20c767ad0941413385b308d628aac6c
Reviewed-on: https://go-review.googlesource.com/c/go/+/674635
Auto-Submit: Mark Freeman <mark@golang.org>
TryBot-Bypass: Mark Freeman <mark@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Add generator tests that verify the timestamps for the sync events
emitted in the go1.25 trace format and earlier versions.
Add the ability to configure the properties of the per-generation sync
batches in testgen. Also refactor testgen to produce more realistic
timestamps by keeping track of lastTs and using it for structural
batches that don't have their own timestamps. Otherwise they default to
zero which means the minTs of the generation can't be controlled.
For #69869
Change-Id: I92a49b8281bc4169b63e13c030c1de7720cd6f26
Reviewed-on: https://go-review.googlesource.com/c/go/+/653876
Auto-Submit: 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>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Replace the per-generation EvEventBatch containing a lone EvFrequency
event with a per-generation EvEventBatch containing a EvSync header
followed by an EvFrequency and EvClockSnapshot event.
The new EvClockSnapshot event contains trace, mono and wall clock
snapshots taken in close time proximity. Ignoring minor resolution
differences, the trace and mono clock are the same on linux, but not on
windows (which still uses a TSC based trace clock).
Emit the new sync batch at the very beginning of every new generation
rather than the end to be in harmony with the internal/trace reader
which emits a sync event at the beginning of every generation as well
and guarantees monotonically increasing event timestamps.
Bump the version of the trace file format to 1.25 since this change is
not backwards compatible.
Update the internal/trace reader implementation to decode the new
events, but do not expose them to the public reader API yet. This is
done in the next CL.
For #69869
Change-Id: I5bfedccdd23dc0adaf2401ec0970cbcc32363393
Reviewed-on: https://go-review.googlesource.com/c/go/+/653575
Reviewed-by: David Chase <drchase@google.com>
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>
The RISC-V integer vector multiply add instructions are not encoded
correctly; the first and second arguments are swapped. For example,
the instruction
VMACCVV V1, V2, V3
encodes to
b620a1d7 or vmacc.vv v3,v1,v2
and not
b61121d7 or vmacc.vv v3,v2,v1
as expected.
This is inconsistent with the argument ordering we use for 3
argument vector instructions, in which the argument order, as given
in the RISC-V specifications, is reversed, and also with the vector
FMA instructions which have the same argument ordering as the vector
integer multiply add instructions in the "The RISC-V Instruction Set
Manual Volume I". For example, in the ISA manual we have the
following instruction definitions
; Integer multiply-add, overwrite addend
vmacc.vv vd, vs1, vs2, vm # vd[i] = +(vs1[i] * vs2[i]) + vd[i]
; FP multiply-accumulate, overwrites addend
vfmacc.vv vd, vs1, vs2, vm # vd[i] = +(vs1[i] * vs2[i]) + vd[i]
It's reasonable to expect that the Go assembler would use the same
argument ordering for both of these instructions. It currently does
not.
We fix the issue by switching the argument ordering for the vector
integer multiply add instructions to match those of the vector FMA
instructions.
Change-Id: Ib98e9999617f991969e5c831734b3bb3324439f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/670335
Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
For the package github.com/microsoft/typescript-go/internal/checker,
compilation currently spends most of its time in escape analysis.
Here, we re-order work to be more efficient when analyzing many
locations, and delay visiting some locations to prioritize locations
that might be more likely to reach a terminal point of reaching the
heap and possibly reduce the count of intermediate states for each location.
Action graph reported build times show roughly a 5x improvement for
compilation of the typescript-go/internal/checker package:
go1.24.0: 91.792s
cl-657179-ps1: 17.578s
with timing via:
go build -a -debug-actiongraph=/tmp/actiongraph-cl-657179-ps1 -v github.com/microsoft/typescript-go/internal/checker
There are some additional adjustments to make here, including we can
consider a follow-on CL I have that parallelizes the operations of the
core loop, but this seems to be a nice win as is, and my understanding
is the desire is to merge this as it stands.
Updates #72815
Change-Id: I1753c5354b495b059f68fb97f3103ee7834f9eee
Reviewed-on: https://go-review.googlesource.com/c/go/+/657179
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>
All private keys need to go through a slow PCT in FIPS-140 mode.
ECDH and RSA keys have places to hide a precomputed value without
causing races, but Ed25519 and ECDSA keys might be constructed by the
application and then used with concurrent Sign calls.
For these, implement an equivalent to crypto/internal/boring/bcache
using weak.Pointer and runtime.AddCleanup.
fips140: latest
goos: linux
goarch: amd64
pkg: crypto/ed25519
cpu: AMD Ryzen 7 PRO 8700GE w/ Radeon 780M Graphics
│ 1a93e4a2cf │ 78a819ea78 │
│ sec/op │ sec/op vs base │
Signing-16 72.72µ ± 0% 16.93µ ± 1% -76.72% (p=0.002 n=6)
fips140: off
goos: linux
goarch: amd64
pkg: crypto/ed25519
cpu: AMD Ryzen 7 PRO 8700GE w/ Radeon 780M Graphics
│ 310bad31e5 │ 310bad31e5-dirty │
│ sec/op │ sec/op vs base │
Signing-16 17.18µ ± 1% 16.95µ ± 1% -1.36% (p=0.002 n=6)
fips140: latest
goos: linux
goarch: amd64
pkg: crypto/ecdsa
cpu: AMD Ryzen 7 PRO 8700GE w/ Radeon 780M Graphics
│ 1a93e4a2cf │ 78a819ea78 │
│ sec/op │ sec/op vs base │
Sign/P256-16 90.97µ ± 0% 21.04µ ± 0% -76.87% (p=0.002 n=6)
Sign/P384-16 701.6µ ± 1% 142.0µ ± 0% -79.75% (p=0.002 n=6)
Sign/P521-16 2943.5µ ± 1% 491.9µ ± 0% -83.29% (p=0.002 n=6)
fips140: off
goos: linux
goarch: amd64
pkg: crypto/ecdsa
cpu: AMD Ryzen 7 PRO 8700GE w/ Radeon 780M Graphics
│ 1a93e4a2cf │ 78a819ea78 │
│ sec/op │ sec/op vs base │
Sign/P256-16 21.27µ ± 0% 21.13µ ± 0% -0.65% (p=0.002 n=6)
Sign/P384-16 143.3µ ± 0% 142.4µ ± 0% -0.63% (p=0.009 n=6)
Sign/P521-16 525.3µ ± 0% 462.1µ ± 0% -12.04% (p=0.002 n=6)
This unavoidably introduces allocations in the very first use of Ed25519
private keys, but usually that's not in the hot path.
Change-Id: I6a6a465640a5dff64edd73ee5dda5f2ad1b476b9
Reviewed-on: https://go-review.googlesource.com/c/go/+/654096
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Replace the hchan.synctest bool with an hchan.bubble reference
to the synctest bubble that created the chan. I originally used
a bool to avoid increasing the size of hchan, but we have space
in hchan's current size class for another pointer.
This lets us detect one bubble operating on a chan created
in a different bubble.
For #67434
Change-Id: If6cf9ffcb372fe7fb3f8f4ef27b664848578ba5c
Reviewed-on: https://go-review.googlesource.com/c/go/+/674515
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
Use a sync.OnceValue rather than a sync.WaitGroup to
coordinate access to encoderCache entries.
The OnceValue better expresses the intent of the code
(we want to initialize the cache entry only once).
However, the motivation for this change is to avoid
testing/synctest incorrectly reporting a deadlock
when multiple bubbles call Marshal at the same time.
Goroutines blocked on WaitGroup.Wait are "durably blocked",
causing confusion when a goroutine in one bubble Waits
for a goroutine in a different bubble. Goroutines blocked
on OnceValue are not durably blocked, avoiding the problem.
Fixes#73733
For #67434
Change-Id: I81cddda80af67cf5c280fd4327620bc37e7a6fe6
Reviewed-on: https://go-review.googlesource.com/c/go/+/673335
Auto-Submit: Damien Neil <dneil@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This change switches the pkgsite command invoked to start a pkgsite
server from golang.org/x/pkgsite/cmd/pkgsite to
golang.org/x/pkgsite/cmd/internal/doc. The doc command is a simplified
version of cmd/pkgsite that changes some options to improve the user
experience. For example, it limits logging informational log messages,
doesn't always expect to find modules (for example if we're outside of a
module getting documentation for the standard library), and it takes the
address of the page to open in the browser (which simplifies waiting for
the server to start listening).
Fixes#68106
Change-Id: I667a49d03823242fa1aff333ecb1c0f198e92412
Reviewed-on: https://go-review.googlesource.com/c/go/+/674158
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Reviewed-by: David Chase <drchase@google.com>
cmd/doc uses go/build to get information about the packages it's
documenting. In some cases, go/build can return a build.Package that it
couldn't determine an import path for, in which case it sets the import
path to ".". This can happen for relative package paths in in a module:
for relative package paths we don't use the go command to get
information about the module and just open the source files directly
instead, and will be missing the import path. This is usually okay
because go doc doesn't need to print the import path of the package it's
documenting, but for go doc -http, we want to know the import path so we
can open the right page in the browser.
For #68106
Change-Id: Ifba92862ad01d8d63f531c2451f18db2b0d7a3e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/674556
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Michael Matloob <matloob@google.com>
This fixes a bug where we start pkgsite for every requested object,
rather than the one that we would have printed the documentation for.
To make things simple, we'll run the logic that prints the
documentation, but with an io.Discard writer. Then we can tell if the
documentation was found based on the return values of those functions.
For #68106
Change-Id: Ibf2ab1720f381d7214fc9239b9c2e915c91f7f7b
Reviewed-on: https://go-review.googlesource.com/c/go/+/674555
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
This implementation is zero-alloc when T is a concrete type,
allocates when val contains a method or when T is a interface
and Value was obtained for example through Elem(), in which case
it has to be allocated to avoid sharing the same memory.
goos: linux
goarch: amd64
pkg: reflect
cpu: AMD Ryzen 5 4600G with Radeon Graphics
│ /tmp/bench2 │
│ sec/op │
TypeAssert/TypeAssert[int](int)-12 2.725n ± 1%
TypeAssert/TypeAssert[uint8](int)-12 2.599n ± 1%
TypeAssert/TypeAssert[fmt.Stringer](reflect_test.testTypeWithMethod)-12 8.470n ± 0%
TypeAssert/TypeAssert[fmt.Stringer](*reflect_test.testTypeWithMethod)-12 8.460n ± 1%
TypeAssert/TypeAssert[interface_{}](int)-12 4.181n ± 1%
TypeAssert/TypeAssert[interface_{}](reflect_test.testTypeWithMethod)-12 4.178n ± 1%
TypeAssert/TypeAssert[time.Time](time.Time)-12 2.839n ± 0%
TypeAssert/TypeAssert[func()_string](func()_string)-12 151.1n ± 1%
geomean 6.645n
│ /tmp/bench2 │
│ B/op │
TypeAssert/TypeAssert[int](int)-12 0.000 ± 0%
TypeAssert/TypeAssert[uint8](int)-12 0.000 ± 0%
TypeAssert/TypeAssert[fmt.Stringer](reflect_test.testTypeWithMethod)-12 0.000 ± 0%
TypeAssert/TypeAssert[fmt.Stringer](*reflect_test.testTypeWithMethod)-12 0.000 ± 0%
TypeAssert/TypeAssert[interface_{}](int)-12 0.000 ± 0%
TypeAssert/TypeAssert[interface_{}](reflect_test.testTypeWithMethod)-12 0.000 ± 0%
TypeAssert/TypeAssert[time.Time](time.Time)-12 0.000 ± 0%
TypeAssert/TypeAssert[func()_string](func()_string)-12 72.00 ± 0%
geomean ¹
Fixes#62121
Change-Id: I0911c70c5966672c930d387438643f94a40441c4
GitHub-Last-Rev: ce89a53097
GitHub-Pull-Request: golang/go#71639
Reviewed-on: https://go-review.googlesource.com/c/go/+/648056
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>
For goroutines in a synctest bubble, include whether the goroutine
is "durably blocked" or not in the goroutine status.
Synctest categorizes goroutines in certain states as "durably"
blocked, where the goroutine is not merely idle but can only
be awoken by another goroutine in its bubble. To make it easier
for users to understand why a bubble is or is not idle,
print the state of each bubbled goroutine.
For example:
goroutine 36 [chan receive, synctest bubble 34, not durably blocked]:
goroutine 37 [chan receive (synctest), synctest bubble 34, durably blocked]:
Goroutine 36 is receiving from a channel created outside its bubble.
Goroutine 36 is receiving from a channel created inside its bubble.
For #67434
Change-Id: I006b656a9ce7eeb75b2be21e748440a5dd57ceb0
Reviewed-on: https://go-review.googlesource.com/c/go/+/670976
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>
Before this change, when we tried to compute the set of packages in
'all', we'd add packages with invalid import paths to the set and try to
load them, which would fail. Instead, do not add them to the list of
packages to load in the second iteration of the loader. We'll still
return errors for invalid imports in the importing packages.
Change-Id: I682229011f555ed1d0c827f79100c1c43bf7f93a
Reviewed-on: https://go-review.googlesource.com/c/go/+/673655
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>
This new debug mode detects cleanup/finalizer leaks using checkmark
mode. It runs a partial GC using only specials as roots. If the GC can
find a path from one of these roots back to the object the special is
attached to, then the object might never be reclaimed. (The cycle could
be broken in the future, but it's almost certainly a bug.)
This debug mode is very barebones. It contains no type information and
no stack location for where the finalizer or cleanup was created.
For #72949.
Change-Id: Ibffd64c1380b51f281950e4cfe61f677385d42a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/634599
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>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
When an errorcheck test uses -m and instantiates an imported generic
function, the errors will include -m messages from the imported package
(since the new function has not previously been walked). These errors
cannot be matched since we can't write errors in files outside the test
input.
To fix this (and enable the other CLs in this stack), drop any unmatched
errors that occur in files outside those in the input set.
Change-Id: I2fcf0dd4693125d2e5823ea4437011730d8b1b1f
Reviewed-on: https://go-review.googlesource.com/c/go/+/672515
Reviewed-by: Michael Knyszek <mknyszek@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: Michael Pratt <mpratt@google.com>
This adds additional logging for the work that walk does to reduce
how often an interface conversion results in an allocation.
Also, as part of #71359, we will be updating how escape analysis and
walk handle basic literals, composite literals, and zero values,
so add some tests that uses this new logging.
By the end of our CL stack, we address all of these tests.
Updates #71359
Change-Id: I43fde8343d9aacaec1e05360417908014a86c8bd
Reviewed-on: https://go-review.googlesource.com/c/go/+/649076
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
CL 614257 refactored mallocgc but lost an optimization: if a span for a
large object is already backed by memory fresh from the OS (and thus
zeroed), we don't need to zero it. CL 614257 unconditionally zeroed
spans for large objects that contain pointers.
This change restores the optimization from before CL 614257, which seems
to matter in some real-world programs.
While we're here, let's also fix a hole with the garbage collector being
able to observe uninitialized memory of the large object is observed
by the conservative scanner before being published. The gory details are
in a comment in heapSetTypeLarge. In short, this change makes
span.largeType an atomic variable, such that the GC can only observe
initialized memory if span.largeType != nil.
Fixes#72991.
Change-Id: I2048aeb220ab363d252ffda7d980b8788e9674dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/659956
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: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com>
Currently, it's possible for asynchronous preemption to observe a
partially initialized object. The sequence of events goes like this:
- The GC is in the mark phase.
- Thread T1 is allocating object O1.
- Thread T1 zeroes the allocation, runs the publication barrier, and
updates freeIndexForScan. It has not yet updated the mark bit on O1.
- Thread T2 is conservatively scanning some stack frame.
That stack frame has a dead pointer with the same address as O1.
- T2 picks up the pointer, checks isFree (which checks
freeIndexForScan without an import barrier), and sees that O1 is
allocated. It marks and queues O1.
- T2 then goes to scan O1, and observes uninitialized memory.
Although a publication barrier was executed, T2 did not have an import
barrier. T2 may thus observe T1's writes to zero the object out-of-order
with the write to freeIndexForScan.
Normally this would be impossible if T2 got a pointer to O1 from
somewhere written by T1. The publication barrier guarantees that if the
read side is data-dependent on the write side then we'd necessarily
observe all writes to O1 before T1 published it. However, T2 got the
pointer 'out of thin air' by scanning a stack frame with a dead pointer
on it.
One fix to this problem would be to add the import barrier in the
conservative scanner. We would then also need to put freeIndexForScan
behind the publication barrier, or make the write to freeIndexForScan
exactly that barrier.
However, there's a simpler way. We don't actually care if conservative
scanning observes a stale freeIndexForScan during the mark phase.
Newly-allocated memory is always marked at the point of allocation (the
allocate-black policy part of the GC's design). So it doesn't actually
matter that if the garbage collector scans that memory or not.
This change modifies the allocator to only update freeIndexForScan
outside the mark phase. This means freeIndexForScan is essentially
a snapshot of freeindex at the point the mark phase started. Because
there's no more race between conservative scanning and newly-allocated
objects, the complicated scenario above is no longer a possibility.
One thing we do have to be careful of is other callers of isFree.
Previously freeIndexForScan would always track freeindex, now it no
longer does. This change thus introduces isFreeOrNewlyAllocated which is
used by the conservative scanner, and uses freeIndexForScan. Meanwhile
isFree goes back to using freeindex like it used to. This change also
documents the requirement on isFree that the caller must have obtained
the pointer not 'out of thin air' but after the object was published.
isFree is not currently used anywhere particularly sensitive (heap dump
and checkmark mode, where the world is stopped in both cases) so using
freeindex is both conceptually simple and also safe.
Change-Id: If66b8c536b775971203fb4358c17d711c2944723
Reviewed-on: https://go-review.googlesource.com/c/go/+/672340
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
CL 518776 deleted the cmd/go/internal/modconv package and dropped the
ability to import dependency requirements from ~nine or so legacy
pre-module dependency configuration files. Part of the rationale from
Russ in 2023 for dropping that support was that "by now no one is
running into those configs anymore during 'go mod init'".
For two of those legacy file formats, Godeps.json and vendor.json, the
ability to import their listed dependencies was dropped in CL 518776,
but what remained for those two formats was the ability to guess the
resulting module name in the absence of a name being supplied to 'go mod
init'.
This could be explained by the fact that this smaller functionality for
guessing a module name was separate, did not rely on the deleted modconv
package, and instead only relied on simple JSON parsing.
The name guessing was helpful as part of the transition when module
support was initially released, but it was never perfect, including the
various third-party dependency managers did not all have the same naming
rules that were enforced by modules.
In short, it is very unlikely anyone is relying on this now, so we
delete it.
This CL was spawned from discussion in two related documentation CLs
(CL 662675 and CL 662695).
Updates #71537
Change-Id: I9e087aa296580239562a0ecee58913c5edc533ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/664315
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Sam Thanawalla <samthanawalla@google.com>
In regalloc, we allocate some values to registers before loop entry,
so that they don't need to be loaded (from spill locations) during
the loop.
But it is pointless if we've already regalloc'd the loop body.
Whatever restores we needed for the body are already generated.
It's not clear if this code is ever useful. No tests fail if I just
remove it. But at least this change is worthwhile. It doesn't help,
and it actively inserts more restores than we really need (mostly
because the desired register list is approximate - I have seen cases
where the loads implicated here end up being dead because the restores
hit the wrong registers and the edge shuffle pass knows it needs
the restores in different registers).
While we are here, might as well have layoutRegallocOrder return
the standard layout order instead of recomputing it.
Change-Id: Ia624d5121de59b6123492603695de50b272b277f
Reviewed-on: https://go-review.googlesource.com/c/go/+/672735
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: David Chase <drchase@google.com>
When appending, if the backing store doesn't escape and a
constant-sized backing store is big enough, use a constant-sized
stack-allocated backing store instead of allocating it from the heap.
cmd/go is <0.1% bigger.
As an example of how this helps, if you edit strings/strings.go:FieldsFunc
to replace
spans := make([]span, 0, 32)
with
var spans []span
then this CL removes the first 2 allocations that are part of the growth sequence:
│ base │ exp │
│ allocs/op │ allocs/op vs base │
FieldsFunc/ASCII/16-24 3.000 ± ∞ ¹ 2.000 ± ∞ ¹ -33.33% (p=0.008 n=5)
FieldsFunc/ASCII/256-24 7.000 ± ∞ ¹ 5.000 ± ∞ ¹ -28.57% (p=0.008 n=5)
FieldsFunc/ASCII/4096-24 11.000 ± ∞ ¹ 9.000 ± ∞ ¹ -18.18% (p=0.008 n=5)
FieldsFunc/ASCII/65536-24 18.00 ± ∞ ¹ 16.00 ± ∞ ¹ -11.11% (p=0.008 n=5)
FieldsFunc/ASCII/1048576-24 30.00 ± ∞ ¹ 28.00 ± ∞ ¹ -6.67% (p=0.008 n=5)
FieldsFunc/Mixed/16-24 2.000 ± ∞ ¹ 2.000 ± ∞ ¹ ~ (p=1.000 n=5)
FieldsFunc/Mixed/256-24 7.000 ± ∞ ¹ 5.000 ± ∞ ¹ -28.57% (p=0.008 n=5)
FieldsFunc/Mixed/4096-24 11.000 ± ∞ ¹ 9.000 ± ∞ ¹ -18.18% (p=0.008 n=5)
FieldsFunc/Mixed/65536-24 18.00 ± ∞ ¹ 16.00 ± ∞ ¹ -11.11% (p=0.008 n=5)
FieldsFunc/Mixed/1048576-24 30.00 ± ∞ ¹ 28.00 ± ∞ ¹ -6.67% (p=0.008 n=5)
(Of course, people have spotted and fixed a bunch of allocation sites
like this, but now we're ~automatically doing it everywhere going forward.)
No significant increases in frame sizes in cmd/go.
Change-Id: I301c4d9676667eacdae0058960321041d173751a
Reviewed-on: https://go-review.googlesource.com/c/go/+/664299
Reviewed-by: Keith Randall <khr@google.com>
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>
Sync is used in the definition of primitives and documented by pkgbits.
It's not much help to also document it here.
Change-Id: I18bd0c7816f8249483550a1f0af7c76b9cfe09fb
Reviewed-on: https://go-review.googlesource.com/c/go/+/674156
Auto-Submit: Mark Freeman <mark@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Bypass: Mark Freeman <mark@golang.org>
ncpu is the total logical CPU count at startup. It is never updated. For
#73193, we will start using updated CPU counts for updated GOMAXPROCS,
making the ncpu name a bit ambiguous. Change to a less ambiguous name.
While we're at it, give the OS specific lookup functions a common name,
so it can be used outside of osinit later.
For #73193.
Change-Id: I6a6a636cf21cc60de36b211f3c374080849fc667
Reviewed-on: https://go-review.googlesource.com/c/go/+/672277
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>
Positions mostly borrow their representation from package syntax. Of
note, constants (such as the zero value for positions) are not encoded
directly. Rather, a flag typically signals such values.
Change-Id: I6b4bafc6e96bb21902dd2d6e164031e7dd5aabdd
Reviewed-on: https://go-review.googlesource.com/c/go/+/673535
TryBot-Bypass: Mark Freeman <mark@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Mark Freeman <mark@golang.org>
asancall and msancall are reachable from the signal handler, where we
are running on gsignal. Currently, these calls will use the g0 stack in
this case, but if the interrupted code was running on g0 this will
corrupt the stack and likely cause a crash.
As far as I know, racecall is not reachable from the signal handler, but
I have updated it as well for consistency.
This is the most straightforward fix, though it would be nice to
eventually migrate these wrappers to asmcgocall, which already handled
this case.
Fixes#71395.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-asan-clang15,gotip-linux-amd64-msan-clang15,gotip-linux-amd64-race
Change-Id: I6a6a636ccba826dd53e31c0e85b5d42fb1e98d12
Reviewed-on: https://go-review.googlesource.com/c/go/+/643875
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>
The tests using testprog / testprogcgo are currently not covered on the
asan/msan/race builders because they don't build testprog with the
sanitizer flag.
Explicitly pass the flag if the test itself is built with the sanitizer.
There were a few tests that explicitly passed -race (even on non-race
builders). These tests will now only run on race builders.
For #71395.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-asan-clang15,gotip-linux-amd64-msan-clang15,gotip-linux-amd64-race
Change-Id: I6a6a636ce8271246316a80d426c0e4e2f6ab99c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/643897
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>
Previously, distpack filtered out tools from the packaged distribution
using a list of tools to remove. Instead follow mpratt's suggestion on
CL 666755 and instead filter out tools that are not on a list of tools
to keep. This will make it easier to tell which tools are actually in
the distribution.
For #71867
Change-Id: I8336465703ac820028c3381a0a743c457997e78a
Reviewed-on: https://go-review.googlesource.com/c/go/+/673696
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Matloob <matloob@google.com>
This CL enables intrinsic support to emit the following prefetch
instructions for loong64 platform:
1.Prefetch - prefetches data from memory address to cache;
2.PrefetchStreamed - prefetches data from memory address, with a
hint that this data is being streamed.
Benchmarks picked from go/test/bench/garbage
Parameters tested with:
GOMAXPROCS=8
tree2 -heapsize=1000000000 -cpus=8
tree -n=18
parser
peano
Benchmarks Loongson-3A6000-HV @ 2500.00MHz:
| bench.old | bench.new |
| sec/op | sec/op vs base |
Tree2-8 1238.2µ ± 24% 999.9µ ± 453% ~ (p=0.089 n=10)
Tree-8 277.4m ± 1% 275.5m ± 1% ~ (p=0.063 n=10)
Parser-8 3.564 ± 0% 3.509 ± 1% -1.56% (p=0.000 n=10)
Peano-8 39.12m ± 2% 38.85m ± 2% ~ (p=0.353 n=10)
geomean 83.19m 78.28m -5.90%
Change-Id: I59e9aa4f609a106d4f70706e6d6d1fe6738ab72a
Reviewed-on: https://go-review.googlesource.com/c/go/+/671876
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Meidan Li <limeidan@loongson.cn>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: sophie zhao <zhaoxiaolin@loongson.cn>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Deeply nested parenthesized expressions could cause a stack
overflow during parsing. This change introduces a depth limit
(maxStackDepth) tracked in Tree.stackDepth to prevent this.
Additionally, this commit clarifies the security model in
the package documentation, noting that template authors
are trusted as text/template does not auto-escape.
Fixes#71201
Change-Id: Iab2c2ea6c193ceb44bb2bc7554f3fccf99a9542f
GitHub-Last-Rev: f4ebd1719f
GitHub-Pull-Request: golang/go#73670
Reviewed-on: https://go-review.googlesource.com/c/go/+/671755
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Sean Liao <sean@liao.dev>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Rob Pike <r@golang.org>
The "doc", "fix", and "covdata" tools invoked by the go command are not
needed for builds. Instead of invoking them directly using the installed
binary in the tool directory, use "go tool" to run them, building them
if needed. We can then stop distributing those tools in the
distribution.
covdata is used in tests and can form part of a cached test result, but
test results don't have the same requirements as build outputs to be
completely determined by the action id. We already don't include a
toolid for the covdata tool in the action id for a test run. The more
principled way to do things would be to load the covdata package,
create the actions to build it, and then depend on the output of
that action from the the test action and use that as the covdata tool.
For now, it's probably not worth the effort, but, in the future, if we
wanted to build a tool like cgo as needed, it would be best to build it
in the same action graph. That would introduce a whole bunch of complexity
because we'd need to build the tool in the host configuration, and all
the configuration parameters are global.
For #71867
Change-Id: Id9bbbb5c169296f66c072949f9da552424ecfa2f
Reviewed-on: https://go-review.googlesource.com/c/go/+/673119
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Matloob <matloob@google.com>
This change removes some tools that are not used for builds, or
otherwise invoked by the go command (other than through "go tool"
itself) from the packaged distributions produced by distpack. When these
tools are missing, "go tool" will build and run them as needed.
Also update a case where we print a buildid commandline to specify
invoking buildid using "go tool" rather than the binary at it's install
location, because it may not exist there in packaged distributions
anymore.
The tools in this CL are the lowest hanging fruit. There are a few more
tools that aren't used by builds, but we'd have to get the go command to
run them using "go tool" rather than finding them in the tool install
directory.
For #71867
Change-Id: I217683bd549962a1add87405bf3fb1225e2333c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/666755
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Matloob <matloob@google.com>
The purpose of this change is to enable go get to be used when working
on a module that is usually built from a workspace and has unreleased
dependencies in that workspacae that have no requirements satisfying
them. These modules can't build in single module mode, and the
expectation is that a workspace will provide the unreleased
requirements.
Before this change, if go get was run in a module, and any of the
module's imports, that were not already satisfied using requirements,
could not be resolved from that module in single module mode, go get
would report an error. This could happen if, for example, the dependency
was unreleased, even privately, and couldn't be fetched using version
control or a proxy. go get would also do a check using
cmd/go/internal/modget.(*resolver).checkPackageProblems that, among
other things, any package patterns provided to go get (the pkgPattern
argument to checkPackageProblems) could properly load. When checking in
single-module mode, this would cause an error because imports in the
non-required workspace dependencies could not be resolved.
This change makes a couple of changes to address each of those problems.
First, while "go get" still uses the single module's module graph to
load packages and determine which imports are not satisfied by a module
in the build list (the set of modules the build is done with), it will
"cheat" and look up the set of modules that would be loaded in workspace
mode. It will not try to fetch modules to satisfy imports of packages in
those modules. (Alternatively, it could have tried to fetch modules to
satisfy the requirements, and allowed an error if it could not be found,
but we took the route of not doing the fetch to preserve the invariant
that the behavior wouldn't change if the network was down). The second,
and by far more complex, change is that the load that's done in
checkPackageProblems will be done in workspace mode rather than module
mode. While it is important that the requirements added by "go get" are
not determined using the workspace (with the necessary exception of the
skipped fetches) it is okay to use the workspace to load the modules,
as, if a go.work file is present, the go command would by default run
builds in workspace mode rather than single module mode. This more
relaxed check will allow get to succeed if a go list would succeed in
the workspace, even if it wouldn't from the single module.--
To avoid trying to satisfy imports that are in the other workspace
modules, we add a workspace field to the resolver that can be used to
check if an import is in the workspace. It reads the go.work file and
determines each of the modules' modroots. The hasPackage function will
call into modload logic using the new PkgIsInLocalModule function that
in turn calls into dirInModule to determine if the directory that would
contain the package sources exists in the module. We do that check in
cmd/go/internal/modget.(*resolver).loadPackages, which is used to
resolve modules to satisfy imports in the package graph supplied on the
command line. (Note that we do not skip resolving modules in the
functions that query for a package at a specific module version (such as
in "go get golang.org/x/tools/go/packages@latest), which are done in
(*resolver).queryPath. In that case, the user is explicitly requesting
to add a requirement on that package's module.)
The next step, checking for issues in the workspace mode, is more
complex because of two reasons. First, can't do all of
checkPackageProblems's work in a workspace, and second, that the module
loading state in the go command is global, so we have to manage the
global state in switching to workspace mode and back.
On the work that checkPackageProblems does: it broadly does three things:
first, a load of the packages specified to "go get", to make sure that
imports are satisfied and not ambiguous. Second, using that loaded
information, reporting any retracted or deprecated modules that are
relevant to the user and that they may want to take action on. And
third, checking that all the modules in the build list (the set of
module versions used in a load or build) have sums, and adding those
sums to the in-memory representation of the go.sum file that will be
written out at the end. When there's a workspace, the first two checks
need to be done in workspace mode so that we properly point out issues
in the build, but the sums need to be updated in module mode so that the
module's go.sum file is updated to reflect changes in go.mod.
To do the first two steps in workspace mode, we add a new
modload.EnterWorkspace function that will reset the global modload state
and load from the workspace, using the updated requirements that have
been calculated for the module. It returns a cleanup function that will
exit the workspace and reset to the previous global state. (We need the
previous global state because it holds the updated in memory
representations of go.mod and go.sum that will be written out by go get
if there are no errors.) We switch to workspace mode if there's a
relevant go.work file that would trigger a workspace load _and_ the
module go get is being run from belongs to that workspace (it wouldn't
make sense to use a workspace that the module itself didn't belong to).
We then switch back to module mode after the first two steps are
complete using the cleanup function. We have to be careful to finish
all the tasks checking for deprecations and retractions before to start
looking at the sums because they retraction and deprecation checking
tasks will depend on the global workspace state.
It's a bit unfortunate that much of the modload and modfetch state is
global. It's pretty gross doing the switch. It would be a lot of
work, but if we need to do a switch in a third instance other than for
go work sync and go get it might be worth doing the work to refactor
modload so that the state isn't global.
The EnterWorkspace function that does the switch to workspace mode (in
cmd/go/internal/modload/init.go) first saves the in memory
representation of the go.mod file (calculated using UpdateGoModFromReqs)
so that it can be applied in the workspace. It then uses the new
setState function to save the old state and reset to a clean state,
loads in workspace mode (using InitWorkfile to so that the go.work file
is used by LoadModFile), and then replaces the go.mod file
representation for the previous main module with the contents saved
earlier and reloads the requirements (holding the roots of the module
graph) to represent the updates. In workspace mode, the roots field of the
requirements is the same, but the reload is used to update the set of
direct requirements. rawGoModSummary is also update to use the in-
memory representation of the previous main module's go.mod file rather
than always reading it from disk so that it can take those updated
contents into account. (It previously didn't need to do this because
rawGoModSummary is primarily used to get module information for
dependency modules. The exception is in workspace mode but the same
logic worked because we didn't update workspace module's go.mod files in
a go command running in workspace mode). Finally, EnterWorkspace returns
a function that calls setState with the old state, to revert to the
previous state.
When we save the state of the modload package, we also need to save the
state of the modfetch package because it holds the state of the go.sum
file and the operation of looking up a value in the lookupCache or
downloadCache affects whether it appears in the go.sum file. lookupCache
and downloadCache are turned into pointers so that they can be saved in
the modfetchState.
Fixes#73654
Change-Id: I65cf835ec2293d4e3f66b91d3e77d3bb8d2f26d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/669635
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>
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
This test expects to be able to drain a Pool using only Get. This isn't
actually possible in the general case, since a pooled value could get
stuck in some P's private slot. However, if GOMAXPROCS=1, there's only 1
P we could be running on, so getting stuck becomes impossible.
This test isn't checking any concurrent properties of Pool, so this is
fine. Just set GOMAXPROCS=1 for this one particular test.
Fixes#73728.
Change-Id: I9053e28118060650f2cd7d0d58f5a86d630b36f7
Reviewed-on: https://go-review.googlesource.com/c/go/+/673375
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
This CL adds the ignore directive which enables users to tell the Go
Command to skip traversing into a given directory.
This behaves similar to how '_' or 'testdata' are currently treated.
This mainly has benefits for go list and go mod tidy.
This does not affect what is packed into a module.
Fixes: #42965
Change-Id: I232e27c1a065bb6eb2d210dbddad0208426a1fdd
Reviewed-on: https://go-review.googlesource.com/c/go/+/643355
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>
Currently, there's a window of time where each cleanup goroutine has
committed to going to sleep (immediately after full.pop() == nil) but
hasn't yet marked itself as asleep (state.sleep()). If new work arrives
in this window, it might get missed. This is what we see in #73642, and
I can reproduce it with stress2.
Side-note: even if the work gets missed by the existing sleeping
goroutines, needg is incremented. So in theory a new goroutine will
handle the work. Right now that doesn't happen in tests like the one
running in #73642, where there might never be another call to AddCleanup
to create the additional goroutine. Also, if we've hit the maximum on
cleanup goroutines and all of them are in this window simultaneously, we
can still end up missing work, it's just more rare. So this is still a
problem even if we choose to just be more aggressive about creating new
cleanup goroutines.
This change fixes the problem and also aims to make the cleanup
wake/sleep code clearer. The way this change fixes this problem is to
have cleanup goroutines re-check the work list before going to sleep,
but after having already marked themselves as sleeping. This way, if new
work comes in before the cleanup goroutine marks itself as going to
sleep, we can rely on the re-check to pick up that work. If new work
comes after the goroutine marks itself as going to sleep and after the
re-check, we can rely on the scheduler noticing that the goroutine is
asleep and waking it up. If work comes in between a goroutine marking
itself as sleeping and the re-check, then the re-check will catch that
piece of work. However, the scheduler might now get a false signal that
the goroutine is asleep and try to wake it up. This is OK. The sleeping
signal is now mutated and double-checked under the queue lock, so the
scheduler will grab the lock, may notice there are no sleeping
goroutines, and go on its way. This may cause spurious lock acquisitions
but it should be very rare. The window between a cleanup goroutine
marking itself as going to sleep and re-checking the work list is a
handful of instructions at most.
This seems subtle but overall it's a simplification of the code. We
rely more on the lock, which is easier to reason about, and we track two
separate atomic variables instead of the merged cleanupSleepState: the
length of the full list, and the number of cleanup goroutines that are
asleep. The former is now the primary way to acquire work. Cleanup
goroutines must decrement the length successfully to obtain an item off
the full list. The number of cleanup goroutines asleep, meanwhile, is
now only updated with the queue lock held. It can be checked without the
lock held, and the invariant to make that safe is simple: it must always
be an overestimate of the number of sleeping cleanup goroutines.
The changes here do change some other behaviors.
First, since we're tracking the length of the full list instead of the
abstract concept of a wake-up, the waker can't consume wake-ups anymore.
This means that cleanup goroutines may be created more aggressively. If
two threads in the scheduler see that there are goroutines that are
asleep, only one will win the race, but the other will observe zero
asleep goroutines but potentially many work units available. This will
cause it to signal many goroutines to be created. This is OK since we
have a cap on the number of cleanup goroutines, and the race should be
relatively rare.
Second, because cleanup goroutines can now fail to go to sleep if any
units of work come in, they might spend more time contended on the lock.
For example, if we have N cleanup goroutines and work comes in at *just*
the wrong rate, in the worst case we'll have each of G goroutines loop
N times for N blocks, resulting in O(G*N) thread time to handle each
block in the worst case. To paint a picture, imagine each goroutine
trying to go to sleep, fail because a new block of work came in, and
only one goroutine will get that block. Then once that goroutine is
done, we all try again, fail because a new block of work came in, and so
on and so forth. This case is unlikely, though, and probably not worth
worrying about until it actually becomes a problem. (A similar problem
exists with parking (and exists before this change, too) but at least in
that case each goroutine parks, so it doesn't block the thread.)
Fixes#73642.
Change-Id: I6bbe1b789e7eb7e8168e56da425a6450fbad9625
Reviewed-on: https://go-review.googlesource.com/c/go/+/671676
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>
FILE_FLAG_BACKUP_SEMANTICS is necessary to open directories on Windows,
and to enable backup applications do extended operations on files if
they hold the SE_BACKUP_NAME and SE_RESTORE_NAME privileges.
os.OpenFile currently sets FILE_FLAG_BACKUP_SEMANTICS for all supported
cases except when the file is opened with O_WRONLY | O_RDWR (that is,
access mode 3). This access mode doesn't correspond to any of the
standard POSIX access modes, but some OSes special case it to mean
different things. For example, on Linux, O_WRONLY | O_RDWR means check
for read and write permission on the file and return a file descriptor
that can't be used for reading or writing.
On Windows, os.OpenFile has historically mapped O_WRONLY | O_RDWR to a
0 access mode, which Windows internally interprets as
FILE_READ_ATTRIBUTES. Additionally, it doesn't prepare the file for I/O,
given that the read attributes permission doesn't allow reading or
writing (not that this is similar to what happens on Linux). This
makes opening the file around 50% faster, and one can still use the
handle to stat it, so some projects have been using this behavior
to open files without I/O access.
This CL updates os.OpenFile so that directories can also be opened
without I/O access. This effectively closes#23312, as all the remaining
cases where we don't set FILE_FLAG_BACKUP_SEMANTICS imply opening
with O_WRONLY or O_RDWR, and that's not allowed by Unix's open.
Closes#23312.
Change-Id: I77c4f55e1ca377789aef75bd8a9bce2b7499f91d
Reviewed-on: https://go-review.googlesource.com/c/go/+/673035
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The BoGo IgnoreClientVersionOrder test checks that a client that sends
a supported_versions extension with the list [TLS 1.2, TLS 1.3] ends up
negotiating TLS 1.3.
However, the crypto/tls module treats this list as being in client
preference order, and so negotiates TLS 1.2, failing the test.
Our behaviour appears to be the correct handling based on RFC 8446
§4.2.1 where it says:
The extension contains a list of supported versions in preference
order, with the most preferred version first.
This commit updates the reason we skip this test to cite the RFC instead
of saying it's something to be fixed.
Updates #72006
Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/671415
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>
Auto-Submit: Daniel McCarney <daniel@binaryparadox.net>
x += *p
We want to do this with a single load+add operation on amd64.
The tricky part is that we don't want to combine if there are
other uses of x after this instruction.
Implement a simple detector that seems to capture a common situation -
x += *p is in a loop, and the other use of x is after loop exit.
In that case, it does not hurt to do the load+add combo.
Change-Id: I466174cce212e78bde83f908cc1f2752b560c49c
Reviewed-on: https://go-review.googlesource.com/c/go/+/672957
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>
TestMutexBlockFullAggregation aggregates stacks by function, file, and
line number. But there can be multiple function calls on the same line,
giving us different sequences of PCs. This causes the test to spuriously
fail in some cases. Include PCs in the stacks for this test.
Also pick up a small "range over int" modernize suggestion while we're
looking at the test.
Fixes#73641
Change-Id: I50489e19fcf920e27b9eebd9d4b35feb89981cbc
Reviewed-on: https://go-review.googlesource.com/c/go/+/673115
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>
os.Stat and os.Lstat first try stating the file without opening it. If
that fails, then they open the file and try again, operations that tends
to be slow. There is no point in trying the slow path if the file
doesn't exist, we should just return an error immediately.
This CL makes stating a non-existent file on Windows 50% faster:
goos: windows
goarch: amd64
pkg: os
cpu: Intel(R) Core(TM) i7-10850H CPU @ 2.70GHz
│ old.txt │ new.txt │
│ sec/op │ sec/op vs base │
StatNotExist-12 43.65µ ± 15% 20.02µ ± 10% -54.14% (p=0.000 n=10+7)
│ old.txt │ new.txt │
│ B/op │ B/op vs base │
StatNotExist-12 224.0 ± 0% 224.0 ± 0% ~ (p=1.000 n=10+7) ¹
¹ all samples are equal
│ old.txt │ new.txt │
│ allocs/op │ allocs/op vs base │
StatNotExist-12 2.000 ± 0% 2.000 ± 0% ~ (p=1.000 n=10+7) ¹
Updates #72992.
Change-Id: Iaeb9596d0d18e5a5a1bd1970e296a3480501af78
Reviewed-on: https://go-review.googlesource.com/c/go/+/671458
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Jake Bailey <jacob.b.bailey@gmail.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
The WSASocket documentation states that the returned socket must be
closed by calling closesocket instead of CloseHandle. The different
File methods on the net package return an os.File that is not aware
that it should use closesocket. Ideally, os.NewFile should detect that
the passed handle is a socket and use the appropriate close function,
but there is no reliable way to detect that a handle is a socket on
Windows (see CL 671455).
To work around this, we add a hidden function to the os package that
can be used to return an os.File that uses closesocket. This approach
is the same as used on Unix, which also uses a hidden function for other
purposes.
While here, fix a potential issue with FileConn, which was using File.Fd
rather than File.SyscallConn to get the handle. This could result in the
File being closed and garbage collected before the syscall was made.
Fixes#73683.
Change-Id: I179405f34c63cbbd555d8119e0f77157c670eb3e
Reviewed-on: https://go-review.googlesource.com/c/go/+/672195
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
On every arch except amd64, it is faster to do x&(x-1) than x^(1<<n).
Most archs need 3 instructions for the latter: MOV $1, R; SLL n, R;
ANDN R, x. Maybe 4 if there's no ANDN.
Most archs need only 2 instructions to do x&(x-1). It takes 3 on
x86/amd64 because NEG only works in place.
Only amd64 can do x^(1<<n) in a single instruction.
(We could on 386 also, but that's currently not implemented.)
Change-Id: I3b74b7a466ab972b20a25dbb21b572baf95c3467
Reviewed-on: https://go-review.googlesource.com/c/go/+/672956
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>
To understand this change, we begin with a short description of the UIR
file format.
Every file is a header followed by a series of sections. Each section
has a kind, which determines the type of elements it contains. An
element is just a collection of one or more primitives, as defined by
package pkgbits.
Strings have their own section. Elements in the string section contain
only string primitives. To use a string, elements in other sections
encode a reference to the string section.
To illustrate, consider a simple file which exports nothing at all.
package p
In the meta section, there is an element representing a package stub.
In that package stub, a string ("p") represents both the path and name
of the package. Again, these are encoded as references.
To manage references, every element begins with a reference table.
Instead of writing the bytes for "p" directly, the package stub encodes
an index in this reference table. At that index, a pair of numbers is
stored, indicating:
1. which section
2. which element index within the section
Effectively, elements always use *2* layers of indirection; first to the
reference table, then to the bytes themselves.
With some minor hand-waving, an encoding for the above package is given
below, with (S)ections, (E)lements and (P)rimitives denoted.
+ Header
| + Section Ends // each section has 1 element
| | + 1 // String is elements [0, 1)
| | + 2 // Meta is elements [1, 2)
| + Element Ends
| | + 1 // "p" is bytes [0, 1)
| | + 6 // stub is bytes [1, 6)
+ Payload
| + (S) String
| | + (E) String
| | | + (P) String { byte } 0x70 // "p"
| + (S) Meta
| | + (E) Package Stub
| | | + Reference Table
| | | | + (P) Entry Count uvarint 1 // there is a single entry
| | | | + (P) 0th Section uvarint 0 // to String, 0th section
| | | | + (P) 0th Index uvarint 0 // to 0th element in String
| | | + Internals
| | | | + (P) Path uvarint 0 // 0th entry in table
| | | | + (P) Name uvarint 0 // 0th entry in table
Note that string elements do not have reference tables like other
elements. They behave more like a primitive.
As this is a bit complicated and getting into details of the UIR file
format, we omit some details in the documentation here. The structure
will become clearer as we continue documenting.
Change-Id: I12a5ce9a34251c5358a20f2f2c4d0f9bd497f4d0
Reviewed-on: https://go-review.googlesource.com/c/go/+/671997
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Mark Freeman <mark@golang.org>
TryBot-Bypass: Mark Freeman <mark@golang.org>
Git's supported SHA 256 object hashes since 2.29[1] in 2021, and Gitlab
now has experimental support for sha256 repos.
Take rsc@'s suggestion of checking the of the length of the hashes from
git ls-remote to determine whether a git repo is using sha256 hashes and
decide whether to pass --object-format=sha256 to git init.
Unfortunately, just passing --object-format=sha256 wasn't quite enough,
though. We also need to decide whether the hash-length is 64 hex bytes
or 40 hex bytes when resolving refs to decide whether we've been passed
a full commit-hash. To that end, we use
git config extensions.objectformat to decide whether the (now guaranteed
local) repo is using sha256 hashes and hence 64-hex-byte strings.
[1]: lost experimental status in 2.42 from Aug 2023
(https://lore.kernel.org/git/xmqqr0nwp8mv.fsf@gitster.g/)
For: #68359
Change-Id: I47f480ab8334128c5d17570fe76722367d0d8ed8
Reviewed-on: https://go-review.googlesource.com/c/go/+/636475
Auto-Submit: Sam Thanawalla <samthanawalla@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: David Finkel <david.finkel@gmail.com>
Specified in RISC-V ELF psABI[1], mapping symbols are symbols starting
with "$d" or "$x" with STT_NOTYPE, STB_LOCAL and zero sizes, indicating
boundaries between code and data in the same section.
Let's simply ignore them as they're only markers instead of real symbols.
This fixes linking errors like
sym#63 ("$d"): ignoring symbol in section 4 (".riscv.attributes") (type 0)
when using CGO together with Clang and internal linker, which are caused
by unnecessary (but technically correct) mapping symbols created by LLVM
for various sections.
[1]: 87aecf6017/riscv-elf.adoc (L1448)Fixes#73516
Change-Id: I02ca90c100ba8a38733fe3b8b8403836b44a3dd1
GitHub-Last-Rev: d7842ceafb
GitHub-Pull-Request: golang/go#73592
Reviewed-on: https://go-review.googlesource.com/c/go/+/669675
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>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
This complements the grammar being developed in package noder. It
is unclear how to discuss references in their current state, as
they require knowledge of sections, elements, etc.
Perhaps the references here should refer to indices on the byte
array. This would allow a stronger separation of pkgbits and noder.
Change-Id: Ic0e5ac9c07f0a0b92d6ffd4d4e26dbe5dcf89e57
Reviewed-on: https://go-review.googlesource.com/c/go/+/671440
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Bypass: Mark Freeman <mark@golang.org>
Auto-Submit: Mark Freeman <mark@golang.org>
NewFile was recently updated (in CL 668195) to detect whether the
handle is a socket or not. This special case is not really necessary,
given that socket handles can be used as if they were normal file
handles on all functions supported by os.File (see https://learn.microsoft.com/en-us/windows/win32/winsock/socket-handles-2).
Not only is not necessary, but is can also be problematic, as there is
no way to reliably detect whether a handle is a socket or not. For
example, the test failure reported in #73630 is caused by a named pipe
wrongly detected as a socket.
This aligns with the Unix NewFile behavior of returning an os.File that
identifies itself as a file handle even if it is a socket. This makes
os.File.Close to always return os.ErrClosed in case of multiple calls
rather than sometimes returning "use of closed network connection".
Updates #10350.
Fixes#73630.
Change-Id: Ia8329783d5c8ef6dac34ef69ed1ce9d2a9862e11
Reviewed-on: https://go-review.googlesource.com/c/go/+/671455
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Windows prefers 64-bit binaries to be loaded at an address above 4GB.
Having a preferred base address below this boundary triggers a
compatibility mode in Address Space Layout Randomization (ASLR) on
recent versions of Windows that reduces the number of locations to which
ASLR may relocate the binary.
The Go internal linker was using a smaller base address due to an issue
with how dynamic cgo symbols were relocated, which has been fixed in
this CL.
Fixes#73561.
Cq-Include-Trybots: luci.golang.try:gotip-windows-amd64-longtest
Change-Id: Ia8cb35d57d921d9be706a8975fa085af7996f124
Reviewed-on: https://go-review.googlesource.com/c/go/+/671515
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The first loop leaves the lengths of the two arguments unchanged.
Take advantage of this invariant in the loop's condition. Here are some
benchmark results (no change to allocations):
goos: darwin
goarch: amd64
pkg: strings
cpu: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz
│ old │ new │
│ sec/op │ sec/op vs base │
EqualFold/Tests-8 240.0n ± 4% 245.1n ± 5% ~ (p=0.516 n=20)
EqualFold/ASCII-8 11.50n ± 1% 11.04n ± 0% -3.96% (p=0.000 n=20)
EqualFold/UnicodePrefix-8 102.1n ± 0% 102.2n ± 0% ~ (p=0.455 n=20)
EqualFold/UnicodeSuffix-8 90.14n ± 0% 89.80n ± 1% ~ (p=0.113 n=20)
geomean 71.00n 70.60n -0.56%
Change-Id: I1f6d1df8a0398f9493692f59d7369c3f0fbba436
GitHub-Last-Rev: 9508ee26ad
GitHub-Pull-Request: golang/go#73672
Reviewed-on: https://go-review.googlesource.com/c/go/+/671756
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
If the client hello legacy version is >= TLS 1.3, and no
supported_versions extension is sent, negotiate TLS 1.2 or lower when
supported.
On the topic of supported version negotiation RFC 8446 4.2.1 indicates
TLS 1.3 implementations MUST send a supported_versions extension with
a list of their supported protocol versions. The crypto/tls package
enforces this when the client hello legacy version indicates TLS 1.3
(0x0304), aborting the handshake with an alertMissingExtension alert if
no supported_versions were received.
However, section 4.2.1 indicates different behaviour should be used when
the extension is not present and TLS 1.2 or prior are supported:
If this extension is not present, servers which are compliant with
this specification and which also support TLS 1.2 MUST negotiate
TLS 1.2 or prior as specified in [RFC5246], even if
ClientHello.legacy_version is 0x0304 or later.
This commit updates the client hello processing logic to allow this
behaviour. If no supported_versions extension was received we ignore the
legacy version being >= TLS 1.3 and instead negotiate a lower supported
version if the server configuration allows.
This fix in turn allows enabling the BoGo ClientHelloVersionTooHigh,
MinorVersionTolerance, and MajorVersionTolerance tests.
Updates #72006
Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/671235
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Previously for protocol versions older than TLS 1.3 our server handshake
implementation sent an alertBadCertificate alert in the case where the
server TLS config indicates a client cert is required and none was
received.
This commit updates the relevant logic to instead send
alertHandshakeFailure in these circumstances.
For TLS 1.2, RFC 5246 §7.4.6 unambiguously describes this as the correct
alert:
If the client does not send any certificates, the
server MAY at its discretion either continue the handshake without
client authentication, or respond with a fatal handshake_failure
alert.
The TLS 1.1 and 1.0 specs also describe using this alert (RFC 4346 §7.4.6
and RFC 2246 §7.4.6) both say:
If client authentication is required by the server for the handshake
to continue, it may respond with a fatal handshake failure alert.
Making this correction also allows enabling the
RequireAnyClientCertificate-TLS1* bogo tests.
Updates #72006
Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/671195
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Previously a handful of large record tests were in the bogo config
ignore list. The ignored tests were failing because they used
insecure ciphersuites that aren't enabled by default.
This commit adds the non-default insecure ciphersuites to the bogo
TLS configuration and re-enables the tests. Doing this uncovered
a handful of unrelated tests that needed to be fixed, each handled
before this commit.
Updates #72006
Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/669158
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
These two bogo tests mutate the version number used for the premaster
secret calculation for a client RSA key exchange, with the expectation
the server rejects the handshake.
Per the comment in the end of rsaKeyAgreement.processClientKeyExchange
we explicitly choose *not* to verify the version number.
This commit adds the two version number tests to the ignore list. They
coincidentally happen to produced the expected failure because they use
a non-default ciphersuite. When we add this ciphersuite to the client
config for the bogo test they will start to fail unless ignored.
Updates #72006
Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/669175
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Unlike in earlier TLS versions, in TLS 1.3 when processing a server
hello the legacy_compression_method MUST have the value 0. It is no
longer a parameter that offers a choice of compression method.
With this in mind, it seems more appropriate to return a decode error
when we encounter a non-zero compression method in a server hello
message. We haven't found a parameter value we reject, we've found
a message that doesn't decode according to its specification.
Making this change also aligns with BoringSSL and allows enabling the
TLS13-HRR-InvalidCompressionMethod bogo test.
Updates #72006
Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/669156
Reviewed-by: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Previously if the clientHandshakeState for the TLS 1.2 client code
encountered a server helo message that contained a compression method
other than compressionNone, we would emit an unexpected message alert.
Instead, it seems more appropriate to return an illegal parameter alert.
The server hello message _was_ expected, it just contained a bad
parameter option.
Making this change also allows enabling the InvalidCompressionMethod
bogo test.
Updates #72006
Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/669155
Reviewed-by: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
If a tool in cmd is not installed in $GOROOT/pkg/tool/${GOOS}_${GOARCH},
go tool will build (if it's not cached) and run it in a similar way
(with some changes) to how tools declared with tool directives are built
and run.
The main change in how builtin tools are run as compared to mod tools is
that they are built "in host mode" using the running go command's GOOS
and GOARCH. The "-exec" flag is also ignored and we don't add GOROOT/bin
to the PATH.
A ForceHost function has been added to the cfg package to force the
configuration to runtime.GOOS/runtime.GOARCH. It has to recompute the
BuildContext because it's normally determined at init time but we're
changing it after we realize we're running a builtin tool. (Detecting
that we're running a builtin tool at init time would mean replicating
the cmd line parsing logic so recomputing BuildContext sounds like the
smaller change.)
For #71867
Change-Id: I3b2edf2cb985c1dcf5f845fbf39b7dc11dea4df7
Reviewed-on: https://go-review.googlesource.com/c/go/+/666476
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Matloob <matloob@google.com>
Meta is the most fundamental section. To flesh this out, we discuss references. Primitives are briefly mentioned by pointing to pkgbits,
where they will be defined using a similar grammar.
Change-Id: I7abd899f38fad4cc5caf87ebfc7aa1b1985b17d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/671176
Auto-Submit: Mark Freeman <mark@golang.org>
TryBot-Bypass: Mark Freeman <mark@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
I noticed a failure of this test on a linux/amd64 builder and reproduced
it locally. I can only really reproduce it in a stress test when I
overload my system (`stress2 ./tls.test -test.run=TestCertCache`) but
this points to the root of the problem: it's possible for a timer to get
delayed and the timeout fires before we ever get the chance to check.
After copious debugging printlns, this is essentially what I'd observed.
There would only be one failed check of the reference count from before
it was updated.
Change the test to be a busy-loop again, but call runtime.Gosched. This
is also what we do for the os.Root tests, and in hindsight should've
been my go-to. This has a much higher likelihood of executing promptly.
We may want to go back and understand why the 1 ms timer would fire so
hilariously late the second time. This might be a real bug. For now,
this change makes the test more stable. It no longer fails when it's
hammered under `stress2`.
Fixes#73637.
Change-Id: I316bd9e30946f4c055e61d179c4efc5fe029c608
Reviewed-on: https://go-review.googlesource.com/c/go/+/671175
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>
The UIR export data format can be reasonably expressed using EBNF.
The noder owns the definition of the export data format, so this
seems like a reasonable place to put this.
Change-Id: I0205ab29a3c5e57d670d7fd3164a8bd604ab8e59
Reviewed-on: https://go-review.googlesource.com/c/go/+/670616
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Bypass: Mark Freeman <mark@golang.org>
Auto-Submit: Mark Freeman <mark@golang.org>
This change splits the finalizer and cleanup queues and implements a new
lock-free blocking queue for cleanups. The basic design is as follows:
The cleanup queue is organized in fixed-sized blocks. Individual cleanup
functions are queued, but only whole blocks are dequeued.
Enqueuing cleanups places them in P-local cleanup blocks. These are
flushed to the full list as they get full. Cleanups can only be enqueued
by an active sweeper.
Dequeuing cleanups always dequeues entire blocks from the full list.
Cleanup blocks can be dequeued and executed at any time.
The very last active sweeper in the sweep phase is responsible for
flushing all local cleanup blocks to the full list. It can do this
without any synchronization because the next GC can't start yet, so we
can be very certain that nobody else will be accessing the local blocks.
Cleanup blocks are stored off-heap because the need to be allocated by
the sweeper, which is called from heap allocation paths. As a result,
the GC treats cleanup blocks as roots, just like finalizer blocks.
Flushes to the full list signal to the scheduler that cleanup goroutines
should be awoken. Every time the scheduler goes to wake up a cleanup
goroutine and there were more signals than goroutines to wake, it then
forwards this signal to runtime.AddCleanup, so that it creates another
goroutine the next time it is called, up to gomaxprocs goroutines.
The signals here are a little convoluted, but exist because the sweeper
and the scheduler cannot safely create new goroutines.
For #71772.
For #71825.
Change-Id: Ie839fde2b67e1b79ac1426be0ea29a8d923a62cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/650697
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Currently TestCertCache will busy loop waiting for a cleanup (in the
runtime.AddCleanup sense) to execute. If we ever get into this busy
loop, then on single-threaded platforms like js/wasm, we'll end up
_always_ timing out.
This doesn't happen right now because we're getting lucky. The finalizer
goroutine is scheduled into the runnext slot with 'ready' and is thus
scheduled immediately after the GC call. In a follow-up CL, scheduling
cleanup goroutines becomes less aggressive, and thus this test fails.
Although perhaps that CL should schedule cleanup goroutines more
aggressively, the test is still technically buggy, because it expects
busy loops like this to call into the scheduler, but that won't happen
on certain platforms.
Change-Id: I8efe5975be97f4314aec1c8c6e9e22f396be9c94
Reviewed-on: https://go-review.googlesource.com/c/go/+/670755
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The stated goal for pkgbits is to implement encoding / decoding of
primitives. However, pkgbits has knowledge of high-level details like
elements, sections, and file layout.
This change starts to clarify pkgbits by paring back documentation to
only those concepts which pkgbits owns. Further CLs are needed to shift
away logic that pkgbits should not own.
Change-Id: Id93003d080f58ffbd6327e2db1a4878500511619
Reviewed-on: https://go-review.googlesource.com/c/go/+/670176
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Mark Freeman <mark@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Mark Freeman <mark@golang.org>
It's the job of the last sweeper to emit the GC pacer trace. The last
sweeper can identify themselves by reducing the count of sweepers, and
also seeing that there's no more sweep work.
Currently this identification is broken, however, because the last
sweeper doesn't check the state they just transitioned sweeping into,
but rather the state they transitioned from (one sweeper, no sweep work
left). By design, it's impossible to transition *out* of this state,
except for another GC to start, but that doesn't take this codepath.
This means lines like
pacer: sweep done at heap size ...
were missing from the gcpacertrace output for a long time.
This change fixes this problem by having the last sweeper check the
state they just transitioned sweeping to, instead of the state they
transitioned from.
Change-Id: I44bcd32fe2c8ae6ac6c21ba6feb2e7b9e17f60cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/670735
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
The RISC-V Instruction Set Manual Volume states that "for vadc and
vsbc, the instruction encoding is reserved if the destination vector
register is v0". The assembler currently allows instructions like
VADCVVM V1, V2, V0, V0
to be assembled. It's not clear what the behaviour of such
instructions will be on target hardware so it's best to disallow
them.
For reference, binutils (2.44-3.fc42) allows the instruction
vadc.vvm v0, v4, v8, v0
to be assembled and the instruction actually executes on a Banana PI
F3 without crashing. However, clang (20.1.2) refuses to assemble the
instruction, producing the following error.
error: the destination vector register group cannot be V0
vadc.vvm v0, v4, v8, v0
^
Change-Id: Ia913cbd864ae8dbcf9227f69b963c93a99481cff
Reviewed-on: https://go-review.googlesource.com/c/go/+/669315
Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Joel Sing <joel@sing.id.au>
The encodings for the riscv64 special operands SPOP_MF2 and SPOP_MF8
are incorrect, i.e., their values are swapped. This leads to
incorrect encodings for the VSETVLI and VSETIVLI instructions. The
assembler currently encodes
VSETVLI X10, E32, MF8, TA, MA, X12
as
VSETVLI X10, E32, MF2, TA, MA, X12
We update the encodings for SPOP_MF2 and SPOP_MF8 so that they match
the LMUL table in section "31.3.4. Vector type register, vtype" of
the "RISC-V Instruction Set Manual Volume 1".
Change-Id: Ic73355533d7c2a901ee060b35c2f7af6d58453e4
Reviewed-on: https://go-review.googlesource.com/c/go/+/670016
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>
Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com>
Reviewed-by: Joel Sing <joel@sing.id.au>
Have the test use the same clock (cputicks) as the profiler, and use the
test's own measurements as hard bounds on the magnitude to expect in the
profile.
Compare the depiction of two users of the same lock: one where the
critical section is fast, one where it is slow. Confirm that the profile
shows the slow critical section as a large source of delay (with #66999
fixed), rather than showing the fast critical section as a large
recipient of delay.
Previously reviewed as https://go.dev/cl/586237.
For #66999
Change-Id: Ic2d78cc29153d5322577d84abdc448e95ed8f594
Reviewed-on: https://go-review.googlesource.com/c/go/+/667616
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Rhys Hiltner <rhys.hiltner@gmail.com>
Correct how the mutex contention profile reports on runtime-internal
mutex values, to match sync.Mutex's semantics.
Decide at the start of unlock2 whether we'd like to collect a contention
sample. If so: Opt in to a slightly slower unlock path which avoids
accidentally accepting blame for delay caused by other Ms. Release the
lock before doing an O(N) traversal of the stack of waiting Ms, to
calculate the total delay to those Ms that our critical section caused.
Report that, with the current callstack, in the mutex profile.
Fixes#66999
Change-Id: I561ed8dc120669bd045d514cb0d1c6c99c2add04
Reviewed-on: https://go-review.googlesource.com/c/go/+/667615
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Rhys Hiltner <rhys.hiltner@gmail.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
This change moves the unique package away from using a concurrent map
and instead toward a bespoke concurrent canonicalization map. The map
holds all its keys weakly, though keys may be looked up by value. The
result is the strong pointer for the canonical value. Entries in the map
are automatically cleaned up once the canonical reference no longer
exists.
Why do this? There's a problem with the current implementation when it
comes to chains of unique.Handle: because the unique map will have a
unique.Handle stored in its keys, each nested handle must be cleaned up
1 GC at a time. It takes N GC cycles, at minimum, to clean up a nested
chain of N handles. This implementation, where the *only* value in the
set is weakly-held, does not have this problem. The entire chain is
dropped at once.
The canon map implementation is a stripped-down version of HashTrieMap.
The weak set implementation also has lower memory overheads by virtue of
the fact that keys are all stored weakly. Whereas the previous map had
both a T and a weak.Pointer[T], this *only* has a weak.Pointer[T].
The canonicalization map is a better abstraction overall and
dramatically simplifies the unique.Make code.
While we're here, delete the background goroutine and switch to
runtime.AddCleanup. This is a step toward fixing #71772. We still need
some kind of back-pressure mechanism, which will be implemented in a
follow-up CL.
For #71772.
Fixes#71846.
Change-Id: I5b2ee04ebfc7f6dd24c2c4a959dd0f6a8af24ca4
Reviewed-on: https://go-review.googlesource.com/c/go/+/650256
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
The doInRoot function operates on a path split into components.
The final path component retained any trailing path separator
characters, to permit operations in a Root to retain the
trailing-separator behavior of non-Root operations. However,
doInRoot failed to take trailing separators into account
when checking for .. path components.
This could permit opening the parent directory of the Root
with a path ending in "../".
Change the split path to never include path separators in
components, and handle trailing separators independently
of the split path.
Thanks to Dan Sebastian Thrane of SDU eScience Center for
reporting this issue.
Fixes#73555
Fixes CVE-2025-22873
Change-Id: I9a33a145c22f5eb1dd4e4cafae5fcc61a8d4f0d4
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/2160
Reviewed-by: Neal Patel <nealpatel@google.com>
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/670036
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
The runtime poller and os.NewFile recently gained support for
disassociating the handle from the runtime poller IOCP (see CL 664455).
This was the main blocker for allowing the conversion between *os.File
and net.Conn.
Implementing the conversion is now trivial. The only remaining work,
implemented in this CL, is improving os.NewFile to also support
socket handles and updating some build tags so that Windows can share
almost the same net's File implementation as Unix.
There is one important limitation, though: the duplicated socket handle
returned by the various File methods in the net package is not
usable on other process. If someone needs to pass a socket handle to
another process, they should manually call the WSADuplicateSocket
Windows API passing the process ID of the target process.
Fixes#9503.
Fixes#10350.
Updates #19098.
Cq-Include-Trybots: luci.golang.try:gotip-windows-amd64-race,gotip-windows-amd64-longtest,gotip-windows-arm64
Change-Id: Ic43cadaac2662b925d57a9d362ddc7ae21d1b56e
Reviewed-on: https://go-review.googlesource.com/c/go/+/668195
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
On arm64, systemstack restores the frame pointer from g0.sched to R29
prior to calling the callback. That doesn't really make any sense. The
frame pointer value in g0.sched is some arbitrary BP from a prior
context save, but that is not the caller of systemstack.
amd64 does not do this. In fact, it leaves BP completely unmodified so
frame pointer unwinders like gdb can walk through the systemstack frame
and continue traceback on the caller's stack. Unlike mcall, systemstack
always returns to the original goroutine, so that is safe.
We should do the same on arm64.
For #63630.
Cq-Include-Trybots: luci.golang.try:gotip-linux-arm64-longtest
Change-Id: I6a6a636c35d321dd5d7dc1c4d09e29b55b1ab621
Reviewed-on: https://go-review.googlesource.com/c/go/+/669236
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Nick Ripley <nick.ripley@datadoghq.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
On amd64, mcall leaves BP untouched, so the callback will push BP,
connecting the g0 stack to the calling g stack. This seems OK (frame
pointer unwinders like Linux perf can see what user code called into the
scheduler), but the "scheduler" part is problematic.
mcall is used when calling into the scheduler to deschedule the current
goroutine (e.g., in goyield). Once the goroutine is descheduled, it may
be picked up by another M and continue execution. The other thread is
mutating the goroutine stack, but our M still has a frame pointer
pointing to the goroutine stack.
A frame pointer unwinder like Linux perf could get bogus values off of
the mutating stack. Note that though the execution tracer uses
framepointer unwinding, it never unwinds a g0, so it isn't affected.
Clear the frame pointer in mcall so that unwinding always stops at
mcall.
On arm64, mcall stores the frame pointer from g0.sched.bp. This doesn't
really make any sense. mcall wasn't called by whatever used g0 last, so
at best unwinding will get misleading results (e.g., it might look like
cgocallback calls mcall?).
Also clear the frame pointer on arm64.
Other architectures don't use frame pointers.
For #63630.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-linux-arm64-longtest
Change-Id: I6a6a636cb6404f3c95ecabdb969c9b8184615cee
Reviewed-on: https://go-review.googlesource.com/c/go/+/669615
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Nick Ripley <nick.ripley@datadoghq.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
The existing implementation lacks the Status function for retrieving VCS build
information for Subversion. As a consequence, binaries aren't stamped with the
Revision, CommitTime and Uncommitted information from SVN repositories.
This change provides the svnStatus function and retrieves the information by
running svn info and svn status commands.
Fixes#73444
Change-Id: Ie6d95ffbb3a3c580cc42128ad1f8d82a869c91f2
GitHub-Last-Rev: 3472222865
GitHub-Pull-Request: golang/go#73446
Reviewed-on: https://go-review.googlesource.com/c/go/+/666875
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Sean Liao <sean@liao.dev>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
Our current parallel mark algorithm suffers from frequent stalls on
memory since its access pattern is essentially random. Small objects
are the worst offenders, since each one forces pulling in at least one
full cache line to access even when the amount to be scanned is far
smaller than that. Each object also requires an independent access to
per-object metadata.
The purpose of this change is to improve garbage collector performance
by scanning small objects in batches to obtain better cache locality
than our current approach. The core idea behind this change is to defer
marking and scanning small objects, and then scan them in batches
localized to a span.
This change adds scanned bits to each small object (<=512 bytes) span in
addition to mark bits. The scanned bits indicate that the object has
been scanned. (One way to think of them is "grey" bits and "black" bits
in the tri-color mark-sweep abstraction.) Each of these spans is always
8 KiB and if they contain pointers, the pointer/scalar data is already
packed together at the end of the span, allowing us to further optimize
the mark algorithm for this specific case.
When the GC encounters a pointer, it first checks if it points into a
small object span. If so, it is first marked in the mark bits, and then
the object is queued on a work-stealing P-local queue. This object
represents the whole span, and we ensure that a span can only appear at
most once in any queue by maintaining an atomic ownership bit for each
span. Later, when the pointer is dequeued, we scan every object with a
set mark that doesn't have a corresponding scanned bit. If it turns out
that was the only object in the mark bits since the last time we scanned
the span, we scan just that object directly, essentially falling back to
the existing algorithm. noscan objects have no scan work, so they are
never queued.
Each span's mark and scanned bits are co-located together at the end of
the span. Since the span is always 8 KiB in size, it can be found with
simple pointer arithmetic. Next to the marks and scans we also store the
size class, eliminating the need to access the span's mspan altogether.
The work-stealing P-local queue is a new source of GC work. If this
queue gets full, half of it is dumped to a global linked list of spans
to scan. The regular scan queues are always prioritized over this queue
to allow time for darts to accumulate. Stealing work from other Ps is a
last resort.
This change also adds a new debug mode under GODEBUG=gctrace=2 that
dumps whole-span scanning statistics by size class on every GC cycle.
A future extension to this CL is to use SIMD-accelerated scanning
kernels for scanning spans with high mark bit density.
For #19112. (Deadlock averted in GOEXPERIMENT.)
For #73581.
Change-Id: I4bbb4e36f376950a53e61aaaae157ce842c341bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/658036
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>
For riscv64/rva22u64 and above, we can intrinsify math/bits.OnesCount
using the CPOP/CPOPW machine instructions. Since the native Go
implementation of OnesCount is relatively expensive, it is also
worth emitting a check for Zbb support when compiled for rva20u64.
On a Banana Pi F3, with GORISCV64=rva22u64:
│ oc.1 │ oc.2 │
│ sec/op │ sec/op vs base │
OnesCount-8 16.930n ± 0% 4.389n ± 0% -74.08% (p=0.000 n=10)
OnesCount8-8 5.642n ± 0% 5.016n ± 0% -11.10% (p=0.000 n=10)
OnesCount16-8 9.404n ± 0% 5.015n ± 0% -46.67% (p=0.000 n=10)
OnesCount32-8 13.165n ± 0% 4.388n ± 0% -66.67% (p=0.000 n=10)
OnesCount64-8 16.300n ± 0% 4.388n ± 0% -73.08% (p=0.000 n=10)
geomean 11.40n 4.629n -59.40%
On a Banana Pi F3, compiled with GORISCV64=rva20u64 and with Zbb
detection enabled:
│ oc.3 │ oc.4 │
│ sec/op │ sec/op vs base │
OnesCount-8 16.930n ± 0% 5.643n ± 0% -66.67% (p=0.000 n=10)
OnesCount8-8 5.642n ± 0% 5.642n ± 0% ~ (p=0.447 n=10)
OnesCount16-8 10.030n ± 0% 6.896n ± 0% -31.25% (p=0.000 n=10)
OnesCount32-8 13.170n ± 0% 5.642n ± 0% -57.16% (p=0.000 n=10)
OnesCount64-8 16.300n ± 0% 5.642n ± 0% -65.39% (p=0.000 n=10)
geomean 11.55n 5.873n -49.16%
On a Banana Pi F3, compiled with GORISCV64=rva20u64 but with Zbb
detection disabled:
│ oc.3 │ oc.5 │
│ sec/op │ sec/op vs base │
OnesCount-8 16.93n ± 0% 29.47n ± 0% +74.07% (p=0.000 n=10)
OnesCount8-8 5.642n ± 0% 5.643n ± 0% ~ (p=0.191 n=10)
OnesCount16-8 10.03n ± 0% 15.05n ± 0% +50.05% (p=0.000 n=10)
OnesCount32-8 13.17n ± 0% 18.18n ± 0% +38.04% (p=0.000 n=10)
OnesCount64-8 16.30n ± 0% 21.94n ± 0% +34.60% (p=0.000 n=10)
geomean 11.55n 15.84n +37.16%
For hardware without Zbb, this adds ~5ns overhead, while for hardware
with Zbb we achieve a performance gain up of up to 11ns. It is worth
noting that OnesCount8 is cheap enough that it is preferable to stick
with the generic version in this case.
Change-Id: Id657e40e0dd1b1ab8cc0fe0f8a68df4c9f2d7da5
Reviewed-on: https://go-review.googlesource.com/c/go/+/660856
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com>
Reviewed-by: Mark Ryan <markdryan@rivosinc.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
It's not currently possible to build cgo programs that are partially
compiled with gcc-15 on riscv64 using the internal linker. There are
two reasons for this.
1. When gcc-15 compiles _cgo_export.c, which contains no actual code,
for a riscv64 target, it emits a label in the .text section called
.Letext0. This label is referred to by another section, .debug_line,
and an entry is generated in the symbol table for it. The Go linker
panics when processing the .Letext0 symbol in _cgo_export.o, as it
occurs in an empty section.
2. GCC-15 is generating additional debug symbols with the .LVUS
prefix, e.g., .LVUS33, that need to be ignored.
We fix the issue by removing the check in
cmd/link/internal/loader/loader.go that panics if we encounter a
symbol in an empty section (the comments preceding this check suggest
it's safe to remove it) and by adding .LVUS to the list of symbol
prefixes to ignore.
Fixes#72840
Change-Id: I00658b6bdd01606dde1581b5bc2f42edfc37de82
Reviewed-on: https://go-review.googlesource.com/c/go/+/668276
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Joel Sing <joel@sing.id.au>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com>
These were the remaining instances in the main Go repo I found where a
Go version like "devel go1.25-9ce47e66e8 Wed Mar 26 03:48:50 2025 -0700"
is considered to be a development version rather than a release version,
but the version "go1.25-devel_9ce47e66e8 Wed Mar 26 03:48:50 2025 -0700"
is not.
Update this in preparation of the move of "devel" from front to middle.
For #73372.
For #73369.
Change-Id: If5442ecb0751c08b3a1b4d1148193e501700b956
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/668355
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
NewFile recently added support for overlapped I/O on Windows,
which allows us to set deadlines on them, but the test coverage for
this new feature is not exhaustive.
Modify the existing pipe deadline tests to also exercise named
overlapped pipes.
Updates #19098.
Cq-Include-Trybots: luci.golang.try:gotip-windows-amd64-race,gotip-windows-amd64-longtest,gotip-windows-arm64
Change-Id: I86d284d9fb054c24959045a922cf84feeda5b5f0
Reviewed-on: https://go-review.googlesource.com/c/go/+/668095
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Windows is unlike the other OSs and depends on a syscall for most
errors. This can be costly; cache the returned string for later reuse.
This helps test caching, since errors are written out as string to the
test ID, which are often PathErrors wrapping Errnos.
For now, only cache ERROR_FILE_NOT_FOUND and ERROR_PATH_NOT_FOUND.
goos: windows
goarch: amd64
pkg: syscall
cpu: Intel(R) Core(TM) i9-10900K CPU @ 3.70GHz
│ old.txt │ new.txt │
│ sec/op │ sec/op vs base │
ErrnoString-20 1788.00n ± 1% 11.08n ± 1% -99.38% (p=0.000 n=10)
│ old.txt │ new.txt │
│ B/op │ B/op vs base │
ErrnoString-20 48.00 ± 0% 0.00 ± 0% -100.00% (p=0.000 n=10)
│ old.txt │ new.txt │
│ allocs/op │ allocs/op vs base │
ErrnoString-20 1.000 ± 0% 0.000 ± 0% -100.00% (p=0.000 n=10)
For #72992
Change-Id: I9a0910fa6538772ffc64ef7670b44059a2c7d18c
Reviewed-on: https://go-review.googlesource.com/c/go/+/667495
Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Auto-Submit: Carlos Amedee <carlos@golang.org>
In CL 656755, the readRandom function was modified
to read an integer from /dev/random.
However, on Plan 9, /dev/random can only return
a few hundred bits a second.
The issue is that readRandom is called by randinit,
which is called at the creation of Go processes.
Consequently, it lead the Go programs to be very
slow on Plan 9.
This change reverts the change done in CL 656755
to make the readRandom function always returning 0
on Plan 9.
Change-Id: Ibe1bf7e4c8cbc82998e4f5e1331f5e29a047c4fc
Cq-Include-Trybots: luci.golang.try:gotip-plan9-arm
Reviewed-on: https://go-review.googlesource.com/c/go/+/663195
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Richard Miller <millerresearch@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Non-release versions that are built from source without a VERSION file
specifying any particular version end up with a development version like
"devel go1.25-67e0681aef Thu Apr 24 12:17:27 2025 -0700". Right now
those versions are correctly determined to be non-release because they
don't have a "go" prefix, instead they have a "devel " prefix.
In preparation of being able to move the "devel" substring, add a check
that said substring isn't present anywhere, since it is certain not to
be included in any released Go version we publish at https://go.dev/dl/.
For #73372.
Change-Id: Ia3e0d03b5723d4034d6270c3a2224f8dfae380e9
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/667955
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
We currently make some parts of the preamble unpreemptible because
it confuses morestack. See comments in the code.
Instead, have morestack handle those weird cases so we can
remove unpreemptible marks from most places.
This CL makes user functions preemptible everywhere if they have no
write barriers (at least, on x86). In cmd/go the fraction of functions
that need preemptible markings drops from 82% to 36%. Makes the cmd/go
binary 0.3% smaller.
Update #35470
Change-Id: Ic83d5eabfd0f6d239a92e65684bcce7e67ff30bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/648518
Auto-Submit: Keith Randall <khr@google.com>
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>
Go 1.25 will gain support for overlapped IO on handles passed to
os.NewFile thanks to CL 662236. It was previously not possible to add
an overlapped handle to the Go runtime's IO completion port (IOCP),
and now happens on the first call the an IO method.
This means that there is code that relies on the fact that File.Fd
returns a handle that can always be associated with a custom IOCP.
That wouldn't be the case anymore, as a handle can only be associated
with one IOCP at a time and it must be explicitly disassociated.
To fix this breaking change, File.Fd will disassociate the handle
from the Go runtime IOCP before returning it. It is then not necessary
to defer the association until the first IO method is called, which
was recently added in CL 661955 to support this same use case, but
in a more complex and unreliable way.
Updates #19098.
Cq-Include-Trybots: luci.golang.try:gotip-windows-amd64-race,gotip-windows-amd64-longtest,gotip-windows-arm64
Change-Id: Id8a7e04d35057047c61d1733bad5bf45494b2c28
Reviewed-on: https://go-review.googlesource.com/c/go/+/664455
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
We only want to call into the race detector for Go global variables.
By rounding up the region bounds, we can include some C globals.
Even worse, we can include only *part* of a C global, leading to
race{read,write}range calls which straddle the end of shadow memory.
That causes the race detector to barf.
Fix some off-by-one errors in the assembly comparisons. We want to
skip calling the race detector when addr == racedataend.
Fixes#73483
Change-Id: I436b0f588d6165b61f30cb7653016ba9b7cbf585
Reviewed-on: https://go-review.googlesource.com/c/go/+/667655
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: Dmitry Vyukov <dvyukov@google.com>
Currently we assume alignment to 8 bytes, so we can steal the low 3 bits.
This CL assumes alignment to 512 bytes, so we can steal the low 9 bits.
That's 6 extra bits!
Aligning to 512 bytes wastes a bit of space but it is not egregious.
Most of the objects that we make tagged pointers to are pretty big.
Update #49405
Change-Id: I66fc7784ac1be5f12f285de1d7851d5a6871fb75
Reviewed-on: https://go-review.googlesource.com/c/go/+/665815
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
If the thing we're ranging over is an array or ptr to array, and
it doesn't have a function call or channel receive in it, then we
shouldn't evaluate it.
Typecheck the ranged-over value as a constant in that case.
That makes the unified exporter replace the range expression
with a constant int.
Change-Id: I0d4ea081de70d20cf6d1fa8d25ef6cb021975554
Reviewed-on: https://go-review.googlesource.com/c/go/+/659317
Reviewed-by: Junyang Shao <shaojunyang@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Broadly speaking, escape analysis has two main phases. First, it
traverses the AST while building a data-flow graph of locations and
edges. Second, during "solve", it repeatedly walks the data-flow graph
while carefully propagating information about each location, including
whether a location's address reaches the heap.
Once escape analysis is in the solve phase and repeatedly walking the
data-flow graph, almost all the information it needs is within the
location graph, with a notable exception being the ir.Class of an
ir.Name, which currently must be checked by following a pointer from
the location to its ir.Node.
For typical graphs, that does not matter much, but if the graph becomes
large enough, cache misses in the inner solve loop start to matter more,
and the class is checked many times in the inner loop.
We therefore store the class information on the location in the graph
to reduce how much memory we need to load in the inner loop.
The package github.com/microsoft/typescript-go/internal/checker
has many locations, and compilation currently spends most of its time
in escape analysis.
This CL gives roughly a 30% speedup for wall clock compilation time
for the checker package:
go1.24.0: 91.79s
this CL: 64.98s
Linux perf shows a healthy reduction for example in l2_request.miss and
dTLB-load-misses on an amd64 test VM.
We could tweak things a bit more, though initial review feedback
has suggested it would be good to get this in as it stands.
Subsequent CLs in this stack give larger improvements.
Updates #72815
Change-Id: I3117430dff684c99e6da1e0d7763869873379238
Reviewed-on: https://go-review.googlesource.com/c/go/+/657295
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Jake Bailey <jacob.b.bailey@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
The arith assembly is big enough, and the details that you have to keep
in mind are complex enough and varied enough, that it is worth using
a Go program to generate the assembly. That way, all the architectures
can use the same algorithms, and porting to new architectures will be
easier.
This is the first of a sequence of CLs to introduce a new mini-compiler
for generating the arith assembly, in math/big/internal/asmgen.
This CL has the basics of the compiler as well as a couple simple
architectures and the generator for addVV/subVV. It does not check
in the generated assembly yet. That will happen in a followup CL after
the other architectures and generators have been added.
Change-Id: Ib704c60fd972fc5690ac04d8fae3712ee2c1a80a
Reviewed-on: https://go-review.googlesource.com/c/go/+/664935
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>
The Unicode specification defines aliases for some of the general
category names. For example the category "L" has alias "Letter".
The regexp package supports \p{L} but not \p{Letter}, because there
was nothing in the Unicode tables that lets regexp know about Letter.
Now that package unicode provides CategoryAliases (see #70780),
we can use it to provide \p{Letter} as well.
This is the only feature missing from making package regexp suitable
for use in a JSON-API Schema implementation. (The official test suite
includes usage of aliases like \p{Letter} instead of \p{L}.)
For better conformity with Unicode TR18, also accept case-insensitive
matches for names and ignore underscores, hyphens, and spaces;
and add Any, ASCII, and Assigned.
Fixes#70781.
Change-Id: I50ff024d99255338fa8d92663881acb47f1e92a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/641377
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
This test fails on GOEXPERIMENT=noswissmap as it is testing behavior
specific to swissmaps. Move it to map_swiss_test.go to skip it on
noswissmap.
We could also switch the test to use NewTestMap, which provides a
swissmap even in GOEXPERIMENT=noswissmap, but that is tedious to use and
noswissmap is going away soon anyway.
For #70886.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest-noswissmap
Change-Id: I6a6a636c5ec72217d936cd01e9da36ae127ea2c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/666437
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This imports the proposed new v2 JSON API implemented in
github.com/go-json-experiment/json as of commit
d3c622f1b874954c355e60c8e6b6baa5f60d2fed.
When GOEXPERIMENT=jsonv2 is set, the encoding/json/v2 and
encoding/jsontext packages are visible, the encoding/json
package is implemented in terms of encoding/json/v2, and
the encoding/json package include various additional APIs.
(See #71497 for details.)
When GOEXPERIMENT=jsonv2 is not set, the new API is not
present and the encoding/json package is unchanged.
The experimental API is not bound by the Go compatibility
promise and is expected to evolve as updates are made to
the json/v2 proposal.
The contents of encoding/json/internal/jsontest/testdata
are compressed with zstd v1.5.7 with the -19 option.
Fixes#71845
For #71497
Change-Id: Ib8c94e5f0586b6aaa22833190b41cf6ef59f4f01
Reviewed-on: https://go-review.googlesource.com/c/go/+/665796
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>
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
CL 653856 enabled stack allocation of variable-sized makeslice results.
This CL adds debug hashing of that change, plus a debug flag
to control the byte threshold used.
The debug hashing machinery means we also now have a way to disable just
the CL 653856 optimization by doing -gcflags='all=-d=variablemakehash=n'
or similar, though the stderr output will then typically have many
lines of debug hash output.
Using this CL plus the bisect command, I was able to retroactively
find one of the lines of code responsible for #73199:
$ bisect -compile=variablemake go test -skip TestListWireGuardDrivers
[...]
bisect: FOUND failing change set
--- change set #1 (enabling changes causes failure)
./security_windows.go:1321:38 (variablemake)
./security_windows.go:1321:38 (variablemake)
---
Previously, I had tracked down those lines by diffing '-gcflags=-m=1'
output and brief code inspection, but seeing the bisect was very nice.
This CL also adds a compiler debug flag to control the threshold for
stack allocation of variably sized make results. This can help
us identify more code that is relying on certain stack allocations.
This might be a temporary flag that we delete prior to Go 1.25
(given we would not want people to rely on it), or maybe it
might make sense to keep it for some period of time beyond the release
of Go 1.25 to help the ecosystem shake out other bugs.
Using these two flags together (and picking a threshold of 64 rather
than the default of 32), it looks for example like this
x/sys/windows code might be relying on stack allocation of
a byte slice:
$ bisect -compile=variablemake go test -gcflags=-d=variablemakethreshold=64 -skip TestListWireGuardDrivers
[...]
bisect: FOUND failing change set
--- change set #1 (enabling changes causes failure)
./syscall_windows_test.go:1178:16 (variablemake)
Updates #73199Fixes#73253
Change-Id: I160179a0e3c148c3ea86be5c9b6cea8a52c3e5b7
Reviewed-on: https://go-review.googlesource.com/c/go/+/663795
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@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>
TestScan loads encoding/json and verifies that various imports
match expectations. The new v2 encoding/json violates these
expectations. Since this test is testing the ScanDir function,
not encoding/json, change it to use a test package with defined
imports instead.
Change-Id: I68a0813ccf37daadbd6ea52872a8ac132141e82a
Reviewed-on: https://go-review.googlesource.com/c/go/+/665795
Reviewed-by: Alan Donovan <adonovan@google.com>
TryBot-Bypass: Damien Neil <dneil@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
CL 661575 inadvertently caused os.RemoveDir on Windows to
fail when given a path with a trailing / or \, due to the
splitPath function not correctly stripping trailing
separators.
Fixes#73317
Change-Id: I21977b94bb08ff1e563de6f5f16a4bdf5024a15e
Reviewed-on: https://go-review.googlesource.com/c/go/+/664715
Auto-Submit: Damien Neil <dneil@google.com>
TryBot-Bypass: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
Before CL, all instances of gQueue and gList stored the size of
structures in a separate variable. The size changed manually and passed
as a separate argument to different functions. This CL added an
additional field to gQueue and gList structures to store the size. Also,
the calculation of size was moved into the implementation of API for
these structures. This allows to reduce possible errors by eliminating
manual calculation of the size and simplifying functions' signatures.
Change-Id: I087da2dfaec4925e4254ad40fce5ccb4c175ec41
Reviewed-on: https://go-review.googlesource.com/c/go/+/664777
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
The implementation of iter.Pull and iter.Pull2 functions is based on
closures and sharing local state, which results in one heap allocation
for each captured variable.
The number of heap allocations can be reduced by grouping the state
shared between closures in a struct, allowing the compiler to allocate
all local variables in a single heap region instead of creating
individual heap objects for each variable.
This approach can sometimes have downsides when it couples unrelated
objects in a single memory region, preventing the garbage collector from
reclaiming unused memory. While technically only a subset of the local
state is shared between the next and stop functions, it seems unlikely
that retaining the rest of the state until stop is reclaimed would be
problematic in practice, since the two closures would often have very
similar lifetimes.
The change also reduces the total memory footprint due to alignment
rules, the two booleans can be packed in memory and sometimes can even
exist within the padding space of the v value. There is also less
metadata needed for the garbage collector to track each individual heap
allocation.
goos: darwin
goarch: arm64
pkg: iter
cpu: Apple M2 Pro
│ /tmp/bench.old │ /tmp/bench.new │
│ sec/op │ sec/op vs base │
Pull-12 218.6n ± 7% 146.1n ± 0% -33.19% (p=0.000 n=10)
Pull2-12 239.8n ± 5% 155.0n ± 5% -35.36% (p=0.000 n=10)
geomean 229.0n 150.5n -34.28%
│ /tmp/bench.old │ /tmp/bench.new │
│ B/op │ B/op vs base │
Pull-12 288.0 ± 0% 176.0 ± 0% -38.89% (p=0.000 n=10)
Pull2-12 312.0 ± 0% 176.0 ± 0% -43.59% (p=0.000 n=10)
geomean 299.8 176.0 -41.29%
│ /tmp/bench.old │ /tmp/bench.new │
│ allocs/op │ allocs/op vs base │
Pull-12 11.000 ± 0% 5.000 ± 0% -54.55% (p=0.000 n=10)
Pull2-12 12.000 ± 0% 5.000 ± 0% -58.33% (p=0.000 n=10)
geomean 11.49 5.000 -56.48%
Change-Id: Iccbe233e8ae11066087ffa4781b66489d0d410a7
Reviewed-on: https://go-review.googlesource.com/c/go/+/552375
Reviewed-by: Sean Liao <sean@liao.dev>
Auto-Submit: Sean Liao <sean@liao.dev>
Reviewed-by: qiu laidongfeng2 <2645477756@qq.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This is a case where CL 653856 saves an allocation.
│ old │ new │
│ sec/op │ sec/op vs base │
Join-24 73.57n ± 1% 60.27n ± 1% -18.07% (p=0.000 n=10)
│ old │ new │
│ B/op │ B/op vs base │
Join-24 48.00 ± 0% 24.00 ± 0% -50.00% (p=0.000 n=10)
│ old │ new │
│ allocs/op │ allocs/op vs base │
Join-24 2.000 ± 0% 1.000 ± 0% -50.00% (p=0.000 n=10)
Change-Id: I56308262ca73a7ab9698b54fd8681f5b44626995
Reviewed-on: https://go-review.googlesource.com/c/go/+/665075
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>
When the compiler builds a Go package with DWARF 5 generation enabled,
it emits relocations into various generated DWARF symbols (ex:
SDWARFFCN) that use the R_DWTXTADDR_* flavor of relocations. The
specific size of this relocation is selected based on the total number
of functions in the package -- if the package is tiny (just a couple
funcs) we can use R_DWTXTADDR_U1 relocs (which target just a byte); if
the package is larger we might need to use the 2-byte or 3-byte flavor
of this reloc.
Prior to this patch, the strategy used to pick the right relocation
size was flawed in that it didn't take into account packages with
assembly code. For example, if you have a package P with 200 funcs
written in Go source and 200 funcs written in assembly, you can't use
the R_DWTXTADDR_U1 reloc flavor for indirect text references since the
real function count for the package (asm + go) exceeds 255.
The new strategy (with this patch) is to have the compiler look at the
"symabis" file to determine the count of assembly functions. For the
assembler, rather than create additional plumbing to pass in the Go
source func count we just use an dummy (artificially high) function
count so as to select a relocation that will be large enough.
Fixes#72810.
Updates #26379.
Change-Id: I98d04f3c6aacca1dafe1f1610c99c77db290d1d8
Reviewed-on: https://go-review.googlesource.com/c/go/+/663235
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>
It is annoying that non-x86 implementations of shlVU and shrVU
have to go out of their way to handle the trivial case shift==0
with their own copy loops. Instead, arrange to never call them
with shift==0, so that the code can be removed.
Unfortunately, there are linknames of shlVU, so we cannot
change that function. But we can rename the functions and
then leave behind a shlVU wrapper, so do that.
Since the big.Int API calls the operations Lsh and Rsh, rename
shlVU/shrVU to lshVU/rshVU. Also rename various other shl/shr
methods and functions to lsh/rsh.
Change-Id: Ieaf54e0110a298730aa3e4566ce5be57ba7fc121
Reviewed-on: https://go-review.googlesource.com/c/go/+/664896
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
addMulVVW is an unnecessarily special case.
All other assembly routines taking []Word (V as in vector) arguments
take separate source and destination. For example:
addVV: z = x+y
mulAddVWW: z = x*m+a
addMulVVW uses the z parameter as both destination and source:
addMulVVW: z = z+x*m
Even looking at the signatures is confusing: all the VV routines take
two input vectors x and y, but addMulVVW takes only x: where is y?
(The answer is that the two inputs are z and x.)
It would be nice to fix this, both for understandability and regularity,
and to simplify a future assembly generator.
We cannot remove or redefine addMulVVW, because it has been used
in linknames. Instead, the CL adds a new final addend argument ‘a’
like in mulAddVWW, making the natural name addMulVVWW
(two input vectors, two input words):
addMulVVWW: z = x+y*m+a
This CL updates all the assembly implementations to rename the
inputs z, x, y -> x, y, m, and then introduces a separate destination z.
Change-Id: Ib76c80b53f6d1f4a901f663566e9c4764bb20488
Reviewed-on: https://go-review.googlesource.com/c/go/+/664895
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
The sendfile implementation for platforms supporting it is now in
net/sendfile.go, rather than being duplicated in separate files for
each platform.
The only difference between the implementations was the poll.SendFile
parameters, which have been harmonized, and also linux strictly
asserting for os.File, which now have been relaxed to allow any
type implementing syscall.Conn.
Change-Id: Ia1a2d5ee7380710a36fc555dbf681f7e996ea2ec
Reviewed-on: https://go-review.googlesource.com/c/go/+/664075
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Quim Muntal <quimmuntal@gmail.com>
Windows sendfile optimization is skipped since CL 472475, which started
passing an os.fileWithoutWriteTo instead of an os.File to sendfile,
and that function was only implemented for os.File.
This CL fixes the issue by asserting against an interface rather than
a concrete type.
Some tests have been reenabled, triggering bugs in poll.SendFile which
have been fixed in this CL.
Fixes#67042.
Cq-Include-Trybots: luci.golang.try:gotip-windows-amd64-longtest
Change-Id: Id6f7a0e1e0f34a72216fa9d00c5bf36f5a994219
Reviewed-on: https://go-review.googlesource.com/c/go/+/664055
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>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
The following sequence in the scheduler may potentially lead to
deadlock:
- globrunqget() -> runqput() -> runqputslow() -> globrunqputbatch()
However, according to the current logic of the scheduler it is not
possible to face the deadlock.
The patch explicitly excludes the deadlock, even though it is impossible
situation at the moment.
Additionally, the "runq" and "globrunq" APIs were partially refactored,
which allowed to minimize the usage of these APIs by each other.
This will prevent situations described in the CL.
Change-Id: I7318f935d285b95522998e0903eaa6193af2ba48
Reviewed-on: https://go-review.googlesource.com/c/go/+/662216
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
CL 518776 dropped the ability of 'go mod init' to convert
legacy pre-module dependency configuration files, such as automatically
transforming a Gopkg.lock to a go.mod file with similar requirements,
but some of the documentation remained.
In this CL, we remove it from the cmd/go documentation.
(CL 662675 is a companion change that removes it from the Modules
Reference page).
Updates #71537
Change-Id: Ieccc64c811c4c25a657c00e42f7362a32b5fd661
Reviewed-on: https://go-review.googlesource.com/c/go/+/662695
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Sean Liao <sean@liao.dev>
Auto-Submit: Sean Liao <sean@liao.dev>
Previously, Hijack allocated a new write buffer and the existing
connection write buffer used an extra 4KiB of memory until the handler
finished and the "conn" was garbage collected. Now, hijack re-uses the
existing write buffer and re-attaches it to the raw connection to avoid
referencing the net/http "conn" after returning.
After a handler that hijacked exited, the "conn" reference in
"connReader" will now be unset. This allows all of the "conn",
"response" and "Request" to get garbage collected.
Overall, this is reducing the memory usage by 43% or 6.7KiB per hijacked
connection (see BenchmarkServerHijackMemoryUsage in an earlier revision
of the CL).
CloseNotify will continue to work _before_ the handler has exited
(i.e. while the "conn" is still referenced in "connReader"). This aligns
with the documentation of CloseNotifier:
> After the Handler has returned, there is no guarantee that the channel
> receives a value.
goos: linux
goarch: amd64
pkg: net/http
cpu: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz
│ before │ after │
│ sec/op │ sec/op vs base │
ServerHijack-8 42.59µ ± 8% 39.47µ ± 16% ~ (p=0.481 n=10)
│ before │ after │
│ B/op │ B/op vs base │
ServerHijack-8 16.12Ki ± 0% 12.06Ki ± 0% -25.16% (p=0.000 n=10)
│ before │ after │
│ allocs/op │ allocs/op vs base │
ServerHijack-8 51.00 ± 0% 49.00 ± 0% -3.92% (p=0.000 n=10)
Change-Id: I20a37ee314ed0d47463a4657d712154e78e48138
GitHub-Last-Rev: 80f09dfa27
GitHub-Pull-Request: golang/go#70756
Reviewed-on: https://go-review.googlesource.com/c/go/+/634855
Reviewed-by: Sean Liao <sean@liao.dev>
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>
Auto-Submit: Sean Liao <sean@liao.dev>
There is a potential race between a concurrent call to FD.initIO, which
calls FD.pd.init, and a call to FD.Close, which calls FD.pd.evict.
This is solved by calling FD.initIO in FD.Close, as that will block
until the concurrent FD.initIO has completed. Note that FD.initIO is
no-op if first called from here.
The race window is so small that it is not possible to write a test
that triggers it.
Change-Id: Ie2f2818e746b9d626fe3b9eb6b8ff967c81ef863
Reviewed-on: https://go-review.googlesource.com/c/go/+/663815
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>
This CL removes some unnecessary code and duplicated NewFile tests
cases.
It also simplifies TestPipeCanceled by removing the need for using
SetReadDeadline. Using CancelIoEx instead of CancelIo makes the cancel
operations to finish almost instantly. The latter could take more than
20s to finish if called from a thread different from the one that
called ReadFile.
Change-Id: I9033cbcad277666bc2aec89b3e5a3ef529da2cd8
Reviewed-on: https://go-review.googlesource.com/c/go/+/663755
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
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>
Windows' _PROC_THREAD_ATTRIBUTE_LIST can contain pointers to memory
owned by Go, but the GC is not aware of this. This can lead to the
memory being freed while the _PROC_THREAD_ATTRIBUTE_LIST is still in
use.
This CL uses the same approach as in x/sys/windows to ensure that the
attributes are not collected by the GC.
Fixes#73170.
Updates #73199.
Cq-Include-Trybots: luci.golang.try:gotip-windows-amd64-longtest
Change-Id: I7dca8d386aed4c02fdcd4a631d0fa4dc5747a96f
Reviewed-on: https://go-review.googlesource.com/c/go/+/663715
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
We were not passing the module path to newCodeRepo which caused it to
incorrectly parse the major version. This allowed v0 and v1 modules to
work because an empty major version is allowed in that case.
Additionally we need to pass the root module path to derive the correct tag
for subdirectories.
Fixes: #72877Fixes: #71738
Change-Id: Id792923f426858513972e713623270edbc76c545
Reviewed-on: https://go-review.googlesource.com/c/go/+/661875
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
The runtime/poll package has just gained support for overlapped IO,
see CL 660595 and CL 661955. The only remaining piece was making it
visible to user code via os.NewFile.
Some of the poll.FD.Init responsibility has been moved to os.NewFile
to avoid unnecessary syscalls for the common case of using os.Open,
os.Create, os.OpenFile, and os.Pipe, where we know that the file
is not opened for overlapped IO.
Some internal/poll tests have been moved to the os package to exercise
public APIs rather than internal ones.
The os.NewFile function definition has been moved into an OS-agnostic
file to avoid having duplicated documentation and ensure that the
caller is aware of its behavior across all platforms.
Closes#19098.
Cq-Include-Trybots: luci.golang.try:gotip-windows-amd64-longtest,gotip-windows-amd64-race,gotip-windows-arm64
Change-Id: If043f8b34d588cd4b481777203107ed92d660fd9
Reviewed-on: https://go-review.googlesource.com/c/go/+/662236
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Auto-Submit: Damien Neil <dneil@google.com>
Instead of always allocating variable-sized "make" calls on the heap,
allocate a small, constant-sized array on the stack and use that array
as the backing store if it is big enough.
Requires the result of the "make" doesn't escape.
if cap <= K {
var arr [K]E
slice = arr[:len:cap]
} else {
slice = makeslice(E, len, cap)
}
Pretty conservatively for now, K = 32/sizeof(E). The slice header is
already 24 bytes, so wasting 32 bytes of stack if the requested size
is too big isn't that bad. Larger would waste more stack space but
maybe avoid more allocations.
This CL also requires the element type be pointer-free. Maybe we
could relax that at some point, but it is hard. If the element type
has pointers we can get heap->stack pointers (in the case where the
requested size is too big and the slice is heap allocated).
Note that this only handles the case of makeslice called directly from
compiler-generated code. It does not handle slices built in the
runtime on behalf of the program (e.g. in growslice). Some of those
are currently handled by passing in a tmpBuf (e.g. concatstrings),
but we could probably do more.
Change-Id: I8378efad527cd00d25948a80b82a68d88fbd93a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/653856
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Improve the compiler's store-to-load forwarding optimization by relaxing the
type comparison condition. Instead of requiring exact type equality (CMPeq),
we now use copyCompatibleType which allows forwarding between compatible
types where safe.
Fix several size comparison bugs in the nested store patterns. Previously,
we were comparing the size of the outer store with the load type,
rather than comparing with the size of the actual store being forwarded
from.
Skip OpConvert in dead store elimination to help get rid of dead stores such
as zeroing slices. OpConvert, like OpInlMark, doesn't really use the memory.
This optimization is particularly beneficial for code that creates slices with
computed pointers, such as the runtime's heapBitsSlice function, where
intermediate calculations were previously causing the compiler to miss
store-to-load forwarding opportunities.
Local sweet run result on an x86_64 laptop:
│ Orig.res │ Hopt.res │
│ sec/op │ sec/op vs base │
BiogoIgor-8 5.303 ± 1% 5.322 ± 1% ~ (p=0.190 n=10)
BiogoKrishna-8 7.894 ± 1% 7.828 ± 2% ~ (p=0.190 n=10)
BleveIndexBatch100-8 2.257 ± 1% 2.248 ± 2% ~ (p=0.529 n=10)
EtcdPut-8 30.12m ± 1% 30.03m ± 1% ~ (p=0.796 n=10)
EtcdSTM-8 127.1m ± 1% 126.2m ± 0% -0.74% (p=0.023 n=10)
GoBuildKubelet-8 52.21 ± 0% 52.05 ± 1% ~ (p=0.063 n=10)
GoBuildKubeletLink-8 4.342 ± 1% 4.305 ± 0% -0.85% (p=0.000 n=10)
GoBuildIstioctl-8 43.33 ± 0% 43.24 ± 0% -0.22% (p=0.015 n=10)
GoBuildIstioctlLink-8 4.604 ± 1% 4.598 ± 0% ~ (p=0.063 n=10)
GoBuildFrontend-8 15.33 ± 0% 15.29 ± 0% ~ (p=0.143 n=10)
GoBuildFrontendLink-8 740.0m ± 1% 737.7m ± 1% ~ (p=0.912 n=10)
GopherLuaKNucleotide-8 9.590 ± 1% 9.656 ± 1% ~ (p=0.165 n=10)
MarkdownRenderXHTML-8 96.97m ± 1% 97.26m ± 2% ~ (p=0.105 n=10)
Tile38QueryLoad-8 335.9µ ± 1% 335.6µ ± 1% ~ (p=0.481 n=10)
geomean 1.336 1.333 -0.22%
Change-Id: I031552623e6d5a3b1b5be8325e6314706e45534f
Reviewed-on: https://go-review.googlesource.com/c/go/+/662075
Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Carlos Amedee <carlos@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Add a regression test similar to the reproducer from #73141 to try to
help catch future issues with vgetrandom and thread exit. Though the
test isn't very precise, it just hammers thread exit.
When the test reproduces #73141, it simply crashes with a SIGSEGV and no
output or stack trace, which would be very unfortunate on a builder.
https://go.dev/issue/49165 tracks collecting core dumps from builders,
which would make this more tractable to debug.
For #73141.
Change-Id: I6a6a636c7d7b41e2729ff6ceb30fd7f979aa9978
Reviewed-on: https://go-review.googlesource.com/c/go/+/662636
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
The unsafe.Pointer -> uintptr conversion must happen when calling
syscall.Syscall, not when calling the auto-generated wrapper function,
else the Go compiler doesn't know that it has to keep the pointer alive.
This can cause undefined behavior and stack corruption.
Fixes#73135.
Fixes#73112 (potentially).
Fixes#73128 (potentially).
Cq-Include-Trybots: luci.golang.try:gotip-windows-amd64-race
Change-Id: Ib3ad8b99618d8997bfd0742c0e44aeda696856c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/662575
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Auto-Submit: Carlos Amedee <carlos@golang.org>
Due to a flaw in the %GOROOT_BOOTSTRAP% detection logic, the last Go
executable found by `where go` was taking precedence over the first one.
In batch scripts, environment variable expansion happens when each line
of the script is read, not when it is executed. Thus, the check in the
loop for GOROOT_BOOTSTRAP being unset would always be true, even when
the variable had been set in a previous loop iteration.
See SET /? for more information.
Change-Id: I15ddcbe771a902acb47a1f07ba7f4cb8a311e0dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/653535
Auto-Submit: Carlos Amedee <carlos@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
When an M is destroyed, we put its vgetrandom state back on the shared
list for another M to reuse. This list is simply a slice, so appending
to the slice may allocate. Currently this operation is performed in
mdestroy, after the P is released, meaning allocation is not allowed.
More the cleanup earlier in mdestroy when allocation is still OK.
Also add //go:nowritebarrierrec to mdestroy since it runs without a P,
which would have caught this bug.
Fixes#73141.
Change-Id: I6a6a636c3fbf5c6eec09d07a260e39dbb4d2db12
Reviewed-on: https://go-review.googlesource.com/c/go/+/662455
Reviewed-by: Jason Donenfeld <Jason@zx2c4.com>
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>
When both a direct call and an interface call appear on the same line,
PGO devirtualization may make a suboptimal decision. In some cases,
the directly called function becomes a candidate for devirtualization
if no other relevant outgoing edges with non-zero weight exist for the
caller's IRNode in the WeightedCG. The edge to this candidate is
considered the hottest. Despite having zero weight, this edge still
causes the interface call to be devirtualized.
This CL prevents devirtualization when the weight of the hottest edge
is 0.
Fixes#72092
Change-Id: I06c0c5e080398d86f832e09244aceaa4aeb98721
Reviewed-on: https://go-review.googlesource.com/c/go/+/655475
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Defer the association of the IOCP to the handle until the first
I/O operation is performed.
A handle can only be associated with one IOCP at a time, so this allows
external code to associate the handle with their own IOCP and still be
able to use a FD (through os.NewFile) to pass the handle around
(e.g. to a child process standard input, output, and error) without
having to worry about the IOCP association.
This CL doesn't change any user-visible behavior, as os.NewFile still
initializes the FD as non-pollable.
For #19098.
Change-Id: Id22a49846d4fda3a66ffcc0bc1b48eb39b395dc5
Reviewed-on: https://go-review.googlesource.com/c/go/+/661955
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>
Open /dev/bintime at process start on Plan 9,
marked close-on-exec, hold it open for the duration of the
process, and use it for obtaining time.
The change to using /dev/bintime also sets up for an upcoming
Plan 9 change to add monotonic time to that file. If the monotonic
field is available, then nanotime1 and time.now use that field.
Otherwise they fall back to using Unix nanoseconds as "monotonic",
as they always have.
Before this CL, monotonic time went backward any time
aux/timesync decided to adjust the system's time-of-day backward.
Also use /dev/random for randomness (once at startup).
Before this CL, there was no real randomness in the runtime
on Plan 9 (the crypto/rand package still had some). Now there will be.
Change-Id: I0c20ae79d3d96eff1a5f839a56cec5c4bc517e61
Reviewed-on: https://go-review.googlesource.com/c/go/+/656755
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Bypass: Russ Cox <rsc@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Calling syscall.ReadFile and syscall.WriteFile on overlapped handles
always need to be passed a valid *syscall.Overlapped structure, even if
the handle is not added to a IOCP (like the Go runtime poller). Else,
the syscall will fail with ERROR_INVALID_PARAMETER.
We also need to handle ERROR_IO_PENDING errors when the overlapped
handle is not added to the poller, in which case we need to block until
the operation completes.
Previous CLs already added support for overlapped handles to the poller,
mostly to keep track of the file offset independently of the file
pointer (which is not supported for overlapped handles).
Fixed#15388.
Updates #19098.
Change-Id: I2103ab892a37d0e326752ae8c2771a43c13ba42e
Reviewed-on: https://go-review.googlesource.com/c/go/+/661795
Auto-Submit: Quim Muntal <quimmuntal@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
On master, lookups on small Swiss Table maps (<= 8 elements) for
non-specialized key types are seemingly a performance regression
compared to the Go 1.23 map implementation (reported in #70849).
Currently, a linear scan is used for gets in these cases.
This CL changes (*Map).getWithKeySmall to instead use the SIMD or SWAR
match on the control bytes to then jump to candidate matching slots,
with sample results below for a 16-byte key. This especially helps the
hit case when the key is unpredictable, which previously had to scan an
unpredictable number of control bytes to find a candidate slot when the
key is unpredictable.
Separately, other CLs in this stack modify the main Swiss Table
benchmarks to randomize lookup key order (vs. previously most of the
benchmarks had a repeating lookup key ordering, which likely is
predictable until the map is too big). We have sample results for the
randomized key order benchmarks followed by results from the older
benchmarks.
The first table below is with randomized key order. For hits, the older
results get slower as there are more elements. With this CL, we see hits
for unpredictable key ordering (sizes 2-8) get a ~1.7x speedup from
~25ns to ~14ns, with a now consistent lookup time for the different
sizes. (The 1 element size map has a predictable key ordering because
there is only one key, and that reports a modest ~0.5ns or ~3%
performance penalty). Misses for unpredictable key order get a ~1.3x
speedup, from ~13ns to ~10ns, with similar results for the 1 element
size.
│ no-fix-new-bmarks │ fix-with-new-bmarks │
│ sec/op │ sec/op vs base │
MapSmallAccessHit/Key=smallType/Elem=int32/len=1-4 13.26n ± 0% 13.64n ± 0% +2.90% (p=0.000 n=20)
MapSmallAccessHit/Key=smallType/Elem=int32/len=2-4 19.47n ± 0% 13.62n ± 0% -30.05% (p=0.000 n=20)
MapSmallAccessHit/Key=smallType/Elem=int32/len=3-4 22.23n ± 0% 13.64n ± 0% -38.68% (p=0.000 n=20)
MapSmallAccessHit/Key=smallType/Elem=int32/len=4-4 23.98n ± 0% 13.64n ± 0% -43.11% (p=0.000 n=20)
MapSmallAccessHit/Key=smallType/Elem=int32/len=5-4 25.02n ± 0% 13.67n ± 0% -45.35% (p=0.000 n=20)
MapSmallAccessHit/Key=smallType/Elem=int32/len=6-4 25.77n ± 1% 13.68n ± 2% -46.89% (p=0.000 n=20)
MapSmallAccessHit/Key=smallType/Elem=int32/len=7-4 26.38n ± 0% 13.64n ± 0% -48.28% (p=0.000 n=20)
MapSmallAccessHit/Key=smallType/Elem=int32/len=8-4 26.31n ± 0% 13.71n ± 21% -47.90% (p=0.000 n=20)
MapSmallAccessMiss/Key=smallType/Elem=int32/len=1-4 13.055n ± 0% 9.815n ± 0% -24.82% (p=0.000 n=20)
MapSmallAccessMiss/Key=smallType/Elem=int32/len=2-4 13.070n ± 0% 9.813n ± 0% -24.92% (p=0.000 n=20)
MapSmallAccessMiss/Key=smallType/Elem=int32/len=3-4 13.060n ± 0% 9.819n ± 0% -24.82% (p=0.000 n=20)
MapSmallAccessMiss/Key=smallType/Elem=int32/len=4-4 13.075n ± 0% 9.816n ± 0% -24.92% (p=0.000 n=20)
MapSmallAccessMiss/Key=smallType/Elem=int32/len=5-4 13.060n ± 0% 9.826n ± 0% -24.76% (p=0.000 n=20)
MapSmallAccessMiss/Key=smallType/Elem=int32/len=6-4 13.095n ± 19% 9.834n ± 31% -24.90% (p=0.000 n=20)
MapSmallAccessMiss/Key=smallType/Elem=int32/len=7-4 13.075n ± 19% 9.822n ± 27% -24.88% (p=0.000 n=20)
MapSmallAccessMiss/Key=smallType/Elem=int32/len=8-4 13.11n ± 16% 12.14n ± 19% -7.43% (p=0.000 n=20)
The next table uses the original benchmarks from just before this CL
stack (i.e., without shuffling lookup keys).
With this CL, we see improvement that is directionally similar to the
above results but not as large, presumably because the branches in the
linear scan are fairly predictable with predictable keys. (The numbers
here also include the time from a mod in the benchmark code, which
seemed to take around ~1/3 of CPU time based on spot checking a couple
of examples, vs. the modified benchmarks shown above have removed that
mod).
│ master-8c3e391573 │ just-fix-with-old-bmarks │
│ sec/op │ sec/op vs base │
MapSmallAccessHit/Key=smallType/Elem=int32/len=1-4 20.85n ± 0% 21.69n ± 0% +4.03% (p=0.000 n=20)
MapSmallAccessHit/Key=smallType/Elem=int32/len=2-4 21.22n ± 0% 21.70n ± 0% +2.24% (p=0.000 n=20)
MapSmallAccessHit/Key=smallType/Elem=int32/len=3-4 21.73n ± 0% 21.71n ± 0% ~ (p=0.158 n=20)
MapSmallAccessHit/Key=smallType/Elem=int32/len=4-4 22.06n ± 0% 21.71n ± 0% -1.56% (p=0.000 n=20)
MapSmallAccessHit/Key=smallType/Elem=int32/len=5-4 22.41n ± 0% 21.73n ± 0% -3.01% (p=0.000 n=20)
MapSmallAccessHit/Key=smallType/Elem=int32/len=6-4 22.71n ± 0% 21.72n ± 0% -4.38% (p=0.000 n=20)
MapSmallAccessHit/Key=smallType/Elem=int32/len=7-4 22.98n ± 0% 21.71n ± 0% -5.53% (p=0.000 n=20)
MapSmallAccessHit/Key=smallType/Elem=int32/len=8-4 23.20n ± 0% 21.72n ± 0% -6.36% (p=0.000 n=20)
MapSmallAccessMiss/Key=smallType/Elem=int32/len=1-4 19.95n ± 0% 17.30n ± 0% -13.28% (p=0.000 n=20)
MapSmallAccessMiss/Key=smallType/Elem=int32/len=2-4 19.96n ± 0% 17.31n ± 0% -13.28% (p=0.000 n=20)
MapSmallAccessMiss/Key=smallType/Elem=int32/len=3-4 19.95n ± 0% 17.29n ± 0% -13.33% (p=0.000 n=20)
MapSmallAccessMiss/Key=smallType/Elem=int32/len=4-4 19.95n ± 0% 17.30n ± 0% -13.29% (p=0.000 n=20)
MapSmallAccessMiss/Key=smallType/Elem=int32/len=5-4 19.96n ± 25% 17.32n ± 0% -13.22% (p=0.000 n=20)
MapSmallAccessMiss/Key=smallType/Elem=int32/len=6-4 19.99n ± 24% 17.29n ± 0% -13.51% (p=0.000 n=20)
MapSmallAccessMiss/Key=smallType/Elem=int32/len=7-4 19.97n ± 20% 17.34n ± 16% -13.14% (p=0.000 n=20)
MapSmallAccessMiss/Key=smallType/Elem=int32/len=8-4 20.02n ± 11% 17.33n ± 14% -13.44% (p=0.000 n=20)
geomean 21.02n 19.39n -7.78%
See #70849 for additional benchmark results, including results for arm64
(which also means without SIMD support).
Updates #54766
Updates #70700Fixes#70849
Change-Id: Ic2361bb6fc15b4436d1d1d5be7e4712e547f611b
Reviewed-on: https://go-review.googlesource.com/c/go/+/634396
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
With recent LLVM toolchain, on macOS/AMD64, the race detector syso
file built from it contains X86_64_RELOC_SUBTRACTOR relocations,
which the Go linker currently doesn't handle in internal linking
mode. To ensure internal linking mode continue to work with the
race detector syso, this CL adds support of X86_64_RELOC_SUBTRACTOR
relocations.
X86_64_RELOC_SUBTRACTOR is actually a pair of relocations that
resolves to the difference between two symbol addresses (each
relocation specifies a symbol). For the cases we care (the race
syso), the symbol being subtracted out is always in the current
section, so we can just convert it to a PC-relative relocation,
with the addend adjusted. If later we need the more general form,
we can introduce a new mechanism (say, objabi.R_DIFF) that works
as a pair of relocations like the Mach-O one.
As we expect the pair of relocations be consecutive, don't reorder
(sort) relocation records when loading Mach-O objects.
Change-Id: I757456b07270fb4b2a41fd0fef67a2b39dd6b238
Reviewed-on: https://go-review.googlesource.com/c/go/+/660715
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Than McIntosh <thanm@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
FD.Read converts a syscall.ERROR_OPERATION_ABORTED error to
ErrFileClosing. It does that in case the pipe operation was aborted by
a CancelIoEx call in FD.Close.
It doesn't take into account that the operation might have been
aborted by a CancelIoEx call in external code. In that case, the
operation should return the error as is.
Change-Id: I75dcf0edaace8b57dc47b398ea591ca9f116112b
Reviewed-on: https://go-review.googlesource.com/c/go/+/661555
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>
The docs currently are imprecise about comparisons. This could lead
users to believe that objects of the same type, allocated at the same
address, could produce weak pointers that are equal to
previously-created weak pointers. This is not the case. Weak pointers
map to objects, not addresses.
Update the documentation to state precisely that if two pointers do not
compare equal, then two weak pointers created from those two pointers
are guaranteed not to compare equal. Since a future pointer pointing to
the same address is not comparable with a pointer produced *before* an
object at that address has been reclaimed, this is sufficient to explain
that weak pointers map 1:1 with object offsets, not addresses.
(An object slot cannot be reused unless that slot is unreachable, so
by construction, there's never an opportunity to compare an "old" and
"new" pointer unless one uses unsafe tricks that violate the
unsafe.Pointer rules.)
Fixes#71381.
Change-Id: I5509fd433cde013926d725694d480c697a8bc911
Reviewed-on: https://go-review.googlesource.com/c/go/+/643935
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>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
When two packages declare a variable with the same name (with
linkname at least on one side), the linker will choose one as the
actual definition of the symbol if one has content (i.e. a DATA
symbol) and the other does not (i.e. a BSS symbol). When both have
content, it is redefinition error. When neither has content,
currently the choice is sort of arbitrary (depending on symbol
loading order, etc. which are subject to change).
One use case for that is that one wants to reference a symbol
defined in another package, and the reference side just wants to
see some of the fields, so it may be declared with a smaller type.
In this case, we want to choose the one with the larger size as
the true definition. Otherwise the code accessing the larger
sized one may read/write out of bounds, corrupting the next
variable. This CL makes the linker do so.
Fixes#72032.
Change-Id: I160aa9e0234702066cb8f141c186eaa89d0fcfed
Reviewed-on: https://go-review.googlesource.com/c/go/+/660696
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@golang.org>
Empty writes might be important for some protocols. Let Windows decide
what do with them rather than skipping them on our side. This is inline
with the behavior of other platforms.
While here, refactor the Read/Write/Pwrite methods to reduce one
indentation level and make the code easier to read.
Fixes#73084.
Change-Id: Ic5393358e237d53b8be6097cd7359ac0ff205309
Reviewed-on: https://go-review.googlesource.com/c/go/+/661435
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Optimise more branches with zero on riscv64. In particular, BLTU with
zero occurs with IsInBounds checks for index zero. This currently results
in two instructions and requires an additional register:
li t2, 0
bltu t2, t1, 0x174b4
This is equivalent to checking if the bounds is not equal to zero. With
this change:
bnez t1, 0x174c0
This removes more than 500 instructions from the Go binary on riscv64.
Change-Id: I6cd861d853e3ef270bd46dacecdfaa205b1c4644
Reviewed-on: https://go-review.googlesource.com/c/go/+/606715
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
This CL adds support for async file operations on Windows. The affected
functions are Read, Write, Pread, and Pwrite.
The code has been slightly refactored to avoid duplication. Both the
async and sync variants follow the same code path, with the exception of
the async variant passes an overlapped structure to the syscalls
and supports the use of a completion port.
This doesn't change any user-facing behavior, as the os package still
sets the pollable parameter to false when calling FD.Init.
For #19098.
Change-Id: Iead6e51fa8f57e83456eb5ccdce28c2ea3846cc2
Reviewed-on: https://go-review.googlesource.com/c/go/+/660595
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>
Before this change, in several cases where HasModRoot() returned false,
we'd return ErrNoModRoot. ErrNoModRoot would say that there was no
go.mod file but would not mention workspaces. With this change,
ErrNoModRoot will return error text that's different if we're in a
workspace, saying that there are no modules in the workspace.
Fixes#54419
Change-Id: I77c94d0011947bf8e33c066416ab3762502fd2e6
Reviewed-on: https://go-review.googlesource.com/c/go/+/660675
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Setting the SIO_UDP_CONNRESET option in internal/poll.FD.Init
adds unnecessary complexity to the FD.Init signature and
implementation. Better to set it in the net package when initializing
the UDP connection, which is where conceptually it belongs.
While here, update an outdated comment in FD.Init that said the runtime
poller doesn't support I/O operations initialized by the user
outside the internal/poll package. It does support those operations
since CL 561895.
For #19098.
Updates #21172.
Change-Id: I9a70b0deafdb4619830abe2147e2d366b4c2b890
Reviewed-on: https://go-review.googlesource.com/c/go/+/660496
Auto-Submit: Damien Neil <dneil@google.com>
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>
Currently, if the user stops the timer in a B.Loop benchmark loop, the
benchmark will run until it hits the timeout and fails.
Fix this by detecting that the timer is stopped and failing the
benchmark right away. We avoid making the fast path more expensive for
this check by "poisoning" the B.Loop iteration counter when the timer
is stopped so that it falls back to the slow path, which can check the
timer.
This causes b to escape from B.Loop, which is totally harmless because
it was already definitely heap-allocated. But it causes the
test/inline_testingbloop.go errorcheck test to fail. I don't think the
escape messages actually mattered to that test, they just had to be
matched. To fix this, we drop the debug level to -m=1, since -m=2
prints a lot of extra information for escaping parameters that we
don't want to deal with, and change one error check to allow b to
escape.
Fixes#72971.
Change-Id: I7d4abbb1ec1e096685514536f91ba0d581cca6b7
Reviewed-on: https://go-review.googlesource.com/c/go/+/659657
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>
Currently, if a benchmark function returns prior to B.Loop() returning
false, we'll report a bogus result. While there was no way to detect
this with b.N-style benchmarks, one way b.Loop()-style benchmarks are
more robust is that we *can* detect it.
This CL adds a flag to B that tracks if B.Loop() has finished and
checks it after the benchmark completes. If there was an early exit
(not caused by another error), it reports a B.Error.
Fixes#72933.
Updates #72971.
Change-Id: I731c1350e6df938c0ffa08fcedc11dc147e78854
Reviewed-on: https://go-review.googlesource.com/c/go/+/659656
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Austin Clements <austin@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
This CL changes the toolchain selection behavior for go install pkg@v
and go run pkg@v to also take into account the go and toolchain version
lines in the containing go.mod and go.work file.
Before this change, the go command would detect that go install
pkg@version or go run pkg@version was being run and skip the standard
behavior that would select the toolchain based on the go version in the
go.mod or go.work file. It would instead check the go line of the module
being downloaded and switch to that version if necessary.
With this change, the go command does not skip the standard behavior. It
proceeds to determine if an upgrade is required based on the containing
go.mod or go.work file's go and toolchain lines. Then, it checks the
module being installed to see if it would require a higher version than
the determined upgrade (or the local version if no upgrade was
determined). If it does require a higher version, then a switch happens
to that version, and if not the upgrade logic proceeds as usual doing
the upgrade if one was determined.
Fixes#66518
Change-Id: I00d96170e8713c451cc0fd2203be521585418842
Reviewed-on: https://go-review.googlesource.com/c/go/+/660035
Reviewed-by: Junyang Shao <shaojunyang@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently, b.Loop uses b.N as the iteration count target. However,
since it updates the target as it goes, the behavior is quite
different from a b.N-style benchmark. To avoid user confusion, this CL
gives b.Loop a separate, unexported iteration count target. It ensures
b.N is 0 within the b.Loop loop to help catch misuses, and commits the
final iteration count to b.N only once the loop is done (as the
documentation states "After Loop returns false, b.N contains the total
number of iterations that ran, so the benchmark may use b.N to compute
other average metrics.")
Since there are now two variables used by b.Loop, we put them in an
unnamed struct. Also, we rename b.loopN to b.loop.i because this
variable tracks the current iteration index (conventionally "i"), not
the target (conventionally "n").
Unfortunately, a simple renaming causes B.Loop to be too large for the
inliner. Thus, we make one simplification to B.Loop to keep it under
the threshold. We're about to lean into that simplification anyway in
a follow-up CL, so this is just temporary.
Prep for #72933 and #72971.
Change-Id: Ide1c4f1b9ca37f300f3beb0e60ba6202331b183e
Reviewed-on: https://go-review.googlesource.com/c/go/+/659655
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Auto-Submit: Austin Clements <austin@google.com>
Injecting a call to a thread context is complex enough to warrant
a dedicated function so that we don't repeat the same code in multiple
places. Note that the unix sigctxt struct also follows the
same approach.
The behavior is unchanged, but the implementation semantics are now
clearer by using goarch.StackAlign instead of a mix of goarch.PtrSize,
goarch.StackAlign and hardcoded values.
While here, fix#68552.
Cq-Include-Trybots: luci.golang.try:gotip-windows-arm64
Change-Id: Ic29cd2bf322b520127fecccafd61577076945758
Reviewed-on: https://go-review.googlesource.com/c/go/+/657815
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>
When an AfterFunc executes in a synctest bubble, there is a series of
happens-before relationships:
1. The AfterFunc is created.
2. The AfterFunc goroutine executes.
3. The AfterFunc goroutine returns.
4. A subsequent synctest.Wait call returns.
We were failing to correctly establish the happens-before relationship
between the AfterFunc goroutine and the AfterFunc itself being created.
When an AfterFunc executes, the G running the timer temporarily switches
to the timer heap's racectx. It then calls time.goFunc, which starts a
new goroutine to execute the timer. time.goFunc relies on the new goroutine
inheriting the racectx of the G running the timer.
Normal, non-synctest timers, execute with m.curg == nil, which causes
new goroutines to inherit the g0 racectx. We were running synctest
timers with m.curg set (to the G executing synctest.Run), so the new
AfterFunc goroutine was created using m.curg's racectx. This resulted
in us not properly establishing the happens-before relationship between
AfterFunc being called and the AfterFunc goroutine starting.
Fix this by setting m.curg to nil while executing timers.
As one additional fix, when waking a blocked bubble, wake the root
goroutine rather than a goroutine blocked in Wait if there is a
timer that can fire.
Fixes#72750
Change-Id: I2b2d6b0f17f64649409adc93c2603f720494af89
Reviewed-on: https://go-review.googlesource.com/c/go/+/658595
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>
Currently, if computing of the go cache directory fails it does not expose the error. Commands like go clean, exec, modindex that use go cache directory continue execution producing incorrect or no result. This patch adds an error to the return values such that it can be validated on call sites. It also introduces such validation in go clean -cache command to fail execution in case when error occurred.
Fixes#69997
Change-Id: I53fd1ec67f0a6bd8a367e785dcb145a673c084dc
GitHub-Last-Rev: e2063d10db
GitHub-Pull-Request: golang/go#70392
Reviewed-on: https://go-review.googlesource.com/c/go/+/628596
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Matloob <matloob@golang.org>
At first glance i have thought that we do not handle such case properly,
because parseBlockStmt and parseStmtList do not call call the
incNestLev. Fortunately parseStmt does, so it is detected properly.
As we don't have a test case directly for blockstmts only, i think it is
worth adding one.
Change-Id: If149b86fd90a7ee4a33c861070d1bafdd40e98ff
Reviewed-on: https://go-review.googlesource.com/c/go/+/659455
Reviewed-by: Roland Shoemaker <roland@golang.org>
Commit-Queue: 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>
Auto-Submit: Robert Griesemer <gri@google.com>
TestRace runs a collection of tests, some of which are expected
to fail with data races. Make TestRace more robust at detecting
when the test run is cut short, such as when a test causes
an unhandled panic.
Skip TestRaceRangeFuncIterator, which contains an unhandled panic.
This test was causing all subsequent tests to not run.
Skip TestNoRaceRangeFuncIterator, which contains an unexpected data race.
This test was not running due to the above failure.
For #72925
Change-Id: Id662375cc498ea25ae308619709768588bf6a2f0
Reviewed-on: https://go-review.googlesource.com/c/go/+/658875
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Damien Neil <dneil@google.com>
CL 637939 changed ReverseProxy to report errors encountered when
copying data on an hijacked connection. This is generally not useful,
and when using the default error handler results in WriteHeader
being called on a hijacked connection.
While this is harmless with standard net/http ResponseWriter
implementations, it can confuse middleware layers.
Fixes#72954
Change-Id: I21f3d3d515e114dc5c298d7dbc3796c505d3c82f
Reviewed-on: https://go-review.googlesource.com/c/go/+/659255
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Syntactically incorrect branches, such as
BEQ X5, X6, $1
BEQ X5, X6, 31(X10)
cause the assembler to panic, which they shouldn't really do. It's
better for the user to see a normal error, as reported for other
syntax errors in riscv64 assembly. The panics also prevent us
from writing negative tests for these sorts of errors.
Here we fix the issue by ensuring we generate a normal error instead
of panicking when the user provides an invalid branch target. We
also add a couple of negative tests.
Change-Id: I1da568999a75097484b61a01d418f5d4be3e04fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/637316
Reviewed-by: Cherry Mui <cherryyz@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: David Chase <drchase@google.com>
Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com>
The riscv64 Go assembler can output certain errors, ones produced by
instructionsForProg, multiple times. These errors are guaranteed to
be output at least twice and can appear three or more times if a
rescan is needed to recompute branch addresses. For example, the
syntactically incorrect instruction
MOV (X10), $1
will generate at least two identical errors
asm: 86076 (asm.s:21524) MOV (X10), $1: unsupported MOV
asm: 86076 (asm.s:21524) MOV (X10), $1: unsupported MOV
asm: assembly failed
In addition to confusing the user, these duplicate errors make it
difficult to write negative tests for certain types of instructions,
e.g., branches, whose duplicate errors are not always identical,
and so not ignored by endtoend_test.go.
We fix the issue by returning from preprocess if any errors have been
generated by the time we reach the end of the rescan loop. One
implication of this change is that validation errors will no longer
be reported if an error is generated earlier in the preprocess stage.
Negative test cases for validation errors are therefore moved to
their own file as the existing riscv64error.s file contains errors
generated by instructionsForProg that will now suppress the
validation errors.
Change-Id: Iffacdbefce28f44970dd5dda44990b822b8a23d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/637315
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Joel Sing <joel@sing.id.au>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This change adds extra logging in the case where there's an error
removing all the files in the gomodcache using modfetch.RemoveAll.
It logs the names of the files found in GOMODCACHE as well as their
modes. The modes are included because they should all be writable by the
time we call robustio.RemoveAll.
For #68087
Change-Id: Id9ae68bf6a3392baf88ec002d08fed1faf525927
Reviewed-on: https://go-review.googlesource.com/c/go/+/658816
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Matloob <matloob@golang.org>
Don't include a monotonic time in time.Times created inside
a bubble, to avoid the confusion of different Times using
different monotonic clock epochs.
For #67434
goos: darwin
goarch: arm64
pkg: time
cpu: Apple M1 Pro
│ /tmp/bench.0 │ /tmp/bench.1 │
│ sec/op │ sec/op vs base │
Since-10 18.42n ± 2% 18.68n ± 1% ~ (p=0.101 n=10)
Until-10 18.28n ± 2% 18.46n ± 2% +0.98% (p=0.009 n=10)
geomean 18.35n 18.57n +1.20%
Change-Id: Iaf1b80d0a4df52139c5b80d4bde4410ef8a49f2f
Reviewed-on: https://go-review.googlesource.com/c/go/+/657415
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Damien Neil <dneil@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Previously, the code only checked supportedVersions[0] for TLS 1.3
However, Chromium-based
browsers may list TLS 1.3 at different positions, causing ECH failures.
This fix:
Iterates through supportedVersions to accept connections as long as TLS 1.3 is present.
Improves ECH compatibility, ensuring Chrome, Edge, and other browsers work properly.
Fixes#71642
Change-Id: I32f4219fb6654d5cc22c7f33497c6142c0acb4f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/648015
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>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Go 1.24 included the spinbitmutex GOEXPERIMENT for several popular
architectures, based on their native support an atomic primitive (8-bit
exchange) that aided its efficient implementation.
Move towards making the new mutex implementation permanent, so it fully
replaces the two previous (sema- and futex-based "tristate")
implementations.
For #68578
Change-Id: I888a73959df42eb0ec53875309c446675af8f09d
Reviewed-on: https://go-review.googlesource.com/c/go/+/658455
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Rhys Hiltner <rhys.hiltner@gmail.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
On riscv64, subtraction from a constant is typically implemented as an
ADDI with the negative constant, followed by a negation. However this can
lead to multiple NEG/ADDI/NEG sequences that can be optimised out.
For example, runtime.(*_panic).nextDefer currently contains:
lbu t0, 0(t0)
addi t0, t0, -8
neg t0, t0
addi t0, t0, -7
neg t0, t0
Which is now optimised to:
lbu t0, 0(t0)
addi t0, t0, -1
Change-Id: Idf5815e6db2e3705cc4a4811ca9130a064ae3d80
Reviewed-on: https://go-review.googlesource.com/c/go/+/652318
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Mark Ryan <markdryan@rivosinc.com>
Reviewed-by: David Chase <drchase@google.com>
mp.isExtraInC is intended to indicate that this M has no Go frames at
all; it is entirely executing in C.
If there was a cgocallback to Go and then a cgocall to C, such that the
leaf frames are C, that is fine. e.g., traceback can handle this fine
with SetCgoTraceback (or by simply skipping the C frames).
However, we currently mismanage isExtraInC, unconditionally setting it
on return from cgocallback. This means that if there are two levels of
cgocallback, we end up running Go code with isExtraInC set.
1. C-created thread calls into Go function 1 (via cgocallback).
2. Go function 1 calls into C function 1 (via cgocall).
3. C function 1 calls into Go function 2 (via cgocallback).
4. Go function 2 returns back to C function 1 (returning via the remainder of cgocallback).
5. C function 1 returns back to Go function 1 (returning via the remainder of cgocall).
6. Go function 1 is now running with mp.isExtraInC == true.
The fix is simple; only set isExtraInC on return from cgocallback if
there are no more Go frames. There can't be more Go frames unless there
is an active cgocall out of the Go frames.
Fixes#72870.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest
Change-Id: I6a6a636c4e7ba75a29639d7036c5af3738033467
Reviewed-on: https://go-review.googlesource.com/c/go/+/658035
Reviewed-by: Cherry Mui <cherryyz@google.com>
Commit-Queue: Michael Pratt <mpratt@google.com>
Auto-Submit: 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>
For various cursed reasons we need to support the BMPString and
T61String ASN.1 string encodings. These types use the defunct UCS-2 and
T.61 character encodings respectively.
This change rejects some characters when decoding BMPStrings which are
not valid in UCS-2, and properly parses T61Strings instead of treating
them as plain UTF-8.
While still not perfect, this matches the behavior of most other
implementations, particularly BoringSSL. Ideally we'd just remove
support for these ASN.1 types (particularly in crypto/x509, where we
don't actually expose any API), but doing so is likely to break some
deploy certificates which unfortunately still use these types in DNs,
despite them being deprecated since 1999/2002.
Fixes#71862
Change-Id: Ib8f392656a35171e48eaf71a200be6d7605b2f02
Reviewed-on: https://go-review.googlesource.com/c/go/+/651275
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
In CL 475375 the Go command started to generate the "preferlinkext"
token file for "strange/dangerous" compiler flags. This serves as a hint
to the Go linker whether to call the external linker or not.
Permit compiler flag used by the hermetic_cc_toolchain bzlmod.
As a side effect, it also allows these flags to appear
in #cgo directives in source code. We don't know of any cases
where that is actually useful, but it appears to be harmless
and simplifies the implementation of the internal linking change.
Fixes#72842
Change-Id: Ic6de29b535a4e2c0720f383567ea6b3c7ca4f541
Reviewed-on: https://go-review.googlesource.com/c/go/+/657575
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
This required adding a new field to SessionState for TLS 1.0–1.2, since
the key exchange is not repeated on resumption. The additional field is
unfortunately not backwards compatible because current Go versions check
that the encoding has no extra data at the end, but will cause
cross-version tickets to be ignored. Relaxed that so we can add fields
in a backwards compatible way the next time.
For the cipher suite, we check that the session's is still acceptable
per the Config. That would arguably make sense here, too: if a Config
for example requires PQ, we should reject resumptions of connections
that didn't use PQ. However, that only applies to pre-TLS 1.3
connections, since in TLS 1.3 we always do a fresh key exchange on
resumption. Since PQ is the only main differentiator between key
exchanges (aside from off-by-default non-PFS RSA, which are controlled
by the cipher suite in TLS 1.0–1.2) and it's PQ-only, we can skip that
check.
Fixes#67516
Change-Id: I6a6a465681a6292edf66c7b8df8f4aba4171a76b
Reviewed-on: https://go-review.googlesource.com/c/go/+/653315
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
This patch extends the change in CL 657175 to apply the same abbrev
selection strategy to single-range lexical scopes that we're now using
for inlined routine bodies, when DWARF 5 is in effect. Ranges are more
compact and use fewer relocation than explicit hi/lo PC values, so we
might as well always use them.
Updates #26379.
Change-Id: Ieeaddf50e82acc4866010e29af32bcd1fb3b4f02
Reviewed-on: https://go-review.googlesource.com/c/go/+/657177
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Currently we check the size difference between non-PIE and PIE binaries
without specifying a linkmode (and that is presumed to be internal).
However, on some platforms (like openbsd/arm64), the use of
-buildmode=pie results in external linking. Ensure that we only test
internally linked non-PIE against internally linked PIE and externally
linked non-PIE against externally linked PIE, avoiding unexpected
differences.
Fixes#72818
Change-Id: I7e1da0976a4b5de387a59d0d6c04f58498a8eca0
Reviewed-on: https://go-review.googlesource.com/c/go/+/657035
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Than McIntosh <thanm@golang.org>
This PR adds an helper FileContentDisposition that builds multipart
Content-Disposition header contents with field name and file name,
escaping quotes and escape characters.
The function is then called in the related helper CreateFormFile.
The new function allows users to add other custom MIMEHeaders,
without having to rewrite the char escaping logic of field name and
file name, which is provided by the new helper.
Fixes#46771
Change-Id: Ifc82a79583feb6dd609ca1e6024e612fb58c05ce
GitHub-Last-Rev: 969f846fa9
GitHub-Pull-Request: golang/go#63324
Reviewed-on: https://go-review.googlesource.com/c/go/+/531995
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
The Go command had a behavior of writing its own toolchain name when
updating the go line in a go.mod (for example when a user runs go get
go@version). This behavior was often undesirable and the toolchain line
was often removed by users before checking in go.mod files (including in
the x/ repos). It also led to user confusion.
This change removes that behavior. A toolchain line will not be added if
one wasn't present before. The toolchain line can still be removed
though: the toolchain line must be at least the go version, so if the go
version is increased above the toolchain version, the toolchain version
will be bumped up to that go version. Then the toolchain line will then
be dropped because go <version> implies toolchain <version>.
Making this change slightly hurts reproducability because future go
commands run on the go.mod file may be run with a different toolchain
than the one that used it, but that doesn't seem to be worth the
confusion the behavior resulted in.
We expect this change will not have negative consequences, but it could
be possible, and we would like to hear from any users that depended on
the previous behavior in case we need to roll it back before the
release.
Fixes#65847
Change-Id: Id795b7f762e4f90ba0fa8c7935d03f32dfc8590e
Reviewed-on: https://go-review.googlesource.com/c/go/+/656835
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This patch changes the strategy we use in the compiler for handling
range information for inlined subroutine bodies, fixing a bug in how
this was handled for DWARF 5. The high and lo PC values being emitted
for DW_TAG_inlined_subroutine DIEs were incorrect, pointing to the
start of functions instead of the proper location. The fix in this
patch is to move to unconditionally using DW_AT_ranges for inlined
subroutines, even those with only a single range.
Background: prior to this point, if a given inlined function body had
a single contiguous range, we'd pick an abbrev entry for it with
explicit DW_AT_low_pc and DW_AT_high_pc attributes. If the extent of
the code for the inlined body was not contiguous (which can happen),
we'd select an abbrev that used a DW_AT_ranges attribute instead. This
strategy (preferring explicit hi/lo PC attrs for a single-range func)
made sense for DWARF 4, since in DWARF 4 the representation used in
the .debug_ranges section was especially heavyweight (lots of space,
lots of relocations), so having explicit hi/lo PC attrs was less
expensive.
With DWARF 5 range info is written to the .debug_rnglists section, and
the representation here is much more compact. Specifically, a single
hi/lo range can be represented using a base address in addrx format
(max of 4 bytes, but more likely 2 or 3) followed by start and
endpoints of the range in ULEB128 format. This combination is more
compact spacewise than the explicit hi/lo values, and has fewer
relocations (0 as opposed to 2).
Note: we should at some point consider applying this same strategy to
lexical scopes, since we can probably reap some of the same benefits
there as well.
Updates #26379.
Fixes#72821.
Change-Id: Ifb65ecc6221601bad2ca3939f9b69964c1fafc7c
Reviewed-on: https://go-review.googlesource.com/c/go/+/657175
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alessandro Arzilli <alessandro.arzilli@gmail.com>
Bump the required version of GDB up to 10 from 7.7 in the runtime GDB
tests, so as to ensure that we have something that can handle DWARF 5
when running tests. In theory there is some DWARF 5 support on the
version 9 release branch, but we get "Dwarf Error: DW_FORM_addrx"
errors for some archs on builders where GDB 9.2 is installed.
Updates #26379.
Change-Id: I1b7b45f8e4dd1fafccf22f2dda0124458ecf7cba
Reviewed-on: https://go-review.googlesource.com/c/go/+/656836
Auto-Submit: Ian Lance Taylor <iant@google.com>
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@google.com>
I've originally used |= and &= to setup assumptions exploitable by the
operation under test but theses have multiple issues making it poor
for this usecase:
- &= does not pass the minimum value as-is, rather always set it to 0
- |= rounds up the max value to a number of the same length with all ones set
- I've never implemented them to work with negative signed numbers
Change-Id: Ie43c576fb10393e69d6f989b048823daa02b1df8
Reviewed-on: https://go-review.googlesource.com/c/go/+/656160
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: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Jorropo <jorropo.pgm@gmail.com>
This patch enables the DWARF version 5 experiment by default for most
platforms that support DWARF. Note that MacOS is kept at version 4,
due to problems with CGO builds; the "dsymutil" tool from older
versions of Xcode (prior to V16) can't handle DWARF5. Similar we keep
DWARF 4 for GOOS=aix, where XCOFF doesn't appear to support the new
section subtypes in DWARF 5.
Updates #26379.
Change-Id: I5edd600c611f03ce8e11be3ca18c1e6686ac74ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/637895
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>
test/decoratemappingszero.go is intended to test that
//go:debug decoratemappings=0 disables annonations.
Unfortunately, //go:debug processing is handled by cmd/go, but
cmd/internal/testdir (which runs tests from test/) generally invokes the
compiler directly, thus it does not set default GODEBUGs.
Move this test to the cmd/go script tests, alongside the similar test
for language version.
Fixes#72772.
Cq-Include-Trybots: luci.golang.try:gotip-linux-ppc64le_power10
Change-Id: I6a6a636c9d380ef984f760be5689fdc7f5cb2aeb
Reviewed-on: https://go-review.googlesource.com/c/go/+/656795
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
We previously disallowed all non-regular files being embedded. This CL
relaxes the restriction a little: if the GODEBUG embedfollowsymlinks=1
is set, we allow the leaf files being embedded (not the directories
containing them) to be symlinks. The files pointed to by the symlinks
must still be regular files.
This will be used when a Bazel build action executing the Go command is
running in a symlink-based sandbox. It's not something we want to enable
in general for now, so it's behind a GODEBUG.
Fixes#59924
Change-Id: I895be14c12de55b7d1b663d81bdda1df37d54804
Reviewed-on: https://go-review.googlesource.com/c/go/+/643215
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Rather than relying on coreString, use the new commonUnder function
to determine the argument slice element types.
Factor out this functionality, which is shared for append and copy,
into a new helper function sliceElem (similar to chanElem).
Use sliceElem for both the append and copy implementation.
As a result, the error messages for invalid copy calls are
now more detailed.
While at it, handle the special cases for append and copy first
because they don't need the slice element computation.
Finally, share the same type recording code for the special and
general cases.
As an aside, in commonUnder, be clearer in the code that the
result is either a nil type and an error, or a non-nil type
and a nil error. This matches in style what we do in sliceElem.
Change-Id: I318bafc0d2d31df04f33b1b464ad50d581918671
Reviewed-on: https://go-review.googlesource.com/c/go/+/655675
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
If we weren't resuming an existing session, and we constructed a TLS 1.3
compatible client hello, ensure the server doesn't echo back the
made up compatibility session ID if we end up handshaking for TLS 1.2.
As part of an effort to make the initial stages of a TLS 1.3 handshake
compatible with TLS 1.2 middleboxes, TLS 1.3 requires that the client
hello contain a non-empty legacy_session_id value. For anti-ossification
purposes it's recommended this ID be randomly generated. This is the
strategy the crypto/tls package takes.
When we follow this approach, but then end up negotiating TLS 1.2, the
server should not have echoed back that random ID to us. It's impossible
for the server to have had a session with a matching ID and so it is
misbehaving and it's prudent for our side to abort the handshake.
See RFC 8446 Section 4.1.2 for more detail:
https://www.rfc-editor.org/rfc/rfc8446#section-4.1.2
Adopting this behaviour allows un-ignoring the BoGo
EchoTLS13CompatibilitySessionID testcase.
Updates #72006
Change-Id: I1e52075177a13a7aa103b45498eae38d8a4c34b9
Reviewed-on: https://go-review.googlesource.com/c/go/+/652997
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
For malformed client/server certificates in a TLS handshake send
a decode_error alert, matching BoringSSL behaviour.
Previously crypto/tls used a bad_certificate alert for this purpose.
The TLS specification is imprecise enough to allow this to be considered
a spec. justified choice, but since all other places in the protocol
encourage using decode_error for structurally malformed messages we may
as well do the same here and get some extra cross-impl consistency for
free.
This also allows un-ignoring the BoGo
GarbageCertificate-[Client|Server]-[TLS12|TLS13] tests.
Updates #72006
Change-Id: Ide45ba1602816e71c3289a60e77587266c3b9036
Reviewed-on: https://go-review.googlesource.com/c/go/+/652995
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Previously this test was skipped without a comment clarifying why. In
practice it's because crypto/tls doesn't generate GREASE extensions at
this time, and the test expects to find one in the NewSessionTicket
message extensions produced by a server.
We're already skipping some other GREASE related test as
not-yet-implemented without explicit bogo_config.json exclusion by way
of the -enable-grease flag not being implemented, however for TLS
1.3 servers the BoGo expectation is that they _always_ send GREASE, and
so the -enable-grease flag isn't provided and an explicit skip must be
used.
We should revisit this alongside implementing GREASE ext production in
general for both clients and servers.
Updates #72006
Change-Id: I8af4b555ac8c32cad42215fbf26aa0feae90fa21
Reviewed-on: https://go-review.googlesource.com/c/go/+/650717
Reviewed-by: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
When this command line flag is provided to the BoGo runner it will:
* Disable some timeouts
* Limit concurrency to 1 worker at a time
* Pass the -wait-for-debugger flag to the shim process
* Print the PID of the shim process to status output
On the shim-side, we need to react to -wait-for-debugger by sending
ourselves a SIGSTOP signal. When a debugger attaches to the shim the
process will be resumed.
This makes it possible to debug both the runner side and the shim side
of a BoGo interaction without resorting to print style debugging.
Since SIGSTOP is not a signal we can use on Windows this functionality
is limited to unix builds.
Updates #72006
Change-Id: Iafa08cf71830cdfde3e6ee4826914236e3cd7e57
Reviewed-on: https://go-review.googlesource.com/c/go/+/650737
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
When encountering alertUserCanceled in a TLS 1.3 handshake, ignore the
alert and retry reading a record. This matches existing logic for how
TLS 1.2 alertLevelWarning alerts are handled.
For broader context, TLS 1.3 removed warning-level alerts except for
alertUserCanceled (RFC 8446, § 6.1). Since at least one major
implementation (https://bugs.openjdk.org/browse/JDK-8323517)
misuses this alert, many TLS stacks now ignore it outright when seen in
a TLS 1.3 handshake (e.g. BoringSSL, NSS, Rustls).
With the crypto/tls behaviour changed to match peer implementations we
can now enable the "SendUserCanceledAlerts-TLS13" BoGo test.
"SendUserCanceledAlerts-TooMany-TLS13" remains ignored, because like
"SendWarningAlerts*" fixing the test requires some general spam
protocol message enhancements be done first.
Updates #72006
Change-Id: I570c1fa674b5a4760836c514d35ee17f746fe28d
Reviewed-on: https://go-review.googlesource.com/c/go/+/650716
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
This commit removes SkipNewSessionTicket from the bogo_config.json
excluded tests list.
Previously this test was being skipped with a TODO that there might be
a bug here. In practice it seems like there's no bug and the test is
handled correctly by crypto/tls.
When activated, a TLS 1.2 client connecting to the bogo dispatcher goes
through the normal handshake process with the exception that the server
skips sending the NewSessionTicket msg expected by the client in
response to the client's final flight of handshake msgs.
The crypto/tls TLS 1.2 client_handshake.go logic correctly rejects the
unexpected message that follows (ChangeCipherSpec) when trying to read
the bytes necessary to unmarshal the expected NewSessionTicket message
that was omitted.
Updates #72006
Change-Id: I9faea4d18589d10b163211aa17b2d0da8af1187e
Reviewed-on: https://go-review.googlesource.com/c/go/+/650736
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Auto-Submit: Daniel McCarney <daniel@binaryparadox.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
When clients use debug/dwarf to examine DWARF 5 binaries, we can run
into problems when the Seek() method is used to skip ahead from a DIE
in one compilation unit to a DIE in another unit. The problem here is
that it is common for DWARF 5 comp units to have attributes (ex:
DW_AT_addr_base) whose value must be applied as an offset when reading
certain forms (ex: DW_FORM_addrx) within that unit. The existing
implementation didn't have a good way to recover these attrs following
the Seek call, and had to essentially punt in this case, resulting in
incorrect attr values.
This patch adds new support for reading and caching the key comp unit
DIE attributes (DW_AT_addr_base, DW_AT_loclists_base, etc) prior to
visiting any of the DIE entries in a unit, storing the cache values of
these attrs the main table of units. This base attribute
reading/caching behavior also happens (where needed) after Seek calls.
Should resolve delve issue 3861.
Supercedes Go pull request 70400.
Updates #26379.
Fixes#57046.
Change-Id: I536a57e2ba4fc55132d91c7f36f67a91ac408dc3
Reviewed-on: https://go-review.googlesource.com/c/go/+/655976
Reviewed-by: Alessandro Arzilli <alessandro.arzilli@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This adds a new godebug to control whether the runtime applies the
anonymous memory mapping annotations added in https://go.dev/cl/646095.
It is enabled by default.
This has several effects:
* The feature is only enabled by default when the main go.mod has go >=
1.25.
* This feature can be disabled with GODEBUG=decoratemappings=0, or the
equivalents in go.mod or package main. See https://go.dev/doc/godebug.
* As an opaque setting, this option will not appear in runtime/metrics.
* This setting is non-atomic, so it cannot be changed after startup.
I am not 100% sure about my decision for the last two points.
I've made this an opaque setting because it affects every memory mapping
the runtime performs. Thus every mapping would report "non-default
behavior", which doesn't seem useful.
This setting could trivially be atomic and allow changes at run time,
but those changes would only affect future mappings. That seems
confusing and not helpful. On the other hand, going back to annotate or
unannotate every previous mapping when the setting changes is
unwarranted complexity.
For #71546.
Change-Id: I6a6a636c5ad551d76691cba2a6f668d5cff0e352
Reviewed-on: https://go-review.googlesource.com/c/go/+/655895
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
CL 637939 changed ReverseProxy's handling of hijacked connections:
After copying all data in one direction, it half-closes the outbound
connection rather than fully closing both.
Revert to the old behavior when the outbound connection does not support
CloseWrite, avoiding a case where one side of the proxied connection closes
but the other remains open.
Fixes#72140
Change-Id: Ic0cacaa6323290f89ba48fd6cae737e86045a435
Reviewed-on: https://go-review.googlesource.com/c/go/+/655595
Reviewed-by: Jonathan Amsterdam <jba@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Damien Neil <dneil@google.com>
Fix incorrect godoc links related to the use of the name "Reader" for
different things in the various compress/* packages:
- in compress/flate Reader is the interface describing the underlying reader,
not the decompressor as in other packages, so "returned reader" must
not be linked to Reader.
- in compress/lzw and compress/gzip Reader is the decompressor, not the
interface of the underlying reader, so "underlying reader" must not
be linked to Reader.
With this patch the formatting of "underlying reader" and "returned
reader" is consistent accross compress/* packages.
Change-Id: Iea315fd5ee5b6c177855693d68841f3709a382cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/655335
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Russ Cox noticed that reset was clearing limbs up to the *previous* Nat
size, not up to the new size, because clear(x.limbs) was happening
before the x.limbs[:n] reslice.
That's potentially a severe issue, because it may leave garbage in
x.limbs[len(x.limbs):n] if n < cap(x.limbs).
We were saved by an accidental invariant caused by the bug itself,
though: x.limbs[len(x.limbs):cap(x.limbs)] are always zero.
reset was always clearing all exposed (and hence potentially non-zero)
limbs before shrinking the Nat, and the only other function that could
shrink the Nat was trim, which only trims zero limbs.
Near miss.
Preserve the accidental invariant in the fix, because memclr is cheap
and it just proved it can save us from potential mistakes.
Change-Id: I6a6a4656a77735d8e8d520c699c4d85dd33ce497
Reviewed-on: https://go-review.googlesource.com/c/go/+/655056
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
If the error cause is not further specified (empty string),
avoid allocating a new errorCause. This makes using errorCauses
as boolean signals efficient.
While at it, fix an error message for incomparable arrays:
report the array type rather than its underlying type.
Change-Id: I844b18a76695330ca726932ee760aa89635f6a38
Reviewed-on: https://go-review.googlesource.com/c/go/+/654575
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Combine commonUnder and commonUnderOrChan:
- Provide an optional cond(ition) function argument to commonUnder
to establish additional type set conditions.
- Instead of a *Checker and *string argument for error reporting,
return an error cause that is only allocated in the presence of
an error.
- Streamline some error messages.
Replace all calls to coreType with calls to commonUnder.
Change-Id: I81ac86d0d532cddc09164309acced61d90718b44
Reviewed-on: https://go-review.googlesource.com/c/go/+/654455
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
This CL stores coverage profile data in the GOCACHE under the
'coverprofile' subkey alongside tests. This makes tests which use
coverage profiles cacheable. The values of the -coverprofile and
-outputdir flags are not included in the cache key to allow cached
profile data to be written to any output file.
Note: This is a rebase and squash from the original PRs below that
was created/closed/abandoned by @jproberts and @macnibblet that I
plan to maintain.
- https://github.com/golang/go/pull/50483
- https://github.com/golang/go/pull/65657
I made improvements to the change based on feedback from @bcmills in Gerrit
https://go-review.googlesource.com/c/go/+/563138.
From @macnibblet:
I don't know if anyone has considered the environmental impact
(Yes, of course, dev experience too), but on a team with 3 backend
developers, when I replaced our CI Golang version with this build,
it reduced the build time by 50%, which would have
equated to about 5000 hours of CI reduced in the past year.
Fixes#23565
Change-Id: I59a20af5ea156f990a17544cf06dc667ae7f8aa3
GitHub-Last-Rev: a5a1d1b9c8
GitHub-Pull-Request: golang/go#69339
Reviewed-on: https://go-review.googlesource.com/c/go/+/610564
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Than McIntosh <thanm@golang.org>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
The 'used' field on Var and PkgName is fundamentally an aspect of the
type checking pass: it records when objects are used, for the purposes
of reporting errors for unused variables or package names. While
expedient and performant, recording this information in the types.Object
instances themselves increases the memory footprint of type-checked
packages, and (as we saw in golang/go#71817) can lead to data races when
Objects are reused in follow-up type checking, such as is done with the
CheckExpr and Eval APIs.
Fix this by externalizing the 'used' information into two maps (one for
variables and one for packages) on the types.Checker, so that they are
garbage-collected after type checking, and cannot be a source of data
races.
Benchmarks showed essentially no change in performance.
Fixesgolang/go#71817
Change-Id: I40daeabe4ecaca3bcb494e2f1c62a04232098e49
Reviewed-on: https://go-review.googlesource.com/c/go/+/650796
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
cmd/go tests that run builds are generally skipped in short mode. This
change will adds skips for some tests that were running builds.
I found these by sorting tests by elapsed time and removing the top
tests that invoked go build. It's our practice to skip tests that run go
build without the -n flag (which prints but doesn't execute commands).
On my work laptop this reduces test run time from about 20 seconds to
about 16 seconds. On my linux workstation it reduces test run time from
about 10 seconds to about 5 seconds.
Change-Id: I18ffcc231df013cb6ac5f5eb3544bed28dadeda8
Reviewed-on: https://go-review.googlesource.com/c/go/+/653775
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This CL adds an enum type, VarKind, that discriminates among
the various kinds of Var, and adds setter/getter methods
for Var's kind field.
Beware: NewVar has a weaker postcondition: the Var objects it
returns are not completely initialized and require a call to
Var.SetKind. This should only affect importers.
No changes are needed to the export data, since the kind can
always be deduced from the context when decoding.
See CL 645656 for the corresponding x/tools changes.
+ test, relnote, API
Updates golang/go#70250
Change-Id: Icde86ad22a880cde6f50bc12bf38004a5c6a1025
Reviewed-on: https://go-review.googlesource.com/c/go/+/645115
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Findley <rfindley@google.com>
These methods were previously used by crypto/ecdsa, but now not even
ecdsa_legacy.go uses them. Neither were ever documented.
Inverse was available only on P256() and only on amd64 and arm64, so
hopefully no one used it. CombinedMult was always available on all
curves, so it's possible some application might have used it, but all
the samples on GitHub I can find copied the old crypto/ecdsa package,
which does a conditional interface upgrade with a fallback, so they
won't break.
Change-Id: I6a6a4656ee1ab98438ca0fb20bea53b229cd7e71
Reviewed-on: https://go-review.googlesource.com/c/go/+/640116
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
SP and HTAB are allowed after a = before the following CRLF.
RFC 2045 section 6.7 describes the ABNF for the quoted-printable encoding:
qp-line := *(qp-segment transport-padding CRLF)
qp-part transport-padding
qp-segment := qp-section *(SPACE / TAB) "="
transport-padding := *LWSP-char
; Composers MUST NOT generate
; non-zero length transport
; padding, but receivers MUST
; be able to handle padding
; added by message transports.
RFC 822 defines LWSP-char as:
LWSP-char = SPACE / HTAB
Dovecot's imaptest contains such a message in
src/tests/fetch-binary-mime-qp.mbox.
Fixes#70952
Change-Id: Ie05921088d7e4d6c92c4bf79b0f4a13586230753
GitHub-Last-Rev: e6e6eee8eb
GitHub-Pull-Request: golang/go#70951
Reviewed-on: https://go-review.googlesource.com/c/go/+/638276
Reviewed-by: Sean Liao <sean@liao.dev>
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Sean Liao <sean@liao.dev>
This CL propagates closing the write stream from either side of the
reverse proxy and ensures the proxy waits for both copy-to and the
copy-from the backend to complete.
The new unit test checks communication through the reverse proxy when
the backend or frontend closes either the read or write streams.
That closing the write stream is propagated through the proxy from
either the backend or the frontend. That closing the read stream is
not propagated through the proxy.
Fixes#35892
Change-Id: I83ce377df66a0f17b9ba2b53caf9e4991a95f6a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/637939
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Sean Liao <sean@liao.dev>
Auto-Submit: Sean Liao <sean@liao.dev>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Matej Kramny <matejkramny@gmail.com>
The root cause of issue #65802 is a small race condition that occurs between
two events:
1. During the HTTP server shutdown, a connection in an idle state is identified
and closed.
2. The connection, although idle, has just finished reading a complete request
before being closed and hasn't yet updated its state to active.
In this scenario, despite the connection being closed, the request continues to
be processed. This not only wastes server resources but also prevents the
client request from being retried.
Fixes#65802
Change-Id: Ic22abb4497be04f6c84dff059df00f2c319d8652
GitHub-Last-Rev: 426099a3e7
GitHub-Pull-Request: golang/go#65805
Reviewed-on: https://go-review.googlesource.com/c/go/+/565277
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Sean Liao <sean@liao.dev>
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Sean Liao <sean@liao.dev>
This patch updates the compiler to generate DWARF5-style location
lists (e.g. entries that feed into .debug_loclists) as opposed to
DWARF4-style location lists (which wind up in .debug_loc). The DWARF5
format is much more compact, and can make indirect references to text
addresses via the .debug_addr section for further space savings.
Updates #26379.
Change-Id: If2e6fce1136d9cba5125ea51a71419596d1d1691
Reviewed-on: https://go-review.googlesource.com/c/go/+/635836
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>
This patch updates the compiler to generate DWARF5-style range lists
(e.g. entries that feed into .debug_rnglists) as opposed to
DWARF4-style range lists (which wind up in .debug_ranges). The DWARF5
format is much more compact, and can make indirect references to text
address via the .debug_addr section for further space savings.
Updates #26379.
Change-Id: I273a6283484b7fe33d79d5412e31c5155b22a7c0
Reviewed-on: https://go-review.googlesource.com/c/go/+/635345
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>
CL 629195 strongly favor closure inlining, allowing closures to be
inlined more aggressively.
However, if the closure body contains a call to a function, which itself
is one of the call arguments, it causes the infinite inlining.
Fixing this by prevent this kind of functions from being inlinable.
Fixes#72063
Change-Id: I5fb5723a819b1e2c5aadb57c1023ec84ca9fa53c
Reviewed-on: https://go-review.googlesource.com/c/go/+/654195
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The implementatiom still calls coreType in places and refers to
"core types" in comments, but user-visible error messages don't
know about core types anymore.
This brings the user-visible part of the implementation in sync with
the spec which doesn't have the notion of core types anymore.
For #70128.
Change-Id: I14bc6767a83e8f54b10ebe99a7df0b98cd9fca87
Reviewed-on: https://go-review.googlesource.com/c/go/+/654395
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Griesemer <gri@google.com>
For now, use commonUnder (formerly called sharedUnder) and update
error messages and comments. We can provide better error messages
in individual cases eventually.
Kepp using coreType for make built-in for now because it must accept
different channel types with non-conflicting directions and identical
element types. Added extra test cases.
While at it, rename sharedUnder, sharedUnderOrChan to commonUnder
and commonUnderOrChan, respectively (per suggestion from rfindley).
For #70128.
Change-Id: I11f3d5ce858746574f4302271d8cb763c2cdcf98
Reviewed-on: https://go-review.googlesource.com/c/go/+/653139
Reviewed-by: Robert Findley <rfindley@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Div is way faster. We could actually test a lot more primes and still
gain performance despite the diminishing returns, but necessarily it
would have marginal impact overall.
fips140: off
goos: linux
goarch: amd64
pkg: crypto/rsa
cpu: AMD Ryzen 7 PRO 8700GE w/ Radeon 780M Graphics
│ e325b41ad1 │ 0f611af2e1 │
│ sec/op │ sec/op vs base │
GenerateKey/2048-16 124.19m ± 0% 39.93m ± 0% -67.85% (p=0.000 n=20)
Surprisingly, the performance gain is similar on ARM64, which doesn't
have intrinsified math.Div.
fips140: off
goos: darwin
goarch: arm64
pkg: crypto/rsa
cpu: Apple M2
│ e325b41ad1 │ 6276161a7f │
│ sec/op │ sec/op vs base │
GenerateKey/2048-8 136.49m ± 0% 47.97m ± 1% -64.86% (p=0.000 n=20)
Change-Id: I6a6a46560331198312bd09c1cbe4d2b3c370c552
Reviewed-on: https://go-review.googlesource.com/c/go/+/639955
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
CL 652276 reduced the m struct by 8 bytes, which has changed the
allocation class on 64 bit OpenBSD platforms. This results in build
failures due to:
M structure uses sizeclass 1792/0x700 bytes; incompatible with mutex flag mask 0x3ff
Add 128 bytes of padding when spinbitmutex is enabled on 64 bit
architectures, moving the size to the half point between the
1792 and 2048 allocation size.
Change-Id: I71623a1f75714543c302217e619d20cf0e717aeb
Reviewed-on: https://go-review.googlesource.com/c/go/+/653335
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>
Reviewed-by: Keith Randall <khr@golang.org>
The tool IDs can be calculated once and reused across multiple
threads. This is a small optimization that helps optimize system
resources.
On a normal Windows machine with 12 virtual CPUs, the time to build
a hello world program is reduced from over 1 second, with spikes of 2
seconds, to a consistent 0.7 seconds.
Updates #71981.
Change-Id: I85f4a19f8ad4230afa32213780c761b7eb22fa29
Reviewed-on: https://go-review.googlesource.com/c/go/+/653715
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
GetPackage is sometimes called with a modroot or pkgdir that ends with a
path separator, and sometimes without. Clean them before passing them to
openIndexPackage to deduplicate calls to mcache.Do and action entry
files.
This shouldn't affect #71698 but was discovered while debugging that
issue.
Change-Id: I6a7fa4de93f45801504abea11bd97f6c6577f296
Reviewed-on: https://go-review.googlesource.com/c/go/+/652435
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The __nl_symbol_ptr is not a common section name anymore. LLVM prefers
__got for GOT symbols in the __DATA_CONST segment.
Note that the Go linker used to place the GOT section in the __DATA
segment, but since CL 644055 we place it in the __DATA_CONST segment.
Updates #71416.
Cq-Include-Trybots: luci.golang.try:gotip-darwin-amd64-longtest
Change-Id: Icb776e19855eaabb4777a9b1eb433497842413b4
Reviewed-on: https://go-review.googlesource.com/c/go/+/652555
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>
This change tries increasing the timeout in
TestSpuriousWakeupsNeverHangSemasleep. I'm not entirely sure of the
mechanism, but GODEBUG=gcstoptheworld=2 and GODEBUG=gccheckmark=1 can
cause this test to fail at it's regular timeout. It does not seem to
indicate a deadlock, because bumping the timeout 10x make the problem
go away. I suspect the problem is due to the long STW times these two
modes can induce, plus the fact this test runs in parallel with others.
Let's just bump the timeout. The test is fundamentally sound, and it's
unclear to me how else to test for a deadlock here.
Fixes#71691.
Fixes#71548.
Change-Id: I649531eeec8a8408ba90823ce5223f3a17863124
Reviewed-on: https://go-review.googlesource.com/c/go/+/652756
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: Cherry Mui <cherryyz@google.com>
Unlike request headers, where we are allowed to leniently accept
a bare LF in place of a CRLF, chunked bodies must always use CRLF
line terminators. We were already enforcing this for chunk-data lines;
do so for chunk-size lines as well. Also reject bare CRs anywhere
other than as part of the CRLF terminator.
Fixes CVE-2025-22871
Fixes#71988
Change-Id: Ib0e21af5a8ba28c2a1ca52b72af8e2265ec79e4a
Reviewed-on: https://go-review.googlesource.com/c/go/+/652998
Reviewed-by: Jonathan Amsterdam <jba@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Add a few more test cases for scanning (integer conversion),
which were helpful in debugging some upcoming changes.
BenchmarkScan currently times converting the value 10**N
represented in base B back into []Word form.
When B = 10, the text is 1 followed by many zeros, which
could hit a "multiply by zero" special case when processing
many digit chunks, misrepresenting the actual time required
depending on whether that case is optimized.
Change the benchmark to use 9**N, which is about as big and
will not cause runs of zeros in any of the tested bases.
The benchmark comparison below is not showing faster code,
since of course the code is not changing at all here. Instead,
it is showing that the new benchmark work is roughly the same
size as the old benchmark work.
goos: darwin
goarch: arm64
pkg: math/big
cpu: Apple M3 Pro
│ old │ new │
│ sec/op │ sec/op vs base │
ScanPi-12 43.35µ ± 1% 43.59µ ± 1% ~ (p=0.069 n=15)
Scan/10/Base2-12 202.3n ± 2% 193.7n ± 1% -4.25% (p=0.000 n=15)
Scan/100/Base2-12 1.512µ ± 3% 1.447µ ± 1% -4.30% (p=0.000 n=15)
Scan/1000/Base2-12 15.06µ ± 2% 14.33µ ± 0% -4.83% (p=0.000 n=15)
Scan/10000/Base2-12 188.0µ ± 5% 177.3µ ± 1% -5.65% (p=0.000 n=15)
Scan/100000/Base2-12 5.814m ± 3% 5.382m ± 1% -7.43% (p=0.000 n=15)
Scan/10/Base8-12 78.57n ± 2% 75.02n ± 1% -4.52% (p=0.000 n=15)
Scan/100/Base8-12 548.2n ± 2% 526.8n ± 1% -3.90% (p=0.000 n=15)
Scan/1000/Base8-12 5.674µ ± 2% 5.421µ ± 0% -4.46% (p=0.000 n=15)
Scan/10000/Base8-12 94.42µ ± 1% 88.61µ ± 1% -6.15% (p=0.000 n=15)
Scan/100000/Base8-12 4.906m ± 2% 4.498m ± 3% -8.31% (p=0.000 n=15)
Scan/10/Base10-12 73.42n ± 1% 69.56n ± 0% -5.26% (p=0.000 n=15)
Scan/100/Base10-12 511.9n ± 1% 488.2n ± 0% -4.63% (p=0.000 n=15)
Scan/1000/Base10-12 5.254µ ± 2% 5.009µ ± 0% -4.66% (p=0.000 n=15)
Scan/10000/Base10-12 90.22µ ± 2% 84.52µ ± 0% -6.32% (p=0.000 n=15)
Scan/100000/Base10-12 4.842m ± 3% 4.471m ± 3% -7.65% (p=0.000 n=15)
Scan/10/Base16-12 62.28n ± 1% 58.70n ± 1% -5.75% (p=0.000 n=15)
Scan/100/Base16-12 398.6n ± 0% 377.9n ± 1% -5.19% (p=0.000 n=15)
Scan/1000/Base16-12 4.108µ ± 1% 3.782µ ± 0% -7.94% (p=0.000 n=15)
Scan/10000/Base16-12 83.78µ ± 2% 80.51µ ± 1% -3.90% (p=0.000 n=15)
Scan/100000/Base16-12 5.080m ± 3% 4.698m ± 3% -7.53% (p=0.000 n=15)
geomean 12.41µ 11.74µ -5.36%
Change-Id: If3ce290ecc7f38672f11b42fd811afb53dee665d
Reviewed-on: https://go-review.googlesource.com/c/go/+/650639
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Russ Cox <rsc@golang.org>
Implement vector unit stride, vector strided, vector indexed and
vector whole register load and store instructions.
The vector unit stride instructions take an optional vector mask
register, which if specified must be register V0. If only two
operands are given, the instruction is encoded as unmasked.
The vector strided and vector indexed instructions also take an
optional vector mask register, which if specified must be register
V0. If only three operands are given, the instruction is encoded as
unmasked.
Cq-Include-Trybots: luci.golang.try:gotip-linux-riscv64
Change-Id: I35e43bb8f1cf6ae8826fbeec384b95ac945da50f
Reviewed-on: https://go-review.googlesource.com/c/go/+/631937
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Mark Ryan <markdryan@rivosinc.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Pengcheng Wang <wangpengcheng.pp@bytedance.com>
CL 527935 optimized []byte(string1 + string2) to use runtime.concatbytes
to prevent concatenating of strings before converting to slices.
However, the optimization is implemented without allowing temporary
buffer for slice on stack, causing un-necessary allocations.
To fix this, optimize concatbytes to use temporary buffer if the result
string length fit to the buffer size.
Fixes#71943
Change-Id: I1d3c374cd46aad8f83a271b8a5ca79094f9fd8db
Reviewed-on: https://go-review.googlesource.com/c/go/+/652395
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
_beginthread is intended to be used together with the C runtime.
The cgo runtime doesn't use it, so better use CreateThread directly,
which is the Windows API for creating threads.
Cq-Include-Trybots: luci.golang.try:gotip-windows-amd64-longtest,gotip-windows-arm64
Change-Id: Ic6cf75f69f62a3babf5e74155da1aac70961886c
Reviewed-on: https://go-review.googlesource.com/c/go/+/651995
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The lifetime of the variables are identical; capture
them in a single struct to avoid individual allocations.
The inner closure can also avoid allocation by using the
capture of the outer closure.
Escape analysis for OnceValues:
/go/src/sync/oncefunc.go:74:29: moved to heap: sync.f
/go/src/sync/oncefunc.go:76:3: moved to heap: sync.once
/go/src/sync/oncefunc.go:77:3: moved to heap: sync.valid
/go/src/sync/oncefunc.go:78:3: moved to heap: sync.p
/go/src/sync/oncefunc.go:79:3: moved to heap: sync.r1
/go/src/sync/oncefunc.go:80:3: moved to heap: sync.r2
/go/src/sync/oncefunc.go:82:7: func literal escapes to heap
/go/src/sync/oncefunc.go:83:9: func literal does not escape
/go/src/sync/oncefunc.go:93:9: func literal escapes to heap
After provided changes:
/go/src/sync/oncefunc.go:86:2: moved to heap: sync.d
/go/src/sync/oncefunc.go:96:9: func literal escapes to heap
/go/src/sync/oncefunc.go:99:13: func literal does not escape
/go/src/sync/oncefunc.go:100:10: func literal does not escape
Change-Id: Ib06e650fd427b57e0bdbdf1fe759fe436104ff79
Reviewed-on: https://go-review.googlesource.com/c/go/+/601596
Auto-Submit: Austin Clements <austin@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Austin Clements <austin@google.com>
On Darwin, the .got section can be placed in a read-only segment. Only the dynamic linker should modify it at start-up time.
Other read-only sections, like .typelink and .itablink, are already placed in the __DATA_CONST segment. Do the same for the .got section.
Fixes#71416.
Cq-Include-Trybots: luci.golang.try:gotip-darwin-amd64-longtest
Change-Id: I9cd9c20da63b655fabb61d742feb086c3ef3bea7
Reviewed-on: https://go-review.googlesource.com/c/go/+/644055
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 CL removes the notion of core types from the spec.
Instead of referring to core types, each section that did
so before is reverted to approx. the pre-generics (1.17)
prose, and additional paragraphs cover the type parameter
cases as needed.
The hope is that this makes it easier to read the spec.
When type parameters are involved, the extra prose is
local to the language feature in question and thus more
readily available. When no type parameters are present,
readers do not have to concern themselves with core types.
In contrast to CL 621919, this change is not intended to
loosen the spec in any way and therefore does not change
the language (if the new prose implies otherwise, we will
correct it).
Except for adjustments to compiler error messages
(no mention of core types anymore), no other changes
to the compiler or tools are required.
Future CLs may selectively relax requirements on a language
construct by language construct basis; each such change can
be discussed and proposed independently.
For #70128.
Change-Id: I6ed879a472c615d7c8dbdc7b6bd7eef3d12eff7e
Reviewed-on: https://go-review.googlesource.com/c/go/+/645716
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
this removes the old conditional-on-register-value
handshake from the deferproc/deferprocstack logic.
The "line" for the recovery-exit frame itself (not the defers
that it runs) is the closing brace of the function.
Reduces code size slightly (e.g. go command is 0.2% smaller)
Sample output showing effect of this change, also what sort of
code it requires to observe the effect:
```
package main
import "os"
func main() {
g(len(os.Args) - 1) // stack[0]
}
var gi int
var pi *int = &gi
//go:noinline
func g(i int) {
switch i {
case 0:
defer func() {
println("g0", i)
q() // stack[2] if i == 0
}()
for j := *pi; j < 1; j++ {
defer func() {
println("recover0", recover().(string))
}()
}
default:
for j := *pi; j < 1; j++ {
defer func() {
println("g1", i)
q() // stack[2] if i == 1
}()
}
defer func() {
println("recover1", recover().(string))
}()
}
p()
} // stack[1] (deferreturn)
//go:noinline
func p() {
panic("p()")
}
//go:noinline
func q() {
panic("q()") // stack[3]
}
/* Sample output for "./foo foo":
recover1 p()
g1 1
panic: q()
goroutine 1 [running]:
main.q()
.../main.go:46 +0x2c
main.g.func3()
.../main.go:29 +0x48
main.g(0x1?)
.../main.go:37 +0x68
main.main()
.../main.go:6 +0x28
*/
```
Change-Id: Ie39ea62ecc244213500380ea06d44024cadc2317
Reviewed-on: https://go-review.googlesource.com/c/go/+/650795
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The extension-removing rules for ARM64 were moved to late lower in
CL 568616. This means that the late lower pass can now generate
MOVDreg, however the rules that potentially eliminate MOVDreg only
exist in the earlier pass. Fix this by duplicating the MOVDreg/NOVDnop
rules in late lower, such that we can potentially eliminate conversions.
Removes 400+ instructions from the Go binary on openbsd/arm64.
Change-Id: I14aad06b994c9179f3ecdda566629793ba167511
Reviewed-on: https://go-review.googlesource.com/c/go/+/651819
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
This patch rolls the main .debug_info DWARF section from version 4 to
version 5, and also introduces machinery in the Go compiler and linker
for taking advantage of the DWARF5 ".debug_addr" section for
subprogram DIE "high" and "low" PC attributes. All functionality is
gated by GOEXPERIMENT=dwarf5.
For the compiler portion of this patch, we add a new DIE attribute
form "DW_FORM_addrx", which accepts as an argument a function (text)
symbol. The dwarf "putattr" function is enhanced to handle this
format by invoking a new dwarf context method "AddIndirectTextRef".
Under the hood, this method invokes the Lsym method WriteDwTxtAddrx,
which emits a new objabi.R_DWTXTADDR_* relocation. The size of the
relocation is dependent on the number of functions in the package; we
pick a size that is just big enough for the largest func index.
In the linker portion of this patch, we now switch over to writing out
a version number of 5 (instead of 4) in the compile unit header (this
is required if we want to use addrx attributes). In the parallel portion
of DWARF gen, within each compilation unit we scan subprogram DIEs to
look for R_DWTXTADDR_* relocations, and when we find such a reloc,
we assign a slot in the .debug_addr section for the func targeted.
After the parallel portion is complete, we then walk through all of the
compilation units to assign a value to their DW_AT_addr_base attribute,
which points to the portion of the single .debug_addr section containing
the text addrs for that compilation unit.
Note that once this patch is in, programs built with GOEXPERIMENT=dwarf5
will have broken/damaged DWARF info; in particular, since we've changed
only the CU and subprogram DIEs and haven't incorported the other
changes mandated by DWARF5 (ex: .debug_ranges => .debug_rnglists)
a lot of the variable location info will be missing/incorrect. This
will obviously change in subsequent patches.
Note also that R_DWTXTADDR_* can't be used effectively for lexical
scope DIE hi/lo PC attrs, since there isn't a viable way to encode
"addrx + constant" in the attribute value (you would need a new entry
for each attr endpoint in .debug_addr, which would defeat the point).
Updates #26379.
Change-Id: I2dfc45c9a8333e7b2a58f8e3b88fc8701fefd006
Reviewed-on: https://go-review.googlesource.com/c/go/+/635337
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>
Add a new symbol type: SDWARFADDR. This kind of symbol stores content
to be added to the DWARF .debug_addr section (new with DWARF5). At the
moment these symbols are created only in the linker, but it's not hard to
imagine other implementations in which the compiler would create them,
so they are added to both the compiler and linker symbol kind space.
Updates #26379.
Change-Id: I4a82ead0d59fe6028abfd6d6e3fc3df2e28c0ef6
Reviewed-on: https://go-review.googlesource.com/c/go/+/634415
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Add a set of new relocations to be used when the compiler is writing
debug information using DWARF version 5. No changes in compiler or
linker functionality, this patch just adds the relocations themselves
and some helper functions; uses will appear in a later patch. These
relocations are generated by the compiler when writing a DWARF DIE
attribute of form DW_FORM_addrx, or when writing a .debug_addr index
reference in a SDWARFRANGE or SDWARFLOC section. The target symbol of
the relocation is a function (STEXT symbol); the linker resolves the
relocation by replacing the target of the reloc with an index of a
slot in the .debug_addr section (.debug_addr is new with DWARF5).
Updates #26379.
Change-Id: I43c587d25d0836972dac487d09c8924d77345f4e
Reviewed-on: https://go-review.googlesource.com/c/go/+/633880
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
This patch rolls out the necessary changes to migrate the DWARF line
table support in the compiler and linker to DWARF version 5, gated by
the "dwarf5" GOEXPERIMENT.
DWARF version 5 includes a number of changes to the line table,
notably a revamped prolog section and a change in the indexing system
used to refer to files and directories within the line table
program. Specifically, prior to DWARF 4 a compilation's directory
table was considered to have an implicit zero entry containing the
compilation directory of the translation unit (package), and the file
table was considered to have an implicit zero entry storing the
"primary source file" (stored in the compilation unit DIE name).
DWARF 5 does away with these implicity entries meaning that files and
dirs are now effectively a 0-based index.
Updates #26379.
Change-Id: I9b4f1be5415aacec1ba57366d60bd48819c56ea5
Reviewed-on: https://go-review.googlesource.com/c/go/+/633879
Reviewed-by: Alessandro Arzilli <alessandro.arzilli@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Similarly to CL 648035, SetBytes doesn't need to be constant time for
the uses we make of it in the standard library (ECDH and ECDSA public
keys), but it doesn't cost much to make it constant time for users of
the re-exported package, or even just to save the next person from
convincing themselves that it's ok for it not to be constant time.
Change-Id: I6a6a465622a0de08d9fc71db75c63185a82aa54a
Reviewed-on: https://go-review.googlesource.com/c/go/+/650579
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Currently method values aren't correctly handled in Seq because we call
canRangeFunc on the reciever type, not the method value type, when we're
handling a method value. reflect.Value.Type has the logic to obtain the
method value type from the Value.
This change slightly refactors reflect.Value.Type into a separate
function so we can obtain the correct type as an abi.Type and pass it
off to canRangeFunc (and canRangeFunc2).
Fixes#71874.
Change-Id: Ie62dfca2a84b8f2f816bb87ff1ed1a58a7bb8122
Reviewed-on: https://go-review.googlesource.com/c/go/+/651416
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>
As of CL 650835, the pidfd test child no longer sends SIGCHLD on exit.
Per clone(2), "If [the child termination] signal is specified as
anything other than SIGCHLD, then the parent process must specify the
__WALL or __WCLONE options when waiting for the child with wait(2)."
Align with this requirement.
For #71828.
Change-Id: I6a6a636c739e4a59abe1533fe429a433e8588939
Reviewed-on: https://go-review.googlesource.com/c/go/+/651415
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Overzealous security scanners don't like the Go 1.17 binary because they
think it has every 1.17 security vulnerability. base64-encode the binary
to hide from them.
I've also extended the instructions to make the binary easier to
reproduce.
Since we do the Go binary, we might as well do the C binary too, as it
apparently makes some virus scanners unhappy.
Fixes#71753.
For #71734.
For #71821.
Change-Id: I6a6a636cccbf5312522f52f27f74eded64048fb7
Reviewed-on: https://go-review.googlesource.com/c/go/+/651175
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
We used to generate register GC maps as an experimental approach
for asynchronous preemption, which later we chose not to take.
Most of the register GC map code are already removed. One
exception is that the ssa.Register type still contains a field
for the register map index. Remove it.
Change-Id: Ib177ebce9548aa5ffbcaedd4b507240ea7df8afe
Reviewed-on: https://go-review.googlesource.com/c/go/+/651076
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently Make panics when passed a linker-allocated object. This is
inconsistent with both runtime.AddCleanup and runtime.SetFinalizer. Not
panicking in this case is important so that all pointers can be treated
equally by these APIs. Libraries should not have to worry where a
pointer came from to still make weak pointers.
Supporting this behavior is a bit complex for weak pointers versus
finalizers and cleanups. For the latter two, it means a function is
never called, so we can just drop everything on the floor. For weak
pointers, we still need to produce pointers that compare as per the API.
To do this, copy the tiny lock-free trace map implementation and use it
to store weak handles for "immortal" objects. These paths in the
runtime should be rare, so it's OK if it's not incredibly fast, but we
should keep the memory footprint relatively low (at least not have it be
any worse than specials), so this change tweaks the map implementation a
little bit to ensure that's the case.
Fixes#71726.
Change-Id: I0c87c9d90656d81659ac8d70f511773d0093ce27
Reviewed-on: https://go-review.googlesource.com/c/go/+/649460
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>
While looking at the SSA of following code, i noticed
that these rules do not work properly, and the types
are loaded indirectly through an itab, instead of statically.
type M interface{ M() }
type A interface{ A() }
type Impl struct{}
func (*Impl) M() {}
func (*Impl) A() {}
func main() {
var a M = &Impl{}
a.(A).A()
}
Change-Id: Ia275993f81a2e7302102d4ff87ac28586023d13c
GitHub-Last-Rev: 4bfc901917
GitHub-Pull-Request: golang/go#71784
Reviewed-on: https://go-review.googlesource.com/c/go/+/649500
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@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 go command assumes that GOMODCACHE is immutable. As an example of
one place the assumption is made, the modindex won't stat the files in
GOMODCACHE when getting the cache key for the index entry and just uses
the path of the module in the modcache (basically the module's name and
version). Explicitly reject overlays affecting GOMODCACHE to avoid
surprising and incorrect behavior.
For #71783
For #71075
Change-Id: I21dd5d39d71037de473b09ac8482a1867864e11f
Reviewed-on: https://go-review.googlesource.com/c/go/+/650475
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
RtlIsDosDeviceName_U is specifically designed to detect Windows devices.
We were using GetFullPathName to do this, but it's not the right API
for the job, as it is slower and allocates more memory.
goos: windows
goarch: amd64
pkg: path/filepath
cpu: Intel(R) Core(TM) i7-10850H CPU @ 2.70GHz
│ old.txt │ new.txt │
│ sec/op │ sec/op vs base │
IsLocal-12 5.685µ ± 59% 1.853µ ± 12% -67.41% (p=0.000 n=10)
│ old.txt │ new.txt │
│ B/op │ B/op vs base │
IsLocal-12 496.00 ± 0% 48.00 ± 0% -90.32% (p=0.000 n=10)
│ old.txt │ new.txt │
│ allocs/op │ allocs/op vs base │
IsLocal-12 10.000 ± 0% 6.000 ± 0% -40.00% (p=0.000 n=10)
Change-Id: Ib40ad7a90ab93cf7051c8d6becbce4d287f10f4e
Reviewed-on: https://go-review.googlesource.com/c/go/+/650578
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
The existing code for recover from deferrangefunc was broken in
several ways.
1. the code following a deferrangefunc call did not check the return
value for an out-of-band value indicating "return now" (i.e., recover
was called)
2. the returned value was delivered using a bespoke ABI that happened
to match on register-ABI platforms, but not on older stack-based
ABI.
3. the returned value was the wrong width (1 word versus 2) and
type/value(integer 1, not a pointer to anything) for deferrangefunc's
any-typed return value (in practice, the OOB value check could catch
this, but still, it's sketchy).
This -- using the deferreturn lookup method already in place for
open-coded defers -- turned out to be a much-less-ugly way of
obtaining the desired transfer of control for recover().
TODO: we also could do this for regular defer, and delete some code.
Fixes#71675
Change-Id: If7d7ea789ad4320821aab3b443759a7d71647ff0
Reviewed-on: https://go-review.googlesource.com/c/go/+/650476
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
CL 630696 changes budget for once-called closures, making them more
inlinable. However, when recursive inlining involve both the closure and
its parent, the inliner goes into an infinite loop:
parent (a closure) -> closure -> parent -> ...
The problem here dues to the closure name mangling, causing the inlined
checking condition failed, since the closure name affects how the
linker symbol generated.
To fix this, just prevent the closure from inlining its parent into
itself, avoid the infinite inlining loop.
Fixes#71680
Change-Id: Ib27626d70f95e5f1c24a3eb1c8e6c3443b7d90c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/649656
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Currently, exported Go functions with no parameters generate C functions
with an empty parameter list. In C, a function with an empty parameter
list can accept any number of arguments, whereas a function with a single
void parameter explicitly declares that it takes no arguments.
To align the generated C functions with their Go prototypes, update the
code generation to explicitly include a void parameter for functions
with no parameters.
Fixes#68411
Change-Id: Iab9456aa0236200bf21d1181a2e18e82869df63f
GitHub-Last-Rev: 6ff21a98df
GitHub-Pull-Request: golang/go#70981
Reviewed-on: https://go-review.googlesource.com/c/go/+/638635
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Provides, on one line, an approximation of P scheduling throughput: how
many times execute() was called for a given P. Said another way: how
many RUNNABLE to RUNNING transitions have happened for this P.
This allows discerning whether a P actually did anything, and how it
compares to other periods of a processes operation.
This should be useful to analyze (kernel) scheduler hiccups.
Investigators will want to subtract the tick values from subsequent
schedtrace lines to get a rate of schedulings. I've opted to add a space
around the first and last element as well to make it more uniform to do
the proposed subtracting with tools like AWK.
Change-Id: I69d6dae1509ad285d43799f38bcaa3aa0fb2352e
Reviewed-on: https://go-review.googlesource.com/c/go/+/635636
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Nicolas Hillegeer <aktau@google.com>
In particular, we apply it only to functions where it is always
a code improvement to inline the call.
We also apply it to some constants.
In a few cases this may introduce a panic statement at the
caller, which is debatable, but making the potential for panic
evident is the purpose of the deprecation.
The gofix analyzer in gopls v0.18 will show a diagnostic for calls
to the annotated functions, and will offer to inline the call.
The new //go:fix annotation needs a special exemption in the
pragma check in the compiler.
Updates #32816
Change-Id: I43bf15648ac12251734109eb7102394f8a76d55e
Reviewed-on: https://go-review.googlesource.com/c/go/+/648995
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Commit-Queue: Alan Donovan <adonovan@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Use return with register for async preemption resumption on arm64.
This has the same behaviour as the current use of JMP, however
is permitted when Branch Target Identification is being enforced,
while a JMP with register is considered an indirect call and
requires a `BTI J` marker at the resumption address.
Updates #66054
Change-Id: I135ac577073467bedd9efd8df15b76c97dc08767
Reviewed-on: https://go-review.googlesource.com/c/go/+/646782
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Internally we only use SetCanonicalBytes as part of Ed25519
verification, where all inputs are public, so it doesn't need to be
constant time.
However, this code is replicated outside of the standard library. Even
there, an attack is not practical, so this should not be considered a
security vulnerability:
- For specific scalars, this only leaks at most four bits of
information, and always the same four bits (so it's not an adaptive
attack).
- For derived scalars, assuming they are valid and uniformly
distributed, the loop would return true on the first iteration with
probability (1 - 2⁻¹²⁷) due to the shape of the scalar field order.
Still, making it constant time is easy enough and saves the next person
from having to think about it.
This was previously reported by Yawning Angel, and then as part of a
security audit.
Change-Id: I6a6a46563c8abecb0b4a6f12033a71c4c4da6fa7
Reviewed-on: https://go-review.googlesource.com/c/go/+/648035
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>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
CL 648315 and CL 648195 fixed#71615 in the case where we fail to read
the next generation by emitting an extra sync event before returning an
error. But, it's possible we failed to even read the next spilled batch
when we read the first generation, and have been carrying the error from
trying to read a spilled batch since the last generation. In this case,
we don't emit a final sync event, meaning that there are still some
cases where #71615 happens.
This change emits the final sync event in this corner case. I believe
this is the final corner case. I could previously reproduce the issue
by running the test under stress2, but I can no longer reproduce any
failures after this change.
Fixes#71615, for real this time.
Change-Id: I10688a3c0e4b8327a95f31add365338c77c091ab
Reviewed-on: https://go-review.googlesource.com/c/go/+/649259
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>
Benchmarking key generation is a pain. The number of random candidates
explored before finding a prime varies greatly, and on top of that some
rejections happen in the trial divisions step and some in the
Miller-Rabin step.
However, we can calculate on average how many candidates we should
reject before finding a prime, and of those how many should be divisible
by small primes. (And even the number of multiplications in a
Miller-Rabin iteration.) The new checked in sequence of candidates is
normalized to represent the average case.
It doesn't normalize the runtime of GCD, but running the benchmark with
20 different randomly generated "average cases" produces very consistent
results, so it must not matter much.
goos: darwin
goarch: arm64
pkg: crypto/rsa
cpu: Apple M2
│ regen.txt │
│ sec/op │
GenerateKey/2048-8 136.4m ± 0%
Changed slightly the excess masking in keygen.go to make it easier to
feed fixed candidates. This might also make it easier to share test
vectors in the future.
Change-Id: I66696c693f35da7bda27db537aa3bf3b991e970e
Reviewed-on: https://go-review.googlesource.com/c/go/+/639335
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Implement vector configuration setting instructions (VSETVLI,
VSETIVLI, VSETL). These allow the vector length (vl) and vector
type (vtype) CSRs to be configured via a single instruction.
Unfortunately each instruction has its own dedicated encoding.
In the case of VSETVLI/VSETIVLI, the vector type is specified via
a series of special operands, which specify the selected element
width (E8, E16, E32, E64), the vector register group multiplier
(M1, M2, M4, M8, MF2, MF4, MF8), the vector tail policy (TU, TA)
and vector mask policy (MU, MA). Note that the order of these
special operands matches non-Go assemblers.
Partially based on work by Pengcheng Wang <wangpengcheng.pp@bytedance.com>.
Cq-Include-Trybots: luci.golang.try:gotip-linux-riscv64
Change-Id: I431f59c1e048a3e84754f0643a963da473a741fe
Reviewed-on: https://go-review.googlesource.com/c/go/+/631936
Reviewed-by: Mark Ryan <markdryan@rivosinc.com>
Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
This CL adds new relocation type for riscv64: R_GOT_PCREL_ITYPE_RELOC
which generate an AUIPC + I-type pair with relocation type of GOT_HI20
and PCREL_LO12_I.
According to RISCV elf psabi doc, medium position independent code
model, the GNU as example is:
```
# Calculate address of non-local symbol
.Ltmp3: aupipc a0, %got_pcrel_hi(symbol)
ld a0, %pcrel_lo(.Ltmp3)(a0)
```
Change-Id: I719dd05e009ca2d9291f0689b346c059f9c56918
Reviewed-on: https://go-review.googlesource.com/c/go/+/612635
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Particularly with 2-word load instructions, this becomes important.
Classic example is:
func f(p *string) string {
return *p
}
We want the two loads to put the return values directly into
the two ABI return registers.
At this point in the stack, cmd/go is 1.1% smaller.
Change-Id: I51fd1710238e81d15aab2bfb816d73c8e7c207b1
Reviewed-on: https://go-review.googlesource.com/c/go/+/631137
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>
If we call slicebytetostring immediately (with no intervening writes)
before calling map access or delete functions with the resulting
string as the key, then we can just use the ptr/len of the
slicebytetostring argument as the key. This avoids an allocation.
Fixes#44898
Update #71132
There's old code in cmd/compile/internal/walk/order.go that handles
some of these cases.
1. m[string(b)]
2. s := string(b); m[s]
3. m[[2]string{string(b1),string(b2)}]
The old code handled cases 1&3. The new code handles cases 1&2.
We'll leave the old code around to keep 3 working, although it seems
not terribly common.
Case 2 happens particularly after inlining, so it is pretty common.
Change-Id: I8913226ca79d2c65f4e2bd69a38ac8c976a57e43
Reviewed-on: https://go-review.googlesource.com/c/go/+/640656
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Fix TestACVP environment construction to include both ACVP_WRAPPER and
GODEBUG.
Previously we were accidentally overwriting the cmd.Env, stomping the
ACVP_WRAPPER env var and replacing it with just the GODEBUG env var.
This in turn makes the tests start to fail when the test binary
subprocess is invoked without knowing it's fulfilling the role of the
wrapper, and not the test driver.
Change-Id: Ie6ee30c8b93b2051a671e12aaa63d2116c5eb8c8
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/649016
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
If there's an error getting the version of the c compiler, add the error
to the input used to produce the cache key. In the case where we can't
parse the version, the text of the output of the command is part of the
error, so different unparseable versions will produce different cache
keys. Before, we wouldn't add anything to the key when there was an
error getting the version, so we wouldn't distinguish a missing compiler
from one where we couldn't parse the version.
Fixes#64589
Change-Id: I27f853e8ff40002e2f045b2210633b38f93d0130
Reviewed-on: https://go-review.googlesource.com/c/go/+/648196
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
The tree has opened for Go 1.25 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.
cat <<EOF | patch
diff --git a/src/cmd/vet/testdata/print/print.go b/src/cmd/vet/testdata/print/print.go
index a2ad0f1298..fffe571163 100644
--- a/src/cmd/vet/testdata/print/print.go
+++ b/src/cmd/vet/testdata/print/print.go
@@ -200,8 +200,8 @@ func PrintfTests() {
// Bad argument reorderings.
Printf("%[xd", 3) // ERROR "Printf format %\[xd is missing closing \]"
Printf("%[x]d x", 3) // ERROR "Printf format has invalid argument index \[x\]"
- Printf("%[3]*s x", "hi", 2) // ERROR "Printf format has invalid argument index \[3\]"
- _ = fmt.Sprintf("%[3]d x", 2) // ERROR "Sprintf format has invalid argument index \[3\]"
+ Printf("%[3]*s x", "hi", 2) // ERROR "Printf format %\[3\]\*s reads arg #3, but call has 2 args"
+ _ = fmt.Sprintf("%[3]d x", 2) // ERROR "Sprintf format %\[3\]d reads arg #3, but call has 1 arg"
Printf("%[2]*.[1]*[3]d x", 2, "hi", 4) // ERROR "Printf format %\[2]\*\.\[1\]\*\[3\]d uses non-int \x22hi\x22 as argument of \*"
Printf("%[0]s x", "arg1") // ERROR "Printf format has invalid argument index \[0\]"
Printf("%[0]d x", 1) // ERROR "Printf format has invalid argument index \[0\]"
EOF
# Temporarily hold x/net back to leave out CL 643780 because it's
# causing an import cycle in net/http's generated h2_bundle.go.
cd src
sed -i '' 's|"golang.org/x/net/internal/httpcommon"||' net/http/h2_bundle.go
go get golang.org/x/net@v0.34.1-0.20250123000230-c72e89d6a9e4 # version before CL 643780
go mod tidy
go mod vendor
go generate net/http
Change-Id: I91967ceb797bbc741af024cd2d2dba29dc558384
Reviewed-on: https://go-review.googlesource.com/c/go/+/648735
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>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
This change modifies this test (which involves an arbitrary timeout) to
be a little less flaky by double-checking that our subprocess program
completed even if the ticker fires and we've exceeded our timeout. The
logic behind this change is that the testing goroutine might get delayed
for any number of reasons, but the subprocess could still complete in
time. Still, the goroutine will wake up to handle the ticker and see its
over time, even though the event it was waiting for did actually happen.
I can't reproduce #71548 locally, so I suspect because this test calls
t.Parallel other load can delay the testing goroutine enough for this to
happen (especially with GODEBUG=gccheckmark=1, which pauses
everything to perform a full mark and sweep, and runtime tests love to
call runtime.GC).
For #71548.
Change-Id: I83e86a0115f65950886b57b5af0b4a517ef5f90f
Reviewed-on: https://go-review.googlesource.com/c/go/+/648576
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>
Commit-Queue: Michael Knyszek <mknyszek@google.com>
make.bat accepts the --dist-tool flag on multiple flag positions
and also allows omitting the trailing dash. Doing so adds complexity
and is not aligned with the make.bash and make.rc behavior. Remove that
flexibility to simplify the code and make it more consistent. This also
fixes a bug where dist.exe wouldn't be removed from cmd\dist when
running make.bat --dist-tool.
Also, there is no need for race.bat to invoke make.bat with --dist-tool.
It uses it to get the GOHOSTARCH env value, but we can already get
that from the built-in PROCESSOR_ARCHITECTURE env variable.
Change-Id: Ia673562c1ae6aff9bd3ec7aa8cdd25ff187eeb79
Reviewed-on: https://go-review.googlesource.com/c/go/+/648615
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>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Currently one of the reasons experimental events are tricky to use is
because:
- There's no way to take advantage of the existing infrastructure, like
strings and stacks, and
- There's no way to attach arbitrary data to an event (except through
strings, possibly).
Fix this by abstracting away the raw arguments in an ExperimentalEvent
and requiring access to the arguments via a new method, ArgValue. This
returns a Value, which gives us an opportunity to construct a typed
value for the raw argument dynamically, and a way to access existing
tables. The type of the argument is deduced from conventions for the
argument's name. This seems more than sufficient for experimental
events.
To make this work, we also need to add a "string" variant to the Value
type. This may be a little confusing since they're primarily used for
metrics, but one could imagine other scenarios in which this is useful,
such as including build information in the trace as a metric, so I think
this is fine.
This change also updates the Value API to accomodate a String method for
use with things that expect a fmt.Stringer, which means renaming the
value assertion methods to have a "To" prefix.
Change-Id: I43a2334f6cd306122c5b94641a6252ca4258b39f
Reviewed-on: https://go-review.googlesource.com/c/go/+/645135
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
parser.go is an old file that contains trace v1 definitions and a second
equivalent definition for stack frames. These are redundant and useless.
Delete these definitions and rename the file to fakep.go, which
describes the only thing left in this file, a bunch of fake P IDs used
by the trace viewer.
We should consider moving the fake P definitions elsewhere, too.
Change-Id: Ifd0768bd73c39009069445afe0155f1e352f00c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/644875
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>
This change moves maxArgs to tracev2 and renames it MaxTimedEventArgs.
It also updates the tests to make sure the specs conform to this
requirement.
Change-Id: I7b0c888a4dfd83306a470a4c9b0f9e44fe2e7818
Reviewed-on: https://go-review.googlesource.com/c/go/+/646016
TryBot-Bypass: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Adds ACVP test coverage for the SP 800-108r1 KDF feedback mode algorithm
based on the NIST spec:
https://pages.nist.gov/ACVP/draft-celi-acvp-kbkdf.html
The HKDF-based implementation in our FIPS module fixes some parameters,
requiring tailoring of the advertised capability to match. Notably:
* We only support fixedDataOrder "after fixed data"
* We only support a counter length of 8 bits
* We only support empty IVs
No acvp_test.config.json update accompanies this support because the
ACVP tests for this algorithm aren't amenable to fixed data testing.
Updates #69642
Change-Id: I729e899377a64d2b613d6435241aebabeef93bca
Reviewed-on: https://go-review.googlesource.com/c/go/+/640016
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: 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>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Adds ACVP test coverage for the SP 800-108r1 KDF counter mode algorithm
based on the NIST spec:
https://pages.nist.gov/ACVP/draft-celi-acvp-kbkdf.html
The implementation in our FIPS module fixes some parameters, requiring
tailoring of the advertised capability to match. Notably:
* We only support macModes CMAC-AES-128, -192, and -256
* We only support supportedLengths 256 (matching the [32]byte output
from CounterKDF.DeriveKey)
* We only support fixedDataOrder "before fixed data"
* We only support counterLength 16
No acvp_test.config.json update accompanies this support because the
ACVP tests for this algorithm aren't amenable to fixed data testing.
Updates #69642
Change-Id: I9e02d6c8cb6e209ac8e4c9fba926fffbad916098
Reviewed-on: https://go-review.googlesource.com/c/go/+/639776
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Adds ACVP test coverage for the SP 800-90A rev 1 ctrDRBG algorithm based
on the NIST spec:
https://pages.nist.gov/ACVP/draft-vassilev-acvp-drbg.html#section-7.2
The implementation in our FIPS module is a minimal implementation
tailored to the specific needs of stdlib crypto. As a result we
customize the ACVP capability registration so that:
* predResistanceEnabled is false
* only mode AES-256 is supported
* for that mode,
* derFuncEnabled is false
* persoStringLen is 0 to disable personalization
* additionalInputLen is 384 to match the [48]byte argument in our API
Other capability values are chosen based on Table 4's ctrDRBG AES-256
w/o `derFuncEnabled` row:
https://pages.nist.gov/ACVP/draft-vassilev-acvp-drbg.html#section-7.4
We do enable reseed in the capability, necessitating two acvptool
commands: one that expects only 6 args and doesn't reseed
("ctrDRBG/AES-256"), and one that expects 8 args and does
("ctrDRBG-reseed/AES-256").
Updates #69642
Change-Id: I0f01a2f9496f45b130ee7d10916708093236f473
Reviewed-on: https://go-review.googlesource.com/c/go/+/639795
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Since CL 644215 each Sync event now represents the coming generation,
with a final Sync event emitted even when there's nothing ahead. This
change however failed to emit a Sync event at the end of a completely
valid generation when the next generation was invalid, causing the
runtime test TestCrashWhileTracing to start failing.
Fix this by emitting a final Sync event even when the next generation is
broken. We hold onto the error in parsing the next generation and emit
it after that final Sync event.
(Should these "final" Sync events distinguish themselves in some way?)
Fixes#71615.
Change-Id: I1f8abee5abaa39e1219e6fa05e9f82f1478db4c9
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/648195
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
These two packages were historically separate in an attempt to provide a
unified description of trace v1 and trace v2 formats. In practice this
turned out to be pointless, since it made more sense to keep the trace
v1 parser in a self-contained bubble with a converter to v2. Future
trace wire format migrations should probably just follow the same
general strategy, if there's a substantial change. (Minor changes can be
handled more organically.)
Change-Id: Ic765df62065fe53cfae59b505297527c3fa42dfb
Reviewed-on: https://go-review.googlesource.com/c/go/+/645395
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>
Currently all v2 trace versions, Go 1.22 and Go 1.23, share a full set
of specs. This is mostly OK, but it means quite a few events will be
accepted for 1.22 traces that should be rejected. This change fixes that
by limiting which event specs are returned by version.Version.Specs for
Go 1.22.
While we're here, let's be stricter about event names too, and move
tracev2.EventString to be a method on the version, so we can be more
precise. An intended consequence of this move is that tracev2 no longer
depends on fmt, since we will want the runtime to depend on tracev2 in
the near future.
Change-Id: If7285460c8ba59ab73da00993b7b12e61cdfe6a9
Reviewed-on: https://go-review.googlesource.com/c/go/+/644219
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 follows up from the previous one which renamed oldtrace to
tracev1, defining everything Go 1.22+ as trace v2.
This change also re-maps some packages in preparation for sharing with
other parts of the standard library, like the runtime. It also cleans up
some other uses of 'go122' that are just a bit misleading. The mappings
are as follows:
- internal/trace/event -> internal/trace/tracev2/event
- internal/trace/event/go122 -> internal/trace/tracev2
- internal/trace/internal/testgen/go122 ->
internal/trace/internal/testgen
The CL updates all import paths and runs gofmt -w -s on the entire
subdirectory.
Change-Id: I35476c679a96d4eafad6b94bac5f88aa7b085d2f
Reviewed-on: https://go-review.googlesource.com/c/go/+/644218
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>
Currently Root embeds a root and calls SetFinalizer on &r.root. This
sets the finalizer on the outer root, which is visible to users of
os.Root, and thus they can mutate the finalizer attached to it.
This change modifies Root to not embed its inner root, but rather to
refer to it by pointer. This allows us to set the finalizer on this
independent inner object, preventing users of os.Root from changing the
finalizer. This follows the same pattern as os.File's finalizer.
Fixes#71617.
Change-Id: Ibd199bab1b3c877d5e12ef380fd4647b4e10221f
Reviewed-on: https://go-review.googlesource.com/c/go/+/647876
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This is part of a refactoring to better distinguish trace wire format
versions. Even though details may change between Go versions and they
might be backwards-incompatible, the trace format still broadly has two
wire formats: v1 and v2.
A follow-up change will rename go122 to v2 to make this more consistent.
Change-Id: If4fe1c82d8aeabc8baa05f525e08a9e7d469a5c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/644217
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>
This change modifies how per-generation experimental batches are
exposed. Rather than expose them on the ExperimentalEvent, it exposes it
as part of the Sync event, so it's clear to the caller when the
information becomes relevant and when it should be parsed.
This change also adds a field to each ExperimentalEvent indicating which
experiment the event is a part of.
Because this information needs to appear *before* a generation is
observed, we now ensure there is a sync event both before and after each
generation. This means the final sync event is now a special case;
previously we would only emit a sync event after each generation.
This change is based on feedback from Austin Clements on the
experimental events functionality.
For #62627.
Change-Id: I48b0fe12b22abb7ac8820a9e73447bfed8419856
Reviewed-on: https://go-review.googlesource.com/c/go/+/644215
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>
nolocal is (almost) no longer needed after CL 647115. If we remove it,
then we can pass through all arguments to the Go command, which is
useful for running tests with additional flags, like -json or -v.
This CL also updates all.bat to use "go tool dist" instead of
"%GOTOOLDIR%/dist", as %GOTOOLDIR% is no longer set after making
make.bat uncoditionally set nolocal.
Change-Id: I97dc687faa5686d023f7d7d2b96637295995fe67
Reviewed-on: https://go-review.googlesource.com/c/go/+/647117
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
"if errorlevel 1" is and old construct that returns true if the
errorlevel is greater than or equal to 1. There are better alternatives
since Windows NT. For example, the || operator runs the RHS operand if
the preceding command failed, determined by checking that the errorlevel
is different from 0. This approach is more robust -it also works with
negative errorlevels- and is less verbose.
Change-Id: I2070d654d8f9dd41a6cd586ba5ad5f4fea0638ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/647136
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>
Adds ACVP test coverage for deterministic ECDSA based on the NIST spec:
https://pages.nist.gov/ACVP/draft-fussell-acvp-ecdsa.html
Notably there is no corresponding acvp_test.config.json update in this
commit because ACVP DetECDSA only specifies sigGen mode.
The ACVP ECDSA sigGen tests are not amenable to testing against
static data because the test vectors don't provide a key pair to use for
the signature, just the message. The module wrapper has to generate its
own keypair and return the public key components with the signature.
DetECDSA produces deterministic signatures only when signing the same
message with the same key.
Change-Id: I9921f52e943c96b32e02e79cb5556ba0fabeae17
Reviewed-on: https://go-review.googlesource.com/c/go/+/635341
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
%GOBUILDEXIT% is used to avoid closing the terminal window when the
build or the tests fail on a dev machine. It is only set in CI to get
a non-zero exit code in case of failure.
%GOBUILDFAIL% is used to pass the exit code from a child batch file to
the parent batch file. It is set to 1 in the child batch file if the
build or the tests fail.
These two variables add complexity to the batch files and impose some
limitations on how they are implemented. For example, the child files
can't use setlocal, as it would make the parent file unable to read the
%GOBUILDFAIL% variable.
This CL removes these two variables and replaces them with unconditional
calls to "exit /b 1" in case of failure, which is more idiomatic and
composable. The trick is that the "/b" parameter makes the exit only
apply to the current batch file, not the entire shell session (unless
the bat file is the root, in which case the parameter is ignored), so
the parent batch file can continue executing, potentially checking the
errorlevel of the child batch file (which we always set to 1).
Change-Id: Ib053fb181ab14d58679551e03485700de77878d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/647115
Auto-Submit: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
The existing implementation would either fail or bind to the wrong interface
when the requested interface had no IPv4 address, such as when the Ethernet cable
was unplugged.
Now on Linux, it will always bind to the requested interface.
On other operating systems, it will consistently fail if the requested interface
has no IPv4 address.
Fixes#70132
Change-Id: I22ec7f9d4adaa4b5afb21fc448050fb4219cacee
Reviewed-on: https://go-review.googlesource.com/c/go/+/644375
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Commit-Queue: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
It appears to be quite easy to end up with a broken 'bzr' installation.
For example, if bzr was installed via a system-wide package manager and
intends to work with a system-wide Python installation, it may break if
another 'python3' binary is added to PATH.
If something as simple as 'bzr help' fails to exit with zero code,
consider it broken and skip tests that require a working bzr binary
just like if the 'bzr' binary isn't present in PATH at all.
This makes these tests more robust and capable of producing useful
signal in more environments. Separately from this, we'll want to
restore a working bzr installation on the linux-arm64 builders, but
at least there's still one on linux-amd64 builders.
For #71563.
Fixes#71504.
Change-Id: Ia147196f12b90a0731ebbfab63b5de308212ed65
Cq-Include-Trybots: luci.golang.try:gotip-linux-arm64-longtest,gotip-linux-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/646715
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Add a RISCV64 variable to cpu/internal that indicates both the presence
of RISC-V extensions and performance information about the underlying
RISC-V cores. The variable is only populated with non false values on
Linux. The detection code relies on the riscv_hwprobe syscall
introduced in Linux 6.4. The patch can detect RVV 1.0 and whether
the CPU supports fast misaligned accesses. It can only detect RVV 1.0
on a 6.5 kernel or later (without backports).
Updates #61416
Change-Id: I2d8289345c885b699afff441d417cae38f6bdc54
Reviewed-on: https://go-review.googlesource.com/c/go/+/522995
Reviewed-by: Joel Sing <joel@sing.id.au>
Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: David Chase <drchase@google.com>
This change ensures that dirinfo in the File struct is initialized atomically,
avoiding redundant allocations when multiple goroutines access it concurrently.
Instead of creating separate buffers, we now use CompareAndSwap to guarantee
thread-safe initialization and reduce unnecessary memory usage.
Although this is not a strict race condition, the update enhances efficiency by
eliminating duplicate allocations and ensuring safer concurrent access.
Fixes#71496.
Change-Id: If08699a94afa05611cdf67e82a5957a8d8f9d5c8
GitHub-Last-Rev: 1e1f619143
GitHub-Pull-Request: golang/go#71501
Reviewed-on: https://go-review.googlesource.com/c/go/+/645720
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
The linux-arm64 trybots are consistently failing with
vcstest_test.go:155: 2025/01/30 21:50:41 hello.txt:
> handle bzr
> env BZR_EMAIL='Russ Cox <rsc@google.com>'
> env EMAIL='Russ Cox <rsc@google.com>'
> bzr init-repo .
[stderr]
brz: ERROR: Couldn't import breezy and dependencies.
Please check the directory containing breezy is on your PYTHONPATH.
Error: PyErr { type: <class 'ModuleNotFoundError'>, value: ModuleNotFoundError("No module named 'breezy'"), traceback: None }
vcstest_test.go:161: hello.txt:6: bzr init-repo .: exit status 1
This seems to be a problem with the builder.
For now, skip the test if we see that error message, just as we already
skip the test if the bzr executable is not found.
For #71504
Change-Id: If8b6d4dea02dc16198ba6067595dff3340a81299
Reviewed-on: https://go-review.googlesource.com/c/go/+/646635
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Check correct use of ...'s in parameter lists in parsers.
This allows the type checkers to assume correct ASTs with
respect to ... use.
Adjust some error messages: if a ... is used in a result
parameter list, the error is now more accurate.
Eliminate a now unused error code.
Change-Id: I66058e114e84805e24c59e570604b607ef5ff1fe
Reviewed-on: https://go-review.googlesource.com/c/go/+/631135
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Refactor parser.parseParameters to only parse
ordinary parameters. Introduce a variant to
parse type parameters.
In the two places where we need ordinary and type
parameters, call the function twice.
Also, use a range loop in two places which is a
bit easier to read.
Change-Id: I0a62e1c508d6ccd16b7cb6e1b852ab1d32224ec2
Reviewed-on: https://go-review.googlesource.com/c/go/+/630816
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Commit-Queue: Robert Griesemer <gri@google.com>
For some reason the ESTALE error message differed on Linux systems.
On Linux strerror normally returns "Stale file handle" for ESTALE,
except possibly in the en_GB locale. The mkerrors.sh script sets
LC_ALL=C, so it should always produces "stale file handle".
However, for some reason, several targets use "stale NFS file handle"
instead.
Clean this up so that we use the same string on all Linux systems.
This is also consistent with golang.org/x/sys/unix.
Fixes#71309
Change-Id: Ic2ffaf114c85112bc6d0831e43dd5fd2f4237bc2
Reviewed-on: https://go-review.googlesource.com/c/go/+/643335
Auto-Submit: Ian Lance Taylor <iant@google.com>
Commit-Queue: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
This is a simple move of the contents of the vendored x/net/route
to internal/routebsd. I've also added some test files that
were not previously vendored.
This next CL will simplify the new internal/routebsd, removing the
code that is not needed by the new package.
This is a step toward simplifying the x/net/route package by
permitting it to import x/sys/unix.
Change-Id: I4d13df11fa9738cd68876b2ea456d03f82d8d64a
Reviewed-on: https://go-review.googlesource.com/c/go/+/637695
Commit-Queue: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Commit-Queue: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
The coverageredesign experiment was turned on by default by
CL 436236 in September, 2022. We've documented it and people
are using it. This CL removes the ability to turn off the experiment.
This removes some old code that is no longer being executed.
For #51430
Change-Id: I88d4998c8b5ea98eef8145d7ca6ebd96f64fbc2b
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-darwin-amd64-longtest,gotip-linux-arm64-longtest,gotip-windows-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/644997
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Than McIntosh <thanm@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Commit-Queue: Ian Lance Taylor <iant@google.com>
After using strings.FieldsFuncSeq, the number of memory allocations has been reduced from 2 to 0.
The following is the complete benchamark code and results:
package main
import (
"strings"
"testing"
)
func isSlashRune(r rune) bool { return r == '/' || r == '\\' }
func containsDotDotLoop(v string) bool {
if !strings.Contains(v, "..") {
return false
}
for _, ent := range strings.FieldsFunc(v, isSlashRune) {
if ent == ".." {
return true
}
}
return false
}
func containsDotDotSeq(v string) bool {
if !strings.Contains(v, "..") {
return false
}
for ent := range strings.FieldsFuncSeq(v, isSlashRune) {
if ent == ".." {
return true
}
}
return false
}
func BenchmarkDotDot(b *testing.B) {
testCases := []string{
"/path/to/somewhere",
"/path/../to/somewhere",
"/really/long/path/with/many/segments",
"../../../deep/path",
}
b.Run("Loop", func(b *testing.B) {
for i := 0; i < b.N; i++ {
for _, tc := range testCases {
containsDotDotLoop(tc)
}
}
})
b.Run("Seq", func(b *testing.B) {
for i := 0; i < b.N; i++ {
for _, tc := range testCases {
containsDotDotSeq(tc)
}
}
})
}
go test -bench=. -benchmem
goos: darwin
goarch: arm64
pkg: bc
cpu: Apple M1
BenchmarkDotDot/Loop-8 6133270 193.7 ns/op 144 B/op 2 allocs/op
BenchmarkDotDot/Seq-8 23172360 51.19 ns/op 0 B/op 0 allocs/op
PASS
ok bc 2.633s
Change-Id: I529c296e701b22710e21b53877aa798799980a3b
Reviewed-on: https://go-review.googlesource.com/c/go/+/639536
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Previously, the implementation used bit manipulation to approximate
counters to the nearest power of two.
Given the 0-255 range of byte, we can precompute values at
initialization and use a lookup table, reducing runtime computation.
Benchmarks show an 18% performance gain on AMD64 and 5% on ARM64.
* net/netip/FuzzParse (n=10, t=60s, state reset per run)
* AMD64 (Intel Alder Lake i5-12600k):
17,349,217 -> 20,487,756 execs/s
* ARM64 (M3 Pro):
19,606,471 -> 20,657,041 execs/s
* compress/gzip/FuzzReader (n=10, t=60s, mature corpus)
* AMD64 (Intel Alder Lake i5-12600k):
5,655,956 -> 6,707,035 execs/s
Change-Id: If11f7fe866f54c7cd2c5a48e251c027b67980df7
Reviewed-on: https://go-review.googlesource.com/c/go/+/627378
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Auto-Submit: Roland Shoemaker <roland@golang.org>
Added implementations for *io/fs.subFS, os.DirFS, and testing/fstest.MapFS.
Amended testing/fstest.TestFS to check behavior.
Addressed TODOs in archive/tar and os.CopyFS around symbolic links.
I am deliberately not changing archive/zip in this CL,
since it currently does not resolve symlinks
as part of its filesystem implementation.
I am unsure of the compatibility restrictions on doing so,
so figured it would be better to address independently.
testing/fstest.MapFS now includes resolution of symlinks,
with MapFile.Data storing the symlink data.
The behavior change there seemed less intrusive,
especially given its intended usage in tests,
and it is especially helpful in testing the io/fs function implementations.
Fixes#49580
Change-Id: I58ec6915e8cc97341cdbfd9c24c67d1b60139447
Reviewed-on: https://go-review.googlesource.com/c/go/+/385534
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Funda Secgin <fundasecgin33@gmail.com>
Methods declared in an interface have a signature and FuncType in the
AST, but they do not express a syntactic function type expression.
Treat them like ordinary function/method declarations and do not record
them in the Info.Types map. This removes an inconsistency in the way
function types are recorded.
Follow-up on CL 640776.
For #70908.
Change-Id: I60848f209b40b008039c014fb8b7b279361487b9
Reviewed-on: https://go-review.googlesource.com/c/go/+/640596
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: Alan Donovan <adonovan@google.com>
This change fixes GODEBUG=gccheckmark=1 which seems to have bit-rotted.
Because the root jobs weren't being reset, it wasn't doing anything.
Then, it turned out that checkmark mode would queue up noscan objects in
workbufs, which caused it to fail. Then it turned out checkmark mode was
broken with user arenas, since their heap arenas are not registered
anywhere. Then, it turned out that checkmark mode could just not run
properly if the goroutine's preemption flag was set (since
sched.gcwaiting is true during the STW). And lastly, it turned out that
async preemption could cause erroneous checkmark failures.
This change fixes all these issues and adds a simple smoke test to dist
to run the runtime tests under gccheckmark, which exercises all of these
issues.
Fixes#69074.
Fixes#69377.
Fixes#69376.
Change-Id: Iaa0bb7b9e63ed4ba34d222b47510d6292ce168bc
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/608915
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Enable the cmd/go fips test now that v1.0.0.zip has been checked in.
Will still need to enable the alias half when the alias is checked in.
Also fix a problem that was causing spurious failures, by fixing
repeated unpackings and also disabling modindex reads of the
virtual fips140 snapshot directories.
Fixes#71491.
Change-Id: I7fa21e9bde07ff4eb6c3483e99d49316ee0ea7f0
Reviewed-on: https://go-review.googlesource.com/c/go/+/645835
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
In ProcessCoverTestDir pass the selected set of packages to
EmitTextual in addition to EmitPercent, so that when we have runs with
multiple packages selected but without -coverpkg, text format output
for package P was incorrectly including output for P's covered
dependencies. This is in effect an extension of the fix for issue
65570.
Includes a cmd/go script test to verify correct behavior; ideally it
would be nice to locate this test in .../internal/coverage somewhere
but at the moment script tests are only supported for
cmd/{go,compile,link}.
Updates #65570.
Fixes#70244.
Change-Id: Ia0bb10155353aa0f2ead46e81a2aaa71bde4ef82
Reviewed-on: https://go-review.googlesource.com/c/go/+/627316
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Than McIntosh <thanm@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This CL reintroduces the various mapiter* linkname functions with a
compatibility layer that is careful to maintain compatibility with users
of the linkname.
The wrappers are straightforward. Callers of these APIs get an extra
layer of indirection, with their hiter containing a pointer to the real
maps.Iter. These users will take a minor performance hit from the extra
allocation, but this approach should have good long-term
maintainability.
Fixes#71408.
Change-Id: I6a6a636c7574bbd670ff5243dfeb63dfba6dc611
Reviewed-on: https://go-review.googlesource.com/c/go/+/643899
Auto-Submit: Michael Pratt <mpratt@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>
mapiterinit allows external linkname. These users must allocate their
own iter struct for initialization by mapiterinit. Since the type is
unexported, they also must define the struct themselves. As a result,
they of course define the struct matching the old hiter definition (in
map_noswiss.go).
The old definition is smaller on 32-bit platforms. On those platforms,
mapiternext will clobber memory outside of the caller's allocation.
On all platforms, the pointer layout between the old hiter and new
maps.Iter does not match. Thus the GC may miss pointers and free
reachable objects early, or it may see non-pointers that look like heap
pointers and throw due to invalid references to free objects.
To avoid these issues, we must keep mapiterinit and mapiternext with the
old hiter definition. The most straightforward way to do this is to use
mapiterinit and mapiternext as a compatibility layer between the old and
new iter types.
The first step to that is to move normal map use off of these functions,
which is what this CL does.
Introduce new mapIterStart and mapIterNext functions that replace the
former functions everywhere in the toolchain. These have the same
behavior as the old functions.
This CL temporarily makes the old functions throw to ensure we don't
have hidden dependencies on them. We cannot remove them entirely because
GOEXPERIMENT=noswissmap still uses the old names, and internal/goobj
requires all builtins to exist regardless of GOEXPERIMENT. The next CL
will introduce the compatibility layer.
I want to avoid using linkname between runtime and reflect, as that
would also allow external linknames. So mapIterStart and mapIterNext are
duplicated in reflect, which can be done trivially, as it imports
internal/runtime/maps.
For #71408.
Change-Id: I6a6a636c6d4bd1392618c67ca648d3f061afe669
Reviewed-on: https://go-review.googlesource.com/c/go/+/643898
Auto-Submit: Michael Pratt <mpratt@google.com>
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>
The TestRootConcurrentClose test can fail when GOARCH=WASM because of
goroutine starvation. The spawned goroutine will sometimes run in a
loop and never have the main goroutine be scheduled. This causes the
test to fail due to a timeout. This change forces the goroutine to be
scheduled with each iteration of the loop when GOARCH=WASM.
For #71134Fixes#71117
Change-Id: I4fb68907c9ac3b33bd0572d5e5db2974a3379191
Reviewed-on: https://go-review.googlesource.com/c/go/+/640195
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: Carlos Amedee <carlos@golang.org>
Pull in x/net CL 642606 and CL 643256 and regenerate h2_bundle.go:
http2: disable extended CONNECT by default
http2: encode :protocol pseudo-header before regular headers
For #36905.
Fixes#70728.
Fixes#71128.
[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.24-vendor
Change-Id: Id853cb96f8fc410956666f5c3ab4c5889c703503
Reviewed-on: https://go-review.googlesource.com/c/go/+/642398
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>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
If a wasmexport function is called from the host before
initializing the Go Wasm module, currently it will likely fail
with a bounds error, because the uninitialized SP is 0, and any
SP decrement will make it out of bounds.
As at least some Wasm runtime doesn't call _initialize by default,
This error can be common. And the bounds error looks confusing to
the users. Therefore, we detect this case and emit a clearer error.
Fixes#71240.
Updates #65199.
Change-Id: I107095f08c76cdceb7781ab0304218eab7029ab6
Reviewed-on: https://go-review.googlesource.com/c/go/+/643115
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Newer git versions (at least git 2.47.1) do not send all the matching tags
for a shallow fetch of a specific hash anymore. The go command assumes
that git servers do this. Since that assumption is broken, use the local
copy of the remote refs list to augment the tags sent by the server.
This makes the cmd/go/internal/modfetch tests pass again with newer git.
Fixes#71261.
Change-Id: I9fd4f3fd7beeb68a522938599f8f3acd887d0b26
Reviewed-on: https://go-review.googlesource.com/c/go/+/642437
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Russ Cox <rsc@golang.org>
https://ci.chromium.org/ui/inv/build-8725798219051312433/test-results?sortby=&groupby=
shows a mysterious failure with this stack:
=== RUN BenchmarkAll
BenchmarkAll
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x7c497f]
goroutine 20 gp=0xc000004000 m=7 mp=0xc000182808 [running]:
panic({0x81c5e0?, 0xabc6b0?})
/home/swarming/.swarming/w/ir/x/w/goroot/src/runtime/panic.go:806 +0x168 fp=0xc00c7ffce0 sp=0xc00c7ffc30 pc=0x4ad4c8
runtime.panicmem(...)
/home/swarming/.swarming/w/ir/x/w/goroot/src/runtime/panic.go:262
runtime.sigpanic()
/home/swarming/.swarming/w/ir/x/w/goroot/src/runtime/signal_unix.go:925 +0x359 fp=0xc00c7ffd40 sp=0xc00c7ffce0 pc=0x4af6d9
cmd/api.(*Walker).export(0xc000034100, 0x0)
/home/swarming/.swarming/w/ir/x/w/goroot/src/cmd/api/main_test.go:193 +0x3f fp=0xc00c7ffe08 sp=0xc00c7ffd40 pc=0x7c497f
cmd/api.BenchmarkAll(0xc000214288)
/home/swarming/.swarming/w/ir/x/w/goroot/src/cmd/api/api_test.go:205 +0x207 fp=0xc00c7ffeb0 sp=0xc00c7ffe08 pc=0x7c1c07
testing.(*B).runN(0xc000214288, 0x1)
/home/swarming/.swarming/w/ir/x/w/goroot/src/testing/benchmark.go:202 +0x291 fp=0xc00c7fff78 sp=0xc00c7ffeb0 pc=0x57e611
testing.(*B).run1.func1()
/home/swarming/.swarming/w/ir/x/w/goroot/src/testing/benchmark.go:224 +0x7c fp=0xc00c7fffe0 sp=0xc00c7fff78 pc=0x57f11c
runtime.goexit({})
/home/swarming/.swarming/w/ir/x/w/goroot/src/runtime/asm_amd64.s:1700 +0x1 fp=0xc00c7fffe8 sp=0xc00c7fffe0 pc=0x4b4a61
created by testing.(*B).run1 in goroutine 1
/home/swarming/.swarming/w/ir/x/w/goroot/src/testing/benchmark.go:217 +0x173
So import_ must have returned an error, making pkg nil. Show that error.
Also do the same at the other calls to import_.
Change-Id: Ie782571c4bda3334a86b303f61969cf1cc7d3c32
Reviewed-on: https://go-review.googlesource.com/c/go/+/642438
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
This case recently started happening on the builders.
The synctest experiment was recently enabled for some targets (CL 642422).
This caused the list of standard packages to include testing/synctest.
However, BenchmarkAll tests for all configurations;
some did not include testing/synctest. That caused the test to crash.
Change-Id: Icade10af147c2e2bcbac25bf744919083db3e70f
Reviewed-on: https://go-review.googlesource.com/c/go/+/642397
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
The existing code assumed the type argument count check in
Checker.instance couldn't fail for generic alias types
(matching the code for generic signatures), but it actually
can.
Adjust the code accordingly and document that the result of
Checker.instance may be invalid.
Review all call sites of Checker.instance and make sure we
handle the failure case, or document the code accordingly
(in the case of generic signatures).
When reporting an type argument count error, use the alias
name rather than the alias string representation to match
the error we get for a non-alias type.
While at it, update the manual.go template for ease of use.
Fixes#71198.
Change-Id: I6d19ec6418440e9b49574a2d7dd9825e0af6c2fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/641857
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Even if an error occurs during unmarshal, check the resulting Go value.
The documented API specifies no guarantees on how much of a Go value
will be populated when an error occurs and the "json" package
is technically not bounded by the Go compatibility agreement
to ensure this behavior never changes.
However, there is still value in running checks for
what exactly what is partially mutated in the event of an error
even if this is not guaranteed behavior.
Change-Id: I6e923a31f77768a14c4adfb0d37dbeee5807a4a2
Reviewed-on: https://go-review.googlesource.com/c/go/+/642275
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>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Adds ACVP test coverage for the hmacDRBG algorithm based on the NIST
spec:
https://pages.nist.gov/ACVP/draft-vassilev-acvp-drbg.html#section-7.2
The HMAC DRBG algorithm in our fips module is a minimal implementation
tailored for use for generating ECDSA nonces and so lives in
crypto/internal/fips140/ecdsa.
In order to be testable by crypto/internal/fips140test this changeset
exports a ecdsa.TestingOnlyNewDrbg() constructor to support the ACVP use-case.
All FIPS-compatible SHA2 and SHA3 digests are tested.
The ACVP capability registration is customized to match the limited
capabilities of our ecdsa-focused impl. Most notably:
* reseedImplemented is false - we expect this impl to be invoked
only once or twice per instantiation and do not support explicit
reseeding.
* predResistanceEnabled is false - this requires reseeding.
* Per mode:
* derFuncEnabled is always false - this is only used by ctrDRBG.
* additionalInputLen is 0 for all modes - this is only used with
preResistanceEnabled.
The other capability values are chosen based on Table 4:
https://pages.nist.gov/ACVP/draft-vassilev-acvp-drbg.html#section-7.4
Updates #69642
Change-Id: Ia58979d691f912e2ed739a05efb719f580fbbf89
Reviewed-on: https://go-review.googlesource.com/c/go/+/639775
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Adds ACVP test coverage for ML-KEM based on the NIST spec:
https://pages.nist.gov/ACVP/draft-celi-acvp-ml-kem.html
Notably we need to update the BoringSSL module version because the
acvptool was only recently updated to support testing ML-KEM.
A few non-test updates are also required for the
crypto/internal/fips140/mlkem package:
* For keyGen tests a new ExpandedBytes768() function is added that
converts a DecapsualtionKey768 struct into the expanded NIST
serialization. The existing Bytes() function returns the
key's seed, while ACVP testing requires the more cumbersome format.
* For decap tests a new TestingOnlyNewDecapsulationKey768()
constructor is added to produce a DecapsulationKey768 struct from the
expanded FIPS 203 serialization provided by the ACVP test vector. The
pre-existing NewDecapsulationKey768() function expects a seed as
input.
The generate1024.go helper is updated to translate the above changes to
the generated mlkem1024.go implementation.
Both of these new functions are exclusively for ACVP usage and so not
present in the public mlkem API. End users should always prefer to work
with seeds.
Updates #69642
Change-Id: I79784f8a8db00a2ddefdcece4b8de50b033c8f69
Reviewed-on: https://go-review.googlesource.com/c/go/+/637439
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: 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>
Heap profiles hide "runtime" frames like runtime.mapassign. This broke
in 1.24 because the map implementation moved to internal/runtime/maps,
and runtime/pprof only considered literal "runtime." when looking for
runtime frames.
It would be nice to use cmd/internal/objabi.PkgSpecial to find runtime
packages, but that is hidden away in cmd.
Fixes#71174.
Change-Id: I6a6a636cb42aa17539e47da16854bd3fd8cb1bfe
Reviewed-on: https://go-review.googlesource.com/c/go/+/641775
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>
The Mmap function returns a Data struct containing a slice with the
mapped contents of the file. Before this change, on Windows, the slice
contained the contents of all the pages of the mapping, including past
the end of the file. Re-slice the slice to the length of the file (if
if the slice is longer) so that the slice contains only the data in the
file.
For #71059
Change-Id: I389b752505b6fa1252b5c6d836a37bc7e662a45d
Reviewed-on: https://go-review.googlesource.com/c/go/+/640155
Reviewed-by: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Both fips140only and the service indicator checks in
crypto/internal/fips140/... expect to type assert to
crypto/internal/fips140/{sha256,sha512,sha3}.Digest.
However, crypto/sha3 returns a wrapper concrete type around sha3.Digest.
Add a new fips140hash.Unwrap function to turn the wrapper into the
underlying sha3.Digest, and use it consistently before calling into
fips140only or the FIPS 140-3 module.
In crypto/rsa, also made the fips140only checks apply consistently after
the Go+BoringCrypto shims, so we can instantiate the hash, and avoid
having to wrap the New function. Note that fips140=only is incompatible
with Go+BoringCrypto.
Fixes#70879
Change-Id: I6a6a4656ec55c3e13f6cbfadb9cf89c0f9183bdc
Reviewed-on: https://go-review.googlesource.com/c/go/+/640855
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The constants appeared badly ordered and grouped in the godoc before
const (
CiphertextSize1024 = 1568
EncapsulationKeySize1024 = 1568
)
const (
SharedKeySize = 32
SeedSize = 64
CiphertextSize768 = 1088
EncapsulationKeySize768 = 1184
)
while now they are a single group with the good size first
const (
SharedKeySize = 32
SeedSize = 64
CiphertextSize768 = 1088
EncapsulationKeySize768 = 1184
CiphertextSize1024 = 1568
EncapsulationKeySize1024 = 1568
)
No code changes.
Change-Id: I6a6a4656961b1e8c8bca3992aafa33e0575af8a2
Reviewed-on: https://go-review.googlesource.com/c/go/+/640997
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Having a global lock on the random state (used only in FIPS-140 mode)
introduces contention in concurrent programs. Use an approximately
per-P random state instead, using sync.Pool to manage per-P state.
This code is important to land for the Go 1.24 release because it is
part of the FIPS-140 module that will be validated and certified,
so it will live for a long time. We otherwise wouldn't be able to
correct this contention for at least a year, perhaps more.
At the same time, the code is only used in the FIPS-140 mode,
so there is no risk to normal programs.
Fixes#71155.
Change-Id: I6b779f15ddfdf232f608f5cda08f75906e58114f
Reviewed-on: https://go-review.googlesource.com/c/go/+/641097
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The backslashes on the windows paths will be escaped, so when checking
for them in the regular expression we'd have to have quadruple
backslashes '\\\\'. Since it's difficult to escape $GOCACHEPROG properly
for both json and regexp, just check for a string that ends in
cacheprog$GOEXE. We already check that the proper value is reported in
go env and go env -changed, and the json test case is mostly useful to
verify that GOCACHEPROG shows up in the json output.
For #71059
Change-Id: I52d49de61f2309a139f84c4d232b4cd94546ec8c
Cq-Include-Trybots: luci.golang.try:gotip-windows-amd64-longtest,gotip-linux-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/641375
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Currently injectglist emits all the trace events before actually calling
casgstatus on each goroutine. This is a problem, since tracing can
observe an inconsistent state (gstatus does not match tracer's 'emitted
an event' state).
This change fixes the problem by having injectglist do what every other
scheduler function does, and that's wrap each call to casgstatus in
traceAcquire/traceRelease.
Fixes#70883.
Change-Id: I857e96cec01688013597e8efc0c4c3d0b72d3a70
Reviewed-on: https://go-review.googlesource.com/c/go/+/638558
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
On Windows, we can't open a file that's already been opened. Before this
change, we'd try to write an index entry if mmapping the entry failed.
But that could happen either if the file doesn't exist or if there was a
problem mmapping an already opened file. Pass through information about
whether the file was actually opened so that we don't try to write to an
already opened file.
For #71059
Change-Id: I6adabe1093fed9ec37e7fafb13384c102786cbce
Reviewed-on: https://go-review.googlesource.com/c/go/+/640577
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
These break if the tools are run with GODEBUG=fips140=only,
which happens if someone sets that during 'go test' (and a test
binary must be built).
The easiest fix is to make the tools compatible with this GODEBUG
by just using sha256 as the underlying hash always. Just in case,
I made the wrappers select different sections of the hash, but
none of the call sites really care.
This CL is for the Go 1.24 release, but a follow-up during the Go 1.25
dev cycle could change all the usage sites to only use Sum32/New32.
For #70514Fixes#70878
Change-Id: Id5fea779c83df51d1680dbe561e0949c56e8d1e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/641096
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Allow a gocacheprog to not respond to close. The intention of the code
is that after we send the close message we'd ignore errors reading from
the cacheprog's stdout. But before this change if a cacheprog
did not respond to close and we got an EOF reading from the cacheprog's
stdout we'd just ignore all pending requests. The send operation would
then block forever waiting for a response. With this change, we close
all response channels for pending responses if there's an error reading
from the cacheprog's stdout while we're closing. The receives from the
response channels would then proceed (but now have to handle a nil
value). Then the send operation would return and the (*ProgCache).Close
function can proceed.
Fixes#70848
Change-Id: I6631d317ba7aea3f25f714f31cd2aeef0f4d4e3e
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/640516
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Function types for function (and method) declarations do not
appear in Info.Types maps, only Info.Defs maps, because the
function type is implicit in the declaration and not a proper
(function) type expression. This is true even though the AST
represents these types via an (artificial) FuncType node.
Document this explicitly in the API.
No functional code changes.
Fixes#70908.
Change-Id: I2aa897daed04e7ad0fa8b625d9adc7b423c57387
Reviewed-on: https://go-review.googlesource.com/c/go/+/640776
Reviewed-by: Alan Donovan <adonovan@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
disasm_riscv64 currently always returns an instruction length of four,
which is not correct if compressed instructions are in use. Return the
length of the decoded instruction, defaulting to two bytes if the
instruction is unknown.
With this change it is possible to correctly objdump a binary that is
written in C and includes compressed instructions:
$ go tool objdump ./hello
TEXT _start(SB)
:0 0x5b0 ef002002 CALL 8(PC)
:0 0x5b4 aa87 ADD X10, X0, X15
:0 0x5b6 17250000 AUIPC $2, X10
:0 0x5ba 033525a3 MOV -1486(X10), X10
:0 0x5be 8265 MOV (X2), X11
:0 0x5c0 3000 ADDI $8, X2, X12
...
Fixes#71102
Change-Id: Ia99eb114a98c6d535de872ce8a526cd5e6203fff
Reviewed-on: https://go-review.googlesource.com/c/go/+/639995
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Jorropo <jorropo.pgm@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
This has no practical advantage, and requires extra variable time code,
but is an explicit FIPS 186-5 requirement.
Note that the new behavior is consistent with Go+BoringCrypto, but not
with Go 1.23. The resulting keys are essentially interchangeable, but
it's not impossible for applications to notice (google/go-tpm#383).
gcd_lcm_tests.txt is from BoringSSL.
Change-Id: I6a6a4656fd5e92912c87bedc667456d0e8787023
Reviewed-on: https://go-review.googlesource.com/c/go/+/639936
Reviewed-by: Russ Cox <rsc@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>
This test checks a use-case of sync.Map that's expected to be more
common in Go 1.24 and beyond, as a concurrent weak cache.
The test will also fail if CompareAndSwap is not properly atomic with
CompareAndDelete, which is what #70970 is actually about. We should have
more explicit tests checking mutual atomicity of operations, but
for now this is OK, and still useful.
For #70970.
Change-Id: I6db508660691586a8af9ad511c9a96432d333343
Reviewed-on: https://go-review.googlesource.com/c/go/+/640737
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
In documentation, we've usually but not always referred to a
context with a closed Done channel as "done" rather than
"canceled", to avoid ambiguity between a context canceled
by calling a CancelFunc and one past its deadline.
This actually adds ambiguity, however, since it's common to
see references to a "canceled context" that are intended to
cover contexts past their deadline. If you see "function F
returns if its context is canceled", you can reasonably
assume that F will return if its context passes its
deadline, unless something says otherwise.
Update the context package docs to explicitly state that
a context is canceled when its deadline passes. Drop references
to contexts becoming "done" and just use "canceled" throughout.
Fixes#70945
Change-Id: I99fbd800c6049deaa37015a304f7f9d9a84100e1
Reviewed-on: https://go-review.googlesource.com/c/go/+/640095
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Damien Neil <dneil@google.com>
When ECH is rejected, properly take retry configs from the encrypted
extensions message. Also fix the bogo shim to properly test for this
behavior.
We should properly map the full BoringSSL -> Go errors so that we don't
run into a similar failure in the future, but this is left for a follow
up CL.
Fixes#70915
Change-Id: Icc1878ff6f87df059e7b83e0a431f50f1fea833c
Reviewed-on: https://go-review.googlesource.com/c/go/+/638583
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Add a section on the representation of values:
distinguish between values that are self-contained
and values that contain references while avoiding
the notion of "reference types" which is misleading.
Also, use "predeclared identifier nil" rather than
"predeclared value nil" because it is the identifier
that is predeclared.
Fixes#5083.
Change-Id: I2235673c6404f2c055f195e879f198c7ab246d58
Reviewed-on: https://go-review.googlesource.com/c/go/+/635801
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
It is not true that Unmarshal always treats a JSON null
as being equivalent to a no-op.
For bools, ints, uints, floats, strings, arrays, and structs,
it treats a JSON null as a no-op. However, for []byte, slice,
map, pointer, or interface, it zeros the underlying value.
Remove this suggestion as the actual behavior is inconsistent.
Note that the proposed behavior in v2 Unmarshal is to consistently
zero out the underlying value.
Change-Id: I02cef0bf7919f25cfd0aceb04486d37498761181
Reviewed-on: https://go-review.googlesource.com/c/go/+/638416
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
The GNU linker interprets @file as "read command-line options from file".
Thus, we forbid values starting with @ on linker flags. However, this
causes a problem when targeting Darwin. @executable_path, @loader_path, and
@rpath are special values used in Mach-O to change the library search path
and can be used in conjunction with the -install_name and -rpath linker
flags. Since the GNU linker does not support Mach-O, targeting Darwin
implies not using the GNU linker. Therefore, we allow @ in the linker flags
if and only if cfg.Goos == "darwin".
Fixes#40559
Change-Id: I0896758f0835e444ea0d501ea3fd8423cff97a27
GitHub-Last-Rev: 2b81dcd12e
GitHub-Pull-Request: golang/go#70939
Reviewed-on: https://go-review.googlesource.com/c/go/+/638075
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
In introducing iterators, package iter gives an example of how to
use an iterator in a range-over-func loop, but currently does not
give an example of what an iterator implementation might look like.
This change adds the example of map.Keys() before the usage example.
Additionally, it references to the Go blog for further examples,
as well as the language spec about for-range loops.
Fixes#70986
Change-Id: I7108d341d314d7de146b4c221700736c943a9f5d
Reviewed-on: https://go-review.googlesource.com/c/go/+/638895
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
On AIX, an R_ADDR relocation from an RODATA symbol to a DATA
symbol does not work, as the dynamic loader can change the address
of the data section, and it is not possible to apply a dynamic
relocation to RODATA. In order to get the correct address, we
apply the delta between unrelocated and relocated data section
addresses at run time. The linker saves both the unrelocated and
the relocated addresses, so we can compute the delta.
This is possible because RODATA symbols are generated by the
compiler and so we have full control of. On AIX, the only case
is the on-demand GC pointer masks from the type descriptors, for
very large types.
Perhaps there is a better way.
Fixes#70483.
Change-Id: I2664c0a813b38f7b146794cb1e73ccf5e238ca65
Reviewed-on: https://go-review.googlesource.com/c/go/+/638016
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>
len(map) is lowered to loading the first field of the map
structure, which is the length. Currently it is a load of an int.
With the old map, the first field is indeed an int. With Swiss
map, however, it is a uint64. On big-endian 32-bit machine,
loading an (32-bit) int from a uint64 would load just the high
bits, which are (probably) all 0. Change to a load with the proper
type.
Fixes#70248.
Change-Id: I39cf2d1e6658dac5a8de25c858e1580e2a14b894
Reviewed-on: https://go-review.googlesource.com/c/go/+/638375
Run-TryBot: 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: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
We were trying to keep all binaries stale in fips140 mode
so that every build would write and leave behind a fips.o
in the work directory for use by validating labs.
That breaks various staleness checks, including the one
in cmd/dist during GOFIPS140=latest ./make.bash.
Revert the fips140 hack. Validating labs will still be able
to find the fips.o when building against a clean cache.
Add the default godebug to the link hash though,
so that it is clear that GOFIPS140=latest
and GOFIPS140=off binaries have different hashes.
(The only effect is the default GODEBUG setting.)
They already had different hashes, because the
default GODEBUG ends up in p.Internal.BuildInfo,
and that gets hashed in a "modinfo" line,
but better to be explicit.
Fixes#70873.
Change-Id: I49a38c180208098c2b6720facef48f4e96d44c54
Reviewed-on: https://go-review.googlesource.com/c/go/+/637116
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
If we do one upgrade because of a go install target's go.mod file,
we still might need a second upgrade to implement the GOTOOLCHAIN
minimum. Instead of allowing a two-step switch (which we were
cutting off anyway), skip the first step and go straight to the
GOTOOLCHAIN min upgrade.
Fixes#69051.
Change-Id: I16f060f473574d8b8f84c55fae2fd0cdabc8aa19
Reviewed-on: https://go-review.googlesource.com/c/go/+/637496
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
CL 603959 added T.Context for #36532.
The discussion on the proposal only mentions t.Context.
However, the implementation of CL 603959 also added B.Context and F.Context.
They were added to the API listing, and B.Context was mentioned in
the release notes.
Unfortunately, the new B.Context and F.Context methods always
returned nil, rather than a context.Context value.
This change adds a working implementation of B.Context and F.Context.
For #36532Fixes#70866
Change-Id: I8a44e6649fb658e4f641ffb7efd08b4374f578ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/637236
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>
Per ISO/IEC 19790:2012, Section 7.4.3.1.
> A cryptographic module shall [04.12] provide the following services to
> operators.
>
> a) Show module’s versioning information. The cryptographic module
> shall [04.13] output the name or module identifier and the versioning
> information that can be correlated with a validation record (e.g.
> hardware, software and/or firmware versioning information)."
For #69536
Change-Id: I8061f64e4ae60a4666f6abd892cb1301d6bf2452
Reviewed-on: https://go-review.googlesource.com/c/go/+/636558
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
On linux/mips64, the syscall.Stat_t struct does not match the
kernel version of the struct. Functions that operate on a Stat_t
translate between it and the kernel struct.
The fstatat function was not doing this translation.
Make it do so.
Export a syscall.Fstatat on mips64 for usage by
internal/syscall/unix. Perhaps we should just do this on all
architectures, but this is the smaller change for now.
Fixes#70659
Change-Id: I38e36473689be25861953b418c9abc5b270a7bcf
Reviewed-on: https://go-review.googlesource.com/c/go/+/633280
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
- Describe that function invocation allocates space for a functions'
variables.
- Explain parameter passing in terms of assignments.
Change-Id: Ia693d73a570f7d1aa2ac05e6095b4e602e4e9bf2
Reviewed-on: https://go-review.googlesource.com/c/go/+/635800
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Rob Pike <r@golang.org>
NIST SP 800-131Ar3 ipd, scheduled for publication in 2025Q1, marks
AES-ECB as disallowed for encryption, and legacy use for decryption.
There are apparently no details on how the transition is going to work,
so to avoid surprises we just mark direct use of the Block as
non-approved.
We need to use Encrypt from higher level modes without tripping the
service indicator. Within the aes package, we just use the internal
function. For the gcm package we could do something more clever, but
this deep into the freeze, just make an exported function that we commit
to use nowhere else.
I could not figure out a decent way to block ECB on GODEBUG=fips140=only.
For #69536
Change-Id: I972a4b5da8efd0a0ab68d7dd509bec73aa2d6b68
Reviewed-on: https://go-review.googlesource.com/c/go/+/636775
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
If a package is incomplete, don't create the actions for building and
testing it. Instead report the errors for the package's dependencies
and report a setup failed error (similar to what we'd to for a load
error when producing the test packages). This produces similar errors to
what were produced by load.CheckPackageErrors while still produing the
test failure actions per package under test.
(I wasn't sure what to do about the last test case in test_setup_error.
I think it should be treated the same as other load errors?)
Fixes#70820
Change-Id: Ie95e3c158c50ed35a1f27237ef3db40502719993
Reviewed-on: https://go-review.googlesource.com/c/go/+/635856
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Matloob <matloob@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
The current b.Loop example doesn't focus on the basic usage of b.Loop.
Replace this with a new example that uses (slightly) more realistic
things to demonstrate the most salient points of b.Loop.
We also move the example into an example file so that we can write a
real Benchmark function and a real function to be benchmarks, which
makes this much closer to what a user would actually write.
Updates #61515.
Change-Id: I4d830b3bfe3eb3cd8cdecef469fea0541baebb43
Reviewed-on: https://go-review.googlesource.com/c/go/+/635896
Auto-Submit: Austin Clements <austin@google.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>
This updates the testing documentation to frame B.Loop as the
canonical way to write benchmarks. We retain documentation on b.N
benchmarks because people will definitely continue to see them (and
write them), but it's demoted to clearly second class.
This also attempts to clarify and refine the B.Loop documentation
itself.
Updates #61515Fixes#70787
Change-Id: If5123435bfe3a5883a753119ecdf7bbc41afd499
Reviewed-on: https://go-review.googlesource.com/c/go/+/635895
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Reviewed-by: Caleb Spare <cespare@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Austin Clements <austin@google.com>
go test -json has two new effects in Go 1.24: it implies go build
-json, and it adds a FailedBuild field in test events. For
compatibility, CL 629335 added gotestjsonbuildtext=1, which disables
the implicit go build -json, but that CL didn't affect the FailedBuild
field. In principle this shouldn't matter because it's just another
JSON field, but just so we don't have to worry about some intermediate
behavior, this CL makes gotestjsonbuildtext=1 disable the FailedBuild
field as well.
Updates #62067
Updates #70402
Change-Id: I006d1ea0468980ee2564495324e8b4ed082898af
Reviewed-on: https://go-review.googlesource.com/c/go/+/635899
Auto-Submit: Austin Clements <austin@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
This is part of a series of CLs that aim to reduce how often interface
arguments escape for the print functions in fmt.
Currently, method values are one of two reasons reflect.Value.Interface
always escapes its reflect.Value.
Our later CLs modify behavior around method values, so we add some tests
of function formatting (including method values) to help reduce the
chances of breaking behavior later.
We also add in some allocation tests focused on interface arguments for
the print functions. These currently do not show any improvements
compared to Go 1.21.
These tests were originally in a later CL in our stack (CL 528538),
but we split them out into this CL and moved them earlier in the stack.
Updates #8618
Change-Id: Iec51abc3b7f86a2711e7497fc2fb7a678b9f8f73
Reviewed-on: https://go-review.googlesource.com/c/go/+/529575
Reviewed-by: Carlos Amedee <carlos@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Testing on the freebsd-386 gomote seems to show that sendfile returns
a non-zero number of bytes written even when it returns EINVAL.
This confuses the caller. Change the Go code to only return non-zero
on success or EINTR or EAGAIN, which are the only cases where the
man page says that sendfile updates the number of bytes.
For #70763
Change-Id: Icc04e6286b5b29a2029237711d50fe4973234f0a
Reviewed-on: https://go-review.googlesource.com/c/go/+/635815
Reviewed-by: Ian Lance Taylor <iant@google.com>
Commit-Queue: Ian Lance Taylor <iant@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Currently, a symbol reference is counted as a reference to a
builtin symbol if the name matches a builtin. Usually builtin
references are generated by the compiler. But one could manually
write one with linkname. Since the list of builtin functions are
subject to change from time to time, we don't want users to depend
on their names. So we don't count a linknamed reference as a
builtin reference, and instead, count it as a named reference, so
it is checked by the linker.
Change-Id: Id3543295185c6bbd73a8cff82afb8f9cb4fd6f71
Reviewed-on: https://go-review.googlesource.com/c/go/+/635755
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This updates the new version API for the discussion on #63952.
This change reveals that in fact none of the tests set the
VERSYM_HIDDEN bit. The code before this CL set the hidden flag
for symbols that appear in DynamicVersionNeed, but that is not
an accurate representation of the ELF. The readelf program
does print undefined symbols that way (with a single '@'),
but that doesn't mean that the hidden flag is set.
Leaving tests with the hidden bit set for later.
For #63952
Change-Id: Ida60831e0c9922dfc10f10c7a64bc76a2b197537
Reviewed-on: https://go-review.googlesource.com/c/go/+/635079
Reviewed-by: Austin Clements <austin@google.com>
Commit-Queue: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
This removes the difference in behavior between FIPS mode on and off.
Instead of the sentinel type we could have moved the Reader to the
drbg package and checked for equality, but then we would have locked the
crypto/rand.Reader implementation to the one in the FIPS module (which
we might have to support for years).
In internal/ed25519.GenerateKey we remove the random parameter entirely,
since that function is not actually used by crypto/ed25519.GenerateKey,
which instead commits to being deterministic.
Fixes#70772
Change-Id: Ic1c7ca2c1cd59eb9cd090a8b235c0ce218921ac5
Reviewed-on: https://go-review.googlesource.com/c/go/+/635195
Reviewed-by: Roland Shoemaker <roland@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
InterfaceAddrs returns a list of the system's unicast interface addresses.
In order to do so, the function reuses the existing helpers and
list first all addresses with the netlink call RTM_GETADDR, then
all interfaces with RTM_GETLINK, and later it merge both lists
(each address references an interface).
However, the list of interfaces and addresses are obtained at
different times and there can be inconsistencies and, if an
address references an interface that is not present in the list
of interfaces, the function fails with an error.
Since the function InterfaceAddress is only about the system
addresses, there is no need to list all the interfaces, and we can
obtain the list of addresses directly from the netlink call RTM_GETADDR.
There is no need to correlate this list with the list of interfaces, as
the OS is the source of truth and should be the one providing the
consistency between addresses and interfaces.
Fixes#51934
Change-Id: I3b816e8146b1c07fdfe1bf6af338f001ef75734f
Reviewed-on: https://go-review.googlesource.com/c/go/+/635196
Reviewed-by: Ian Lance Taylor <iant@google.com>
Commit-Queue: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Currently, cmd/internal/objfile provides dissassembly routines for
various architectures, which depend on dissassemblers from x/arch.
cmd/internal/objfile is imported in tools that need dissassembly
(objdump, pprof) and tools that don't need dissassembly (nm,
addr2line). Adding/improving disassembly support for more
architectures can cause binary size increase, and for some tools
(nm, addr2line) it is not necessary.
This CL breaks out dissassembly routines to a different package,
which is only imported in tools that need dissassembly. Other
tools can depend on cmd/internal/objfile without the disassembly
code from x/arch.
This reduces binary sizes for those tools. On darwin/arm64,
old new
cmd/addr2line 4554418 3648882 -20%
cmd/addr2line (-ldflags=-w) 3464626 2641650 -24%
cmd/nm 4503874 3616722 -20%
cmd/nm (-ldflags=-w) 3430594 2609490 -24%
For #70699.
Change-Id: Ie45d5d5c5500c5f3882e8b3c4e6eb81f0d815292
Reviewed-on: https://go-review.googlesource.com/c/go/+/634916
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
The comment being removed was added by commit ff3173849e
(which predates Gerrit and Rietveld, so no CL link), and
at the time it made sense.
Since CL 148370043 (and up to the current implementation of Clearenv)
the env map, which is populated by copyenv, is actually used, so the
comment is no longer valid.
It is also misleading, so it's best to remove it.
Change-Id: I8bd2e8bca6262759538e5bcbd396f0c71cca6a4c
Reviewed-on: https://go-review.googlesource.com/c/go/+/635078
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
may by implemented as a read of each individual sub-value
may be implemented as a read of each individual sub-value
(array element, struct field, or real/imaginary component),
in any order.
Similarly, a write of an array, struct, or complex number
@@ -453,7 +453,7 @@ crash, or do something else.)
</p>
<pclass="rule">
The <i>k</i>th receive on a channel with capacity <i>C</i> is synchronized before the completion of the <i>k</i>+<i>C</i>th send from that channel completes.
The <i>k</i>th receive from a channel with capacity <i>C</i> is synchronized before the completion of the <i>k</i>+<i>C</i>th send on that channel.
// Test that we have no more than one build ID. In the past we used
// Test that we have no more than one build ID. In the past we used
// to generate a separate build ID for each package using cgo, and the
// linker concatenated them all. We don't want that--we only want
// linker concatenated them all. We don't want that--we only want
// one.
import(
@@ -42,7 +42,7 @@ sections:
forlen(d)>0{
// ELF standards differ as to the sizes in
// note sections. Both the GNU linker and
// note sections. Both the GNU linker and
// gold always generate 32-bit sizes, so that
// is what we assume here.
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.
