When reading from time.Timer.C for an expired timer using
a fake clock (in a synctest bubble), the timer will not
be in a heap. Avoid a spurious panic claiming the timer
moved between synctest bubbles.
Drop the panic when a bubbled goroutine reads from a
non-bubbled timer channel: We allow bubbled goroutines
to access non-bubbled channels in general.
Fixes#70741
Change-Id: I27005e46f4d0067cc6846d234d22766d2e05d163
Reviewed-on: https://go-review.googlesource.com/c/go/+/634955
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>
SP 800-90A Rev. 1 10.1.2.5 step 7 requires
reseed_counter = reseed_counter + 1
as the final step before returning SUCCESS.
This increment of reseedCounter was missing, meaning the reseed interval
check at the start of Generate wasn't actually functional.
Given how it's used, and that it has a reseed interval of 2^48, this
condition will never actually occur but the check is still required by
the standard.
For #69536
Change-Id: I314a7eee5852e6d0fa1a0a04842003553cd803e7
Reviewed-on: https://go-review.googlesource.com/c/go/+/634775
Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Currently specials try to save on space by only encoding the offset from
the base of the span in a uint16. This worked fine up until Go 1.24.
- Most specials have an offset of 0 (mem profile, finalizers, etc.)
- Cleanups do not care about the offset at all, so even if it's wrong,
it's OK.
- Weak pointers *do* care, but the unique package always makes a new
allocation, so the weak pointer handle offset it makes is always zero.
With Go 1.24 and general weak pointers now available, nothing is
stopping someone from just creating a weak pointer that is >64 KiB
offset from the start of an object, and this weak pointer must be
distinct from others.
Fix this problem by just increasing the size of a special and making the
offset a uintptr, to capture all possible offsets. Since we're in the
freeze, this is the safest thing to do. Specials aren't so common that I
expect a substantial memory increase from this change. In a future
release (or if there is a problem) we can almost certainly pack the
special's kind and offset together. There was already a bunch of wasted
space due to padding, so this would bring us back to the same memory
footprint before this change.
Also, add tests for equality of basic weak interior pointers. This
works, but we really should've had tests for it.
Fixes#70739.
Change-Id: Ib49a7f8f0f1ec3db4571a7afb0f4d94c8a93aa40
Reviewed-on: https://go-review.googlesource.com/c/go/+/634598
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>
Commit-Queue: Michael Knyszek <mknyszek@google.com>
In hindsight, I think the "advice" I wrote is a bit heavy-handed and
better suited for something like the GC guide. Listing the use-cases
seems good, and all the possible things that go wrong seems to do the
trick in terms of deterrence, like it does with finalizers.
Also, include some points I missed, like the tiny allocator warning and
the fact that weak pointers are not guaranteed to ever return nil.
Also, a lot of this actually shouldn't have been in the package docs.
Many of the warnings only apply to weak pointers, but not other data
structures that may live in this package in the future, like weak-keyed
maps.
Change-Id: Id245661540ffd93de4b727cd272284491d085c1e
Reviewed-on: https://go-review.googlesource.com/c/go/+/634376
Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
The presence of a pc > entry check in CallersFrame implies we might
actually see pc == entry, when in reality Callers will never return such
a PC. This check is actually just a safety check for avoid reporting
completely nonsensical from bad input.
all.bash reports two violations to this invariant:
TestCallersFromWrapper, which explicitly constructs a CallersFrame input
with an entry PC.
runtime/pprof.printStackRecord, which passes pprof stacks to
CallersFrame (technically not a valid use of CallersFrames!).
runtime/pprof.(*Profile).Add can add the entry PC of
runtime/pprof.lostProfileEvent to samples.
(CPU profiles do lostProfileEvent + 1. I will send a second CL to fix
Add.)
Change-Id: Iac2a2f0c15117d4a383bd84cddf0413b2d7dd3ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/634315
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>
Before tools there was no way to directly import a package in another
module, and so missing packages were always marked as "all" due to being
dependencies of a package in a main module.
Tools break that assumption, and so to report errors in tool packages
correctly we need to mark packages as being in "all" even if they do not
exist.
Fixes#70582
Change-Id: I3273e0ec7910894565206de77986f5c249a5658c
Reviewed-on: https://go-review.googlesource.com/c/go/+/634155
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>
Before this change, when go tool wass used to start a tool defined in a
go.mod tool directive, it used the environment the go command was
running in. The issue with doing that is that the go command sets
various environment variables from the computed environment when
invoking a subcommand. That is used to standardise the environment for
the various tools invoked by the go command, but it is not the
expectatation of tools invoked by the go command, especially since those
environment variables may change the behavior of the tool run. Instead
use the same environment we use in go run to start the executable: the
original environment (with minor modifications) saved before we start
explicitly setting the envornment, with GOROOT/bin added to the path so
that sub commands that run the go tool use the proper go tool binary.
Fixes#70544
Change-Id: Ifbf0040a2543113638eec7232323eb9de1d61529
Reviewed-on: https://go-review.googlesource.com/c/go/+/631836
Reviewed-by: Conrad Irwin <conrad.irwin@gmail.com>
Reviewed-by: Sean Liao <sean@liao.dev>
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The Go 1.24 RC is due for next week. This is a 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
Change-Id: If4fd03a18590ff3b6e701a9698370c57c69979c2
Reviewed-on: https://go-review.googlesource.com/c/go/+/634041
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
go tool, go run, and the executable caching logic have all used
path.Base of a package's import path to set the name of the executable
produced. But the base name for a package name that's the same as a
module name ending in a major version is just that major version, which
is not very useful. For go build and go install, we use
load.DefaultExecName as the name of the binary which will select the
second to last element of the import path as the name of the executable
produced. This change changes go tool, go run, and the executable
caching logic to all use DefaultExecName consistently to pick the name
of the executable.
Change-Id: I8e615bbc6a4f9cc4549165c31954fab181d63318
Reviewed-on: https://go-review.googlesource.com/c/go/+/634039
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Conrad Irwin <conrad.irwin@gmail.com>
When adding support for module tools, we added the ability for `go tool`
to edit the module cache. For users with `GOFLAGS=-modcacherw` this
could have led to a situation where some of the files in the mod cache
were unexpectedly not deletable.
We also allow -modfile so that people can select which module they are
working in when looking for tools.
We still do not support arbitrary build flags for tools with `go tool`.
If you want those, use `go run` or `go build`, etc. instead.
Updates #48429
Change-Id: Ic3c56bb8b6ba46114196465ca6ee2dcb08b9dcc0
Reviewed-on: https://go-review.googlesource.com/c/go/+/632575
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
I did not added a test because `benchmark_test.go` is `package testing_test`
and I don't care to change that because calling predictN is not testing the
thing I would want to test.
Ideally we would run benchmark in a VM with a highjacked clocksource that never
marches forward, or using faketime but that looks fairly involved for a quickie
fix.
Fixes#70709
Change-Id: I8b4d697aff7cba33da388cb0ae8e2c2b550b9690
Reviewed-on: https://go-review.googlesource.com/c/go/+/633419
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Jorropo <jorropo.pgm@gmail.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>
The TestScript/build_trimpath_cgo test for cmd/go 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.
Fixes#70669
Change-Id: I421a2a9348e727e3ac4a3d42baa4d206cfbc047b
Reviewed-on: https://go-review.googlesource.com/c/go/+/633038
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@golang.org>
markUsed was not checking that the error from os.Stat was nil before
trying to access the FileInfo entry returned by it. Instead, always
check the error and return false if it's non-nil (usually because the
file does not exist). This can happen if an index entry exists in the
cache, but the output entry it points to does not. markUsed is called at
different points for the index entry and for the output entry, so it's
possible for the index entry to be marked used, and then for another go
process to trim the cache, deleting the output entry. I'm not sure how
likely that is, or if this is what has been triggering the user observed
instances of #70600, but it's enough for a test case.
Fixes#70600
Change-Id: Ia6be14b4a56736d06488ccf93c3596fff8159f22
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/633037
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Theses tests were forgot because when CL 462298 was originally written
And & Or atomics were not available in go.
Git were smart enough to rebase over And's & Or's addition.
After most reviews and before merging it were pointed I should
make theses new intrinsics noescape.
When doing this last minute addition I forgot to add tests.
Change-Id: I457f98315c0aee91d5743058ab76f256856cb782
Reviewed-on: https://go-review.googlesource.com/c/go/+/633416
Reviewed-by: 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>
On FreeBSD 14.1 we fail to link against C code with internal linking.
The symptom is apparently undefined symbols, but explicitly pointing the
linker at compiler-rt for -libgcc fixes the issue. This looks a lot like
the workaround on OpenBSD, but the symptom is different.
--print-libgcc-file-name produces libclang_rt.builtins-x86_64.a which
appears to be an insufficient subset of libcompiler_rt.a.
For #61095.
Change-Id: Iff5affbc923d69c89d671a69d8f4ecaadac42177
Cq-Include-Trybots: luci.golang.try:gotip-freebsd-amd64
Reviewed-on: https://go-review.googlesource.com/c/go/+/632975
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Currently, maphash.Comparable forces its argument to escape if it
contains a pointer, as we cannot hash stack pointers, which will
change when the stack moves. However, for a string, it is actually
okay if its data pointer points to the stack, as the hash depends
on only the content, not the pointer.
Currently there is no way to write this type-dependent escape
logic in Go code. So we implement it in the compiler as an
intrinsic. The compiler can also recognize not just the string
type, but types whose pointers are all string pointers, and make
them not escape.
Fixes#70560.
Change-Id: I3bf219ad71a238d2e35f0ea33de96487bc8cc231
Reviewed-on: https://go-review.googlesource.com/c/go/+/632715
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This is optimized to be cheap in terms of extra code and complexity,
rather than performance, so we reuse the GCD we have for inverting d.
Recovers most of the performance loss since CL 630516, although
benchmarking key generation is by nature extremely noisy.
goos: darwin
goarch: arm64
pkg: crypto/rsa
cpu: Apple M2
│ 3b42687c56 │ b3d018a1e8-dirty │
│ sec/op │ sec/op vs base │
GenerateKey/2048-8 104.1m ± 7% 139.7m ± 20% +34.10% (p=0.000 n=20)
Updates #69799
For #69536
Change-Id: I00347610935db8feb0597529a301ad7ace5b2f22
Reviewed-on: https://go-review.googlesource.com/c/go/+/632479
Reviewed-by: Roland Shoemaker <roland@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Turns out that recomputing them (and qInv in particular) in constant
time is expensive, so let's not throw them away when they are available.
They are much faster to check, so we now do that on precompute.
Also, thanks to the opaque crypto/internal/fips140/rsa.PrivateKey type,
we now have some assurance that the values we use are always ones we
checked.
Recovers most of the performance loss since CL 630516 in the happy path.
Also, since now we always use the CRT, if necessary by running a
throwaway Precompute, which is now cheap if PrecomputedValues is filled
out, we effectively fixed the JSON round-trip slowdown (#59695).
goos: darwin
goarch: arm64
pkg: crypto/rsa
cpu: Apple M2
│ 3b42687c56 │ f017604bc6-dirty │
│ sec/op │ sec/op vs base │
ParsePKCS8PrivateKey/2048-8 26.76µ ± 1% 65.99µ ± 1% +146.64% (p=0.002 n=6)
Fixes#59695
Updates #69799
For #69536
Change-Id: I507f8c5a32e69ab28990a3bf78959836b9b08cc9
Reviewed-on: https://go-review.googlesource.com/c/go/+/632478
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: Roland Shoemaker <roland@golang.org>
We are severely limited by the crypto/rsa API in a few ways:
- Precompute doesn't return an error, but is the only function allowed
to modify a PrivateKey.
- Clients presumably expect the PrecomputedValues big.Ints to be
populated after Precompute.
- MarshalPKCS1PrivateKey requires the precomputed values, and doesn't
have an error return.
- PrivateKeys with only N, e, and D have worked so far, so they might
have to keep working.
To move precomputation to the FIPS module, we focus on the happy path of
a PrivateKey with two primes where Precompute is called before anything
else, which match ParsePKCS1PrivateKey and GenerateKey.
There is a significant slowdown in the Parse benchmark due to the
constant-time inversion of qInv. This will be addressed in a follow-up
CL that will use (and check) the value in the ASN.1.
Note that the prime product check now moved to checkPrivateKey is broken
(Π should start at 1 not 0) and fixed in CL 632478.
Updates #69799
For #69536
Change-Id: I95a8bc1244755c6d15d7c4eb179135a15608ddd6
Reviewed-on: https://go-review.googlesource.com/c/go/+/632476
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: Russ Cox <rsc@golang.org>
This is the result of running relnote todo today and reviewing its
output. Most of the remaining items that still need to be added to
Go 1.24 release notes are now tracked in release blocking issues.
For a few where it's less clear, I opted to comment on issues.
A good number of items were proposals that affect golang.org/x repos
and don't need to be mentioned in Go 1.24 release notes; they're now
annotated as such.
For #68545.
Change-Id: I4dc7f6d2cf5ab9e68bce83d01413224f80384e2f
Reviewed-on: https://go-review.googlesource.com/c/go/+/631684
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>
Fix a regression that appeared in 1.23 when it comes to the stack traces
shown in the trace viewer. In 1.22 and earlier, the viewer was always
showing end stack traces. In 1.23 and later the viewer started to
exclusively show start stack traces.
Showing only the start stack traces made it impossible to see the last
stack trace produced by a goroutine. It also made it hard to understand
why a goroutine went off-cpu, as one had to hunt down the next running
slice of the same goroutine.
Emit end stack traces in addition to start stack traces to fix the
issue.
Fixes#70570
Change-Id: Ib22ea61388c1d94cdbc99fae2d207c4dce011a59
Reviewed-on: https://go-review.googlesource.com/c/go/+/631895
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com>
Reviewed-by: Nick Ripley <nick.ripley@datadoghq.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TestTransportRemovesH2ConnsAfterIdle is experiencing flaky
failures due to a bug in idle connection handling.
Upon inspection, TestTransportRemovesH2ConnsAfterIdle
is slow and (I think) not currently testing the condition
that it was added to test.
Using the new synctest package, this CL:
- Adds a test for the failure causing flakes in this test.
- Rewrites the existing test to use synctest to avoid sleeps.
- Adds a new test that covers the condition the test was
intended to examine.
The new TestTransportIdleConnRacesRequest exercises the
scenario where a never-used connection is closed by the
idle-conn timer at the same time as a new request attempts
to use it. In this race, the new request should either
successfully use the old connection (superseding the
idle timer) or should use a new connection; it should not
use the closing connection and fail.
TestTransportRemovesConnsAfterIdle verifies that
a connection is reused before the idle timer expires,
and not reused after.
TestTransportRemovesConnsAfterBroken verifies
that a connection is not reused after it encounters
an error. This exercises the bug fixed in CL 196665,
which introduced TestTransportRemovesH2ConnsAfterIdle.
For #70515
Change-Id: Id23026d2903fb15ef9a831b2df71177ea177b096
Reviewed-on: https://go-review.googlesource.com/c/go/+/631795
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>
Previously, we'd skip installing the bundled HTTP/2 support
if Transport.TLSNextProto is non-nil.
With the addition of the Transport.Protocols field, we'll
install HTTP/2 if Protocols contains HTTP2, even if TLSNextProto
is non-nil. However, we shouldn't do so if it already contains an
"h2" entry.
Change-Id: Ib086473bb52f1b76d83b1df961d41360c605832c
Reviewed-on: https://go-review.googlesource.com/c/go/+/631395
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
The Go 1.24 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: I1b2e3b63ccc1137256d80c882b99ed26a66cbf6b
Reviewed-on: https://go-review.googlesource.com/c/go/+/631336
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Bypass: Dmitri Shuralyov <dmitshur@golang.org>
This change modifies the logic which searches for existing cleanups.
The existing search logic sets the next node to the current node
in certain conditions. This would cause future searches to loop
endlessly. The existing loop could convert non-cleanup specials into
cleanups and cause data corruption.
This also changes where we release the m while we are adding a
cleanup. We are currently holding onto an p-specific gcwork after
releasing the m.
Change-Id: I0ac0b304f40910549c8df114e523c89d9f0d7a75
Reviewed-on: https://go-review.googlesource.com/c/go/+/630278
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Carlos Amedee <carlos@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
1. In cmd/internal/obj, only apply the exclusion list to data symbols.
Text symbols are always fine since they can use PC-relative relocations.
2. In cmd/link, only skip trampolines for text symbols in the same package
with the same type. Before, all text symbols had type STEXT, but now that
there are different sections of STEXT, we can only rely on symbols in the
same package in the same section being close enough not to need
trampolines.
Fixes#70379.
Change-Id: Ifad2bdd6001ad3b5b23e641127554e9ec374715e
Reviewed-on: https://go-review.googlesource.com/c/go/+/631036
Auto-Submit: 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>
This makes three related changes that work particularly well together
and would require significant extra work to do separately: it replaces
X25519Kyber768Draft00 with X25519MLKEM768, it makes CurvePreferences
ordering crypto/tls-selected, and applies a preference to PQ key
exchange methods over key shares (to mitigate downgrades).
TestHandshakeServerUnsupportedKeyShare was removed because we are not
rejecting unsupported key shares anymore (nor do we select them, and
rejecting them actively is a MAY). It would have been nice to keep the
test to check we still continue successfully, but testClientHelloFailure
is broken in the face of any server-side behavior which requires writing
any other messages back to the client, or reading them.
Updates #69985Fixes#69393
Change-Id: I58de76f5b8742a9bd4543fd7907c48e038507b19
Reviewed-on: https://go-review.googlesource.com/c/go/+/630775
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This is quite a bit slower (almost entirely in the e * d reductions,
which could be optimized), but the slowdown is only 12% of a signature
operation.
Also, call Validate at the end of GenerateKey as a backstop. Key
generation is so incredibly slow that the extra time is negligible.
goos: darwin
goarch: arm64
pkg: crypto/rsa
cpu: Apple M2
│ ec9643bbed │ ec9643bbed-dirty │
│ sec/op │ sec/op vs base │
SignPSS/2048-8 869.8µ ± 1% 870.2µ ± 0% ~ (p=0.937 n=6)
GenerateKey/2048-8 104.2m ± 17% 106.9m ± 10% ~ (p=0.589 n=6)
ParsePKCS8PrivateKey/2048-8 28.54µ ± 2% 136.78µ ± 8% +379.23% (p=0.002 n=6)
Fixes#57751
Co-authored-by: Derek Parker <parkerderek86@gmail.com>
Change-Id: Ifb476859207925a018b433c16dd62fb767afd2d5
Reviewed-on: https://go-review.googlesource.com/c/go/+/630517
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>
Different Plan 9 file servers may return different error strings
on an attempt to open a directory for writing: EISDIR, EACCES or
EPERM. TestOpenError allows for the first two, but it needs to
allow for EPERM as well.
Fixes#70440
Change-Id: I705cc086e21630ca254499ca922ede78c9901b11
Reviewed-on: https://go-review.googlesource.com/c/go/+/629635
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Bypass: Dmitri Shuralyov <dmitshur@golang.org>
Unify how go/types, types2, and noder read in unified export data from
GC-created files.
This splits FindExportData into smaller pieces for improved code
sharing.
- FindPackageDefinition finds the package definition file in the ar
archive.
- ReadObjectHeaders reads the object headers.
- ReadExportDataHeader reads the export data format header.
There is a new convenience wrapper ReadUnified that combines all of
these. This documents the expected archive contents.
Updates noder and the importers to use these.
This also adjusts when end-of-section marker ("\n$$\n") checking happens.
Change-Id: Iec2179b0a1ae7f69eb12d077018f731116a77f13
Reviewed-on: https://go-review.googlesource.com/c/go/+/628155
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Commit-Queue: Tim King <taking@google.com>
For tests that are interested in testing the difference between TLS in
FIPS 140-3 required mode or otherwise two new helpers are introduced,
runWithFIPSEnabled and runWithFIPSDisabled. They take care of forcing
the correct TLS FIPS 140-3 state regardless of the overal GODEBUG=fips
state, and restoring it afterwards.
For the tests that use features or test data not appropriate for
TLS in FIPS 140-3 required mode we add skips. For some tests we can make
them appropriate for both TLS FIPS 140-3 required or not by tweaking some
parameters that weren't important to the subject under test, but would
otherwise preclude TLS FIPS 140-3 required mode (e.g. because they used
TLS 1.0 when the test could use TLS 1.2 instead). For others, switching
test certificates to a RSA 2048 hierarchy is sufficient. We avoid
regenerating the existing RSA 1024 certs as 2048 since it would
invalidate recorded static flow data.
Tests that rely on static message flows (primarily the client and server
handshake) tests are skipped due to FIPS mode being non-deterministic
and inappropriate for this style of testing.
Change-Id: I311f3828dac890bb3ff8ebda6ed73d50f0797110
Reviewed-on: https://go-review.googlesource.com/c/go/+/629736
Reviewed-by: Roland Shoemaker <roland@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>
Per IG 10 3.A a module implementing PBKDF2 must perform a CAST
on the derivation of a master key. This commit adds the required CAST
test.
The salt length (16 bytes), and output length (14 bytes) for the test
are selected to meet FIPS requirements. The iteration count must be
at least 2 so we use that value exactly for the fastest self-test
allowable.
We test all underlying prerequisite algorithms (HMAC, digest algorithms)
separately.
For #69536
Change-Id: Iba9e87ab89eeec1c73adc7e56016674ac8065c39
Reviewed-on: https://go-review.googlesource.com/c/go/+/623195
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
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>
Add an UnencryptedHTTP2 protocol value.
Both Server and Transport implement "HTTP/2 with prior knowledge"
as described in RFC 9113, section 3.3. Neither supports the
deprecated HTTP/2 upgrade mechanism (RFC 7540, section 3.2 "h2c").
For Server, UnencryptedHTTP2 controls whether the server
will accept HTTP/2 connections on unencrypted ports.
When enabled, the server checks new connections for
the HTTP/2 preface and routes them appropriately.
For Transport, enabling UnencryptedHTTP2 and disabling HTTP1
causes http:// requests to be made over unencrypted HTTP/2
connections.
For #67816
Change-Id: I2763c4cdec1c2bc6bb8157edb93b94377de8a59b
Reviewed-on: https://go-review.googlesource.com/c/go/+/622976
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Setting GODEBUG=multipathtcp= [1] has no effects on apps using
ListenTCP or DialTCP directly.
According to the documentation, these functions are supposed to act like
Listen and Dial respectively:
ListenTCP acts like Listen for TCP networks.
DialTCP acts like Dial for TCP networks.
So when reading this, I think we should expect GODEBUG=multipathtcp= to
act on these functions as well.
Also, since #69016, MPTCP is used by default (if supported) with TCP
listeners. Similarly, when ListenTCP is used directly, MPTCP is
unexpectedly not used. It is strange to have a different behaviour.
So now, ListenTCP and DialTCP also check for MPTCP. Those are the exact
same checks that are done in dial.go, see Listen and dialSingle.
[1] https://pkg.go.dev/net#Dialer.SetMultipathTCPFixes#70500
Change-Id: I646431a74571668e505493fa8c1b2206bf30ed09
GitHub-Last-Rev: 69a31a1b03
GitHub-Pull-Request: golang/go#70501
Reviewed-on: https://go-review.googlesource.com/c/go/+/630715
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: 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>
Adds support for server-side ECH.
We make a couple of implementation decisions that are not completely
in-line with the spec. In particular, we don't enforce that the SNI
matches the ECHConfig public_name, and we implement a hybrid
shared/backend mode (rather than shared or split mode, as described in
Section 7). Both of these match the behavior of BoringSSL.
The hybrid server mode will either act as a shared mode server, where-in
the server accepts "outer" client hellos and unwraps them before
processing the "inner" hello, or accepts bare "inner" hellos initially.
This lets the server operate either transparently as a shared mode
server, or a backend server, in Section 7 terminology. This seems like
the best implementation choice for a TLS library.
Fixes#68500
Change-Id: Ife69db7c1886610742e95e76b0ca92587e6d7ed4
Reviewed-on: https://go-review.googlesource.com/c/go/+/623576
Reviewed-by: 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>
Auto-Submit: Roland Shoemaker <roland@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Using filepath.SkipDir without confirming that d is a directory makes
it prone to taking unintended action if a file (not a directory) with
the same name gets added.
This isn't a problem today, but we shouldn't spend human code review
time checking that this doesn't somehow happen in the future, either.
Change-Id: I29bf203ddef175c3ad23c9ddc10fa934126ac853
Reviewed-on: https://go-review.googlesource.com/c/go/+/630635
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Bypass: Dmitri Shuralyov <dmitshur@golang.org>
Currently, instruction encoding is a slice of encoding types, which
is indexed by a masked version of the riscv64 opcode. Additional
information about some instructions (for example, if an instruction
has a ternary form and if there is an immediate form for an instruction)
is manually specified in other parts of the assembler code.
Rework the instruction encoding information so that we use a table
driven form, providing additional data for each instruction where
relevant. This means that we can simplify other parts of the code
by simply looking up the instruction data and reusing minimal logic.
Change-Id: I7b3b6c61a4868647edf28bd7dbae2150e043ae00
Cq-Include-Trybots: luci.golang.try:gotip-linux-riscv64
Reviewed-on: https://go-review.googlesource.com/c/go/+/622535
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com>
Reviewed-by: Mark Ryan <markdryan@rivosinc.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Adjust splitPathInRoot to match its documented behavior
of dropping . path components except at the end of the path.
This function takes a prefix, path, and suffix; previously
it would preserve a trailing . at the end of the path
even when joining to a suffix.
The practical effect of this change is that we we'll skip
a pointless open of . when following a symlink under some
circumstances:
- open "a/target"
- "a" is a symlink to "b/."
- previously: we rewrite our path to "b/./target"
- now: we rewrite our path to "b/target"
This is a fairly unimportant edge case, and our observable
behavior isn't changing. The main motivation for this change is
that the overall behavior is more comprehensible if splitPathInRoot
follows its documentation.
Change-Id: I96c6a5e3f489cdac991ba1bd702180d69625bc64
Reviewed-on: https://go-review.googlesource.com/c/go/+/630615
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
After tools CL 612038, the package astutil stops being vendored, but
_gen/rulegen.go needs to import this package.
In particular, after update golang.org/x/tools, the package astutil
is deleted from the vendor directory, and got error when run TestStdlib
in longtest. So in this CL, we make _gen an actual submodule and
skip it in TestStdlib.
Change-Id: I76f77b66427f6490b4746698711a6e307ad2ba79
Reviewed-on: https://go-review.googlesource.com/c/go/+/629015
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>
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
This commit imports the x/crypto/pbkdf2 package as described in the
linked proposal. The code is unchanged with the exception of a few
small updates to reflect feedback from the proposal comment period:
* the Key function is made generic over a hash.Hash
* the h function is moved to be the first argument
* keyLen is renamed to keyLength
* an error return is added
* the unit tests were moved to the pbkdf2_test package
Updates #69488
Change-Id: If72f854daeb65a5c7fbe45ebd341e63a33340624
Reviewed-on: https://go-review.googlesource.com/c/go/+/628135
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>
While the cached name of an executable is set based on the base name of
the package path, the executable produced as the output of link doesn't
have ExeName set on it and is just called a.out (with a .exe suffix on
Windows). Set ExeName so that the first time the binary is run, from the
directory link is run in, it has the right name for ps.
For #48429
Change-Id: Ic049304ec6fd5b23c2f5aaaf91aa58d79fe5a7ba
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/630695
Reviewed-by: Conrad Irwin <conrad.irwin@gmail.com>
Reviewed-by: Hongxiang Jiang <hxjiang@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
1. Support for decimal arithmetic quad instructions of powerpc: DADDQ, DSUBQ, DMULQ
and DDIVQ.
2. Support for decimal compare ordered, unordered, quad instructions of powerpc:
DCMPU, DCMPO, DCMPUQ, and DCMPOQ.
Change-Id: I32a15a7f0a127b022b1f43d376e0ab0f7e9dd108
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/+/623036
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Paul Murphy <murp@ibm.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Paul Murphy <murp@ibm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The code takes care to print test results during "go test ./..."
in the package order, delaying prints until it's that package's
turn, even when tests run in parallel. For some reason, the
prints about the test not running were not included in that,
making them print out of order. Fix that, printing that result
with the usual result printer.
This is particularly noticeable during all.bash when we start
letting cmd/dist vet packages without tests.
Change-Id: If07f9fe5a6fac2b57b24d599126b451357a164e2
Reviewed-on: https://go-review.googlesource.com/c/go/+/630416
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
Pass all packages to go test, even if they don't have test files,
so that go test can still run vet.
I just got burned by a vet error in a package without a test
showing up when I added an (unrelated) test.
There are not enough packages without tests to be worth
the "savings" of not letting the go command vet those packages.
For #60463.
Change-Id: Ib9258655151144dce6a51deeae73d651aa46cb2c
Reviewed-on: https://go-review.googlesource.com/c/go/+/630015
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>
An earlier CL moved the actual test from crypto/internal/fips/check
to crypto/internal/fipstest (now crypto/internal/fips140test),
so this cmd/dist check has been doing nothing for a little while.
Fix it to do what it intends.
Also run the actual crypto package tests in FIPS mode in long mode.
Change-Id: Iea8113376b95ec068a459cb8f3d0e77d3e2340f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/630116
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>
This CL rolls forward CL 630276, fixing the issues with the longtest builders that required the revert in CL 630317.
The change this CL makes compared to CL 630276 is adding the
shortPathErrorList function to rewrite the paths in the modfile.Errors
in a modfile.ErrorList using base.ShortPath and calling it on the error
returned from modfile.Parse.
The following is the commit message from the original change:
This CL first removes the base.ShortPathConservative function. It had
two classes of uses. The first was in opening files where the paths end
up in error messages. In all those cases, the non-shortened paths are
used to open the files, and ShortPath is only used for the error
messages. The second is in base.RelPaths. RelPaths will now call
ShortPath for each of the paths passed in instead of calling
RelConservative and then doing the same check as ShortPath to see if the
path is shorter.
To avoid the possibility of incorrect relative paths ending up in error
messages (that might have command lines suggested for users to run), and
to avoid the possibility of incorrect relative paths appearing in the
output of base.RelPaths, base.ShortPaths always does an os.SameFile
check to make sure that the relative path its providing is actually
correct. Since this makes ShortPath slower than just manipulating paths
(because we need to stat the files), we need to be continue to enforce
that ShortPath is only called for error messages (with the exception of
base.RelPaths and its callers).
This is a simpler way of solving the problem that base.ShortPaths
intended to solve.
For #68383
Change-Id: Ibcefb343535bd82999916b2282e9b512bb683433
Cq-Include-Trybots: luci.golang.try:gotip-windows-amd64-longtest,gotip-linux-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/630280
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
This change implements executable caching. It always caches the outputs of
link steps used by go run. To do so we need to make a few changes:
The first is that we want to cache binaries in a slightly different
location than we cache other outputs. The reason for doing so is so that
the name of the file could be the name of the program built. Instead of
placing the files in $GOCACHE/<two digit prefix>/<hash>-d, we place them
in $GOCACHE/<two digit prefix>/<hash>-d/<executable name>. This is done
by adding a new function called PutExecutable that works differently
from Put in two ways: first, it causes the binaries to written 0777
rather than 0666 so they can be executed. Second, PutExecutable also
writes its outputs to a new location in a directory with the output id
based name, with the file named based on p.Internal.ExeName or otherwise
the base name of the package (plus the .exe suffix on Windows).
The next changes are for writing and reading binaries from the cache. In
cmd/go/internal/work.updateBuildID, which updates build ids to the
content based id and then writes outputs to the cache, we first make the
change to always write the content based id into a binary. This is
because we won't be throwing the binaries away after running them. Then,
if the action is a link action, and we enabled excutable caching for the
action, we write the output to the binary cache.
When reading binaries, in the useCache function, we switch to using the
binary cache, and we also print the cached link outputs (which are
stored using the build action's action id).
Finally, we change go run to execute the built output from the cache.
The support for caching tools defined in a module that are run by go
tool will also use this functionality.
Fixes#69290
For #48429
Change-Id: Ic5f1d3b29d8e9786fd0d564460e3a5f53e951f41
Reviewed-on: https://go-review.googlesource.com/c/go/+/613095
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Use similar SIMD operations to the ones used in Abseil. We still
using 8-slot groups (even though the XMM registers could handle 16-slot
groups) to keep the implementation simpler (no changes to the memory
layout of maps).
Still, the implementations of matchH2 and matchEmpty are shorter than
the portable version using standard arithmetic operations. They also
return a packed bitset, which avoids the need to shift in bitset.first.
That said, the packed bitset is a downside in cognitive complexity, as
we have to think about two different possible representations. This
doesn't leak out of the API, but we do need to intrinsify bitset to
switch to a compatible implementation.
The compiler's intrinsics don't support intrinsifying methods, so the
implementations move to free functions.
This makes operations between 0-3% faster on my machine. e.g.,
MapGetHit/impl=runtimeMap/t=Int64/len=6-12 12.34n ± 1% 11.42n ± 1% -7.46% (p=0.000 n=25)
MapGetHit/impl=runtimeMap/t=Int64/len=12-12 15.14n ± 2% 14.88n ± 1% -1.72% (p=0.009 n=25)
MapGetHit/impl=runtimeMap/t=Int64/len=18-12 15.04n ± 6% 14.66n ± 2% -2.53% (p=0.000 n=25)
MapGetHit/impl=runtimeMap/t=Int64/len=24-12 15.80n ± 1% 15.48n ± 3% ~ (p=0.444 n=25)
MapGetHit/impl=runtimeMap/t=Int64/len=30-12 15.55n ± 4% 14.77n ± 3% -5.02% (p=0.004 n=25)
MapGetHit/impl=runtimeMap/t=Int64/len=64-12 15.26n ± 1% 15.05n ± 1% ~ (p=0.055 n=25)
MapGetHit/impl=runtimeMap/t=Int64/len=128-12 15.34n ± 1% 15.02n ± 2% -2.09% (p=0.000 n=25)
MapGetHit/impl=runtimeMap/t=Int64/len=256-12 15.42n ± 1% 15.15n ± 1% -1.75% (p=0.001 n=25)
MapGetHit/impl=runtimeMap/t=Int64/len=512-12 15.48n ± 1% 15.18n ± 1% -1.94% (p=0.000 n=25)
MapGetHit/impl=runtimeMap/t=Int64/len=1024-12 17.38n ± 1% 17.05n ± 1% -1.90% (p=0.000 n=25)
MapGetHit/impl=runtimeMap/t=Int64/len=2048-12 17.96n ± 0% 17.59n ± 1% -2.06% (p=0.000 n=25)
MapGetHit/impl=runtimeMap/t=Int64/len=4096-12 18.36n ± 1% 18.18n ± 1% -0.98% (p=0.013 n=25)
MapGetHit/impl=runtimeMap/t=Int64/len=8192-12 18.75n ± 0% 18.31n ± 1% -2.35% (p=0.000 n=25)
MapGetHit/impl=runtimeMap/t=Int64/len=65536-12 26.25n ± 0% 25.95n ± 1% -1.14% (p=0.000 n=25)
MapGetHit/impl=runtimeMap/t=Int64/len=262144-12 44.24n ± 1% 44.06n ± 1% ~ (p=0.181 n=25)
MapGetHit/impl=runtimeMap/t=Int64/len=1048576-12 85.02n ± 0% 85.35n ± 0% +0.39% (p=0.032 n=25)
MapGetHit/impl=runtimeMap/t=Int64/len=4194304-12 98.87n ± 1% 98.85n ± 1% ~ (p=0.799 n=25)
For #54766.
Cq-Include-Trybots: luci.golang.try:gotip-linux-ppc64_power10,gotip-linux-amd64-goamd64v3
Change-Id: Ic1b852f02744404122cb3672900fd95f4625905e
Reviewed-on: https://go-review.googlesource.com/c/go/+/626277
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>
Reviewed-by: Keith Randall <khr@google.com>
runtime.hmap never directly refers to the bucket type (it uses an
unsafe.Pointer), thus it shouldn't be possible to have infinite
recursion here.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-linux-amd64-longtest-race,gotip-linux-amd64-longtest-aliastypeparams
Change-Id: I457885e48bbc352acedae1c0c389078f39ed9d65
Reviewed-on: https://go-review.googlesource.com/c/go/+/619037
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
This CL first removes the base.ShortPathConservative function. It had
two classes of uses. The first was in opening files where the paths end
up in error messages. In all those cases, the non-shortened paths are
used to open the files, and ShortPath is only used for the error
messages. The second is in base.RelPaths. RelPaths will now call
ShortPath for each of the paths passed in instead of calling
RelConservative and then doing the same check as ShortPath to see if the
path is shorter.
To avoid the possibility of incorrect relative paths ending up in error
messages (that might have command lines suggested for users to run), and
to avoid the possibility of incorrect relative paths appearing in the
output of base.RelPaths, base.ShortPaths always does an os.SameFile
check to make sure that the relative path its providing is actually
correct. Since this makes ShortPath slower than just manipulating paths
(because we need to stat the files), we need to be continue to enforce
that ShortPath is only called for error messages (with the exception of
base.RelPaths and its callers).
This is a simpler way of solving the problem that base.ShortPaths
intended to solve.
For #68383
Change-Id: I474f464f51a9acb2250069dea3054b55d95a4ab4
Reviewed-on: https://go-review.googlesource.com/c/go/+/630276
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
Sometimes we've used the 140 suffix (GOFIPS140, crypto/fips140)
and sometimes not (crypto/internal/fips, cmd/go/internal/fips).
Use it always, to avoid having to remember which is which.
Also, there are other FIPS standards, like AES (FIPS 197), SHA-2 (FIPS 180),
and so on, which have nothing to do with FIPS 140. Best to be clear.
For #70123.
Change-Id: I33b29dabd9e8b2703d2af25e428f88bc81c7c307
Reviewed-on: https://go-review.googlesource.com/c/go/+/630115
Reviewed-by: Filippo Valsorda <filippo@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
This makes methods on aliases of cgo-generated types a new compiler error.
That is ok because cgo-behavior is not covered by the G1 compatibility
guarantee.
Background: In 2023 we fixed a gopls issue related to this by actually
enabling methods on cgo-generated types in the first place (#59944).
See the discussion in #60725 and this CL for why we believe it is ok
to make this an error now.
Based on a variation of CL 503596 (by Xie Cui).
Fixes#60725.
For #59944.
Change-Id: I7e9e6e1a76447167483a282b268f5183214027c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/629715
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
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>
If the receiver is an alias declaring type parameters, report
an error and ensure that the receiver type remains invalid.
Collect type parameters etc. as before but do not attempt to
find their constraints or instantiate the receiver type.
The constraints of the type parameters will be invalid by
default. The receiver type will not be (lazily) instantiated
which causes problems with existing invariants.
If a receiver denotes an instantiated (alias or defined) type,
report an error and ensure that the receiver type remains invalid.
While at it, add more comments and bring go/types and types2
closer together where there were differences.
Fixes#70417.
Change-Id: I87ef0b42d2f70464664cacc410f4b7eb1c994241
Reviewed-on: https://go-review.googlesource.com/c/go/+/629080
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
getOrAddWeakHandle is very careful about keeping its input alive across
the operation, but not very careful about keeping the heap-allocated
handle it creates alive. In fact, there's a window in this function
where it is *only* visible via the special. Specifically, the window of
time between when the handle is stored in the special and when the
special actually becomes visible to the GC.
(If we fail to add the special because it already exists, that case is
fine. We don't even use the same handle value, but the one we obtain
from the attached GC-visible special, *and* we return that value, so it
remains live.)
Fixes#70455.
Change-Id: Iadaff0cfb93bcaf61ba2b05be7fa0519c481de82
Reviewed-on: https://go-review.googlesource.com/c/go/+/630315
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
GenerateKey(nil) is documented to use crypto/rand.Reader, but we didn't
have a test.
While at it, since it's documented to be equivalent to NewKeyFromSeed,
actually implement it that way. This has the probably good side effect
of making it deterministic in FIPS mode. The other GenerateKey use
MaybeReadByte, so can change, but this one is probably worth keeping
deterministic. It's just slightly less compliant, but ok as long as
crypto/rand.Reader is the default one.
Intentionally leaving crypto/internal/fips/ed25519.GenerateKey in, in
case we need to switch to it during the life of the module.
Change-Id: Ic203436ff452bb9740291b9ca17f85aa6ae20b6e
Reviewed-on: https://go-review.googlesource.com/c/go/+/630099
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: Dmitri Shuralyov <dmitshur@google.com>
If cmd/compile is in an unhappy state, the testdir test can
fail with an unhelpful 'exit code 1' log message if
'go list' fails while gathering stdlib import config
When running individual files, such as:
go test cmd/internal/testdir -run='Test/escape.*.go'
This might also happen in other uses, or it might be
that a more expansive set of tests such as run.bash
might first trigger a more useful error.
This change prints stderr and states that it is 'go list'
that is having problems to help someone track down the
proper issue.
Change-Id: Iba658ea139bb9087ab8adb00c9f65080a1b6ee76
Reviewed-on: https://go-review.googlesource.com/c/go/+/524941
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Currently on Windows, commands like:
go test cmd/internal/testdir -run=foo -update_errors
will fail to update the errors because the parsing is
currently confused by the ':' in filepaths that
start with 'C:\', and wrongly thinks that ':' marks
the end of the Go filename.
Instead of finding the first ':', use a regexp
to find what looks to be the end of the Go filename.
Change-Id: I091106da55b8e9e9cf421814abf26a6f8b821af9
Reviewed-on: https://go-review.googlesource.com/c/go/+/524942
Reviewed-by: Russ Cox <rsc@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
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>
GOFIPS140 does two things: (1) control whether to build binaries that
run in FIPS-140 mode by default, and (2) control which version of the
crypto/internal/fips source tree to use during a build.
This CL implements part (2). The older snapshot source trees are
stored in GOROOT/lib/fips140 in module-formatted zip files,
even though crypto/internal/fips is not technically a module.
(Reusing the module packing and unpacking code avoids reinventing it.)
See cmd/go/internal/fips/fips.go for an overview.
The documentation for GOFIPS140 is in a follow-up CL.
For #70200.
Change-Id: I73a610fd2c9ff66d0cced37d51acd8053497238e
Reviewed-on: https://go-review.googlesource.com/c/go/+/629201
Reviewed-by: Michael Matloob <matloob@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
In Loongson's new microstructure LA664 (Loongson-3A6000) and later, the atomic
instruction AMSWAP[DB]{B,H} [1] is supported. Therefore, the implementation of
the atomic operation exchange can be selected according to the CPUCFG flag LAM_BH:
AMSWAPDBB(full barrier) instruction is used on new microstructures, and traditional
LL-SC is used on LA464 (Loongson-3A5000) and older microstructures. This can
significantly improve the performance of Go programs on new microstructures.
Because Xchg8 implemented using traditional LL-SC uses too many temporary
registers, it is not suitable for intrinsics.
goos: linux
goarch: loong64
pkg: internal/runtime/atomic
cpu: Loongson-3A6000 @ 2500.00MHz
BenchmarkXchg8 100000000 10.41 ns/op
BenchmarkXchg8-2 100000000 10.41 ns/op
BenchmarkXchg8-4 100000000 10.41 ns/op
BenchmarkXchg8Parallel 96647592 12.41 ns/op
BenchmarkXchg8Parallel-2 58376136 20.60 ns/op
BenchmarkXchg8Parallel-4 78458899 17.97 ns/op
goos: linux
goarch: loong64
pkg: internal/runtime/atomic
cpu: Loongson-3A5000-HV @ 2500.00MHz
BenchmarkXchg8 38323825 31.23 ns/op
BenchmarkXchg8-2 38368219 31.23 ns/op
BenchmarkXchg8-4 37154156 31.26 ns/op
BenchmarkXchg8Parallel 37908301 31.63 ns/op
BenchmarkXchg8Parallel-2 30413440 39.42 ns/op
BenchmarkXchg8Parallel-4 30737626 39.03 ns/op
For #69735
[1]: https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html
Change-Id: I02ba68f66a2210b6902344fdc9975eb62de728ab
Reviewed-on: https://go-review.googlesource.com/c/go/+/623058
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: sophie zhao <zhaoxiaolin@loongson.cn>
Reviewed-by: Meidan Li <limeidan@loongson.cn>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Mauri de Souza Meneguzzo <mauri870@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Left most of the tests in for now as they are almost all internal and
hard to externalize.
String initialization in the FIPS module has some issues, so switched
field.TestSqrtRatio to storing decoded byte slices instead.
For #69536
Change-Id: If9e4a2bb780a37a8d102a22ffd13c5293d11a8a6
Reviewed-on: https://go-review.googlesource.com/c/go/+/628776
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Bypass: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Since ECDSA private keys are irredeemably malleable, an application
could construct one where the public key doesn't match the private key.
They'd be very much on their own, but crashing the program feels a bit
harsh.
Add this one to the list of issues caused by exposing the ECDSA (and
RSA) key values as big.Ints.
For #69536
Change-Id: Iaa65c73d7145e74f860ca097fa9641448442fbf9
Reviewed-on: https://go-review.googlesource.com/c/go/+/628855
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This has the important advantage of using the system GOMODCACHE when it
exists, avoiding the download on every "go test".
While at it, also consistently use testenv.Command.
Change-Id: Ic999ffa281f6da73fe601b0feba29e60982cce3d
Reviewed-on: https://go-review.googlesource.com/c/go/+/628755
Reviewed-by: Russ Cox <rsc@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
TryBot-Bypass: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
For the future, some test vectors we should generate and then share
through Wycheproof or CCTV:
- A private key with a leading zero byte.
- A hash longer than the modulus.
- A hash longer than the P-521 modulus by a few bits.
- Reductions happening in hashToNat and bits2octets.
Fixes#64802
Change-Id: Ia0f89781b2c78eedd5103cf0e9720630711c37ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/628681
TryBot-Bypass: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
This intentionally gives up on the property of not computing the public
key until requested. It was nice, but it was making the code too
complex. The average use case is to call PublicKey immediately after
GenerateKey anyway.
Added support in the module for P-224, just in case we'd ever want to
support it in crypto/ecdh.
Tried various ways to fix test/fixedbugs/issue52193.go to be meaningful,
but crypto/ecdh is pretty complex and all the solutions would end up
locking in crypto/ecdh structure rather than compiler behavior. The rest
of that test is good enough on its own anyway. If we do the work in the
future of making crypto/ecdh zero-allocations using the affordances of
the compiler, we can add a more robust TestAllocations on our side.
For #69536
Change-Id: I68ac3955180cb31f6f96a0ef57604aaed88ab311
Reviewed-on: https://go-review.googlesource.com/c/go/+/628315
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Russ Cox <rsc@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The affine addition formula is significantly faster, and sets us up to
reuse the precomputed table from the assembly implementation.
This is an incremental step towards converging the purego and assembly
implementations, with the goal of eventually merging them.
Very proud of how the conditional AddAffine avoids the whole zero/sel
cmov dance, compared to the same logic in the assembly implementation.
Change-Id: Iab008e81869cf8c1565b938e4dd392dd4d5787fd
Reviewed-on: https://go-review.googlesource.com/c/go/+/627938
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
As explained in fips_test.go, we generally want to minimize tests inside
the FIPS module. When there is a relevant calling package, the tests
should go there, otherwise in fipstest.
This required redoing a bit the CAST failure tests, but the new version
is actually more robust because it will fail if a _ import is missing.
Since TestCAST doesn't print a line for each passed CAST anymore, made
GODEBUG=fips140=debug do that, in case we need to show it to the lab.
For #69536
Change-Id: I0c1b82a4e9ee39e8df9bbe95bebb0527753f51c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/627955
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Dmitri Shuralyov <dmitshur@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>
GOFIPS140 does two things: (1) control whether to build binaries that
run in FIPS-140 mode by default, and (2) control which version of the
crypto/internal/fips source tree to use during a build.
This CL implements part (1). It recognizes the GOFIPS140 settings
"off" and "latest" and uses them to set the default GODEBUG=fips140
setting to "off" or "on" accordingly.
The documentation for GOFIPS140 is in a follow-up CL.
See cmd/go/internal/fips/fips.go for an overview.
For #70200.
Change-Id: I045f8ae0f19778a1e72a5cd2b6a7b0c88934fc30
Reviewed-on: https://go-review.googlesource.com/c/go/+/629198
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Hashing the key means we have to take the address of it. That inhibits
subsequent optimizations on the key variable.
By hashing a copy, we incur an extra store at the hash callsite, but
we no longer need a load of the key in the inner loop. It can live
in a register throughout. (Technically, it gets spilled around
the call to the hasher, but it gets restored outside the loop.)
Maybe one day we can have special hash functions that take
int64/int32/string instead of *int64/*int32/*string.
Change-Id: Iba3133f6e82328f53c0abcb5eec13ee47c4969d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/629419
Reviewed-by: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Instead of open-coding the waitid syscall wrapper add it to
internal/syscall/unix. As the syscall is currently only used on Linux,
switch the implementation in os.(*Process).blockUntilWaitable to use the
128-byte unix.SiginfoChild type instead of a plain 128-byte buffer.
Also use ignoringEINTR for the waitid calls instead of open-coding it.
Change-Id: I8dc47e361faa1f5e912d5de021f119c91c9f12f5
Reviewed-on: https://go-review.googlesource.com/c/go/+/629655
Reviewed-by: Dmitri Shuralyov <dmitshur@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: Tobias Klauser <tobias.klauser@gmail.com>
Add an internal (for now) implementation of testing/synctest.
The synctest.Run function executes a tree of goroutines in an
isolated environment using a fake clock. The synctest.Wait function
allows a test to wait for all other goroutines within the test
to reach a blocking point.
For #67434
For #69687
Change-Id: Icb39e54c54cece96517e58ef9cfb18bf68506cfc
Reviewed-on: https://go-review.googlesource.com/c/go/+/591997
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
During the development of error wrapping (#29934),
the tests were modified to stop using reflect.DeepEqual
since the prototype for error wrapping at the time included
frame information of where the error was created.
However, that change diminished the fidelity of the test
so that it is no longer as strict, which affects the endeavor
to implement v1 in terms of the v2 prototype.
For locally declared error types, use reflect.DeepEqual
to check that the exact structure of the error value matches.
Change-Id: I443d418533866ab8d533bca3785fdc741e2c140e
Reviewed-on: https://go-review.googlesource.com/c/go/+/629517
Auto-Submit: Damien Neil <dneil@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
GOFIPS140 will be used to control whether to build binaries that
run in FIPS-140 mode by default, as well as which version of
crypto/internal/fips is used during a given build.
It is a target configuration variable analogous to
GOOS, GOARCH, CGO_ENABLED, and the like, so the
default value is recorded in the toolchain during make.bash.
This CL adds the GOFIPS140 setting to the build process
and records the default for use by cmd/go.
For #70200.
Change-Id: Iafcb5a4207f00fae8bcd93e0184a63c72526abea
Reviewed-on: https://go-review.googlesource.com/c/go/+/629196
Reviewed-by: Michael Matloob <matloob@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
fsys.Bind(repl, dir) makes the virtual file system
redirect any references to dir to use repl instead.
In Plan 9 terms, it binds repl onto dir.
In Linux terms, it does a mount --bind of repl onto dir.
Or think of it as being like a symlink dir -> repl being
added to the virtual file system.
This is a separate layer from the overlay so that editors
working in the replacement directory can still apply
their own replacements within that tree, and also so
that editors working in the original dir do not have any
effect at all.
(If the binds and the overlay were in the same sorted list,
we'd have problems with keeping the relative priorities
of individual entries correct.)
Change-Id: Ibc88021cc95a3b8574efd5f37772ccb723aa8f7b
Reviewed-on: https://go-review.googlesource.com/c/go/+/628702
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Code like x := [12]byte{1,2,3,4,5,6,7,8,9,10,11,12} stores x in
a pair of registers and uses MOVD/MOVWU to load the values
from RODATA. The code generator needs to understand not
to use the aligned PC-relative relocation for that sequence.
In non-FIPS modes, more statictemp optimizations can be applied
and this problematic sequence doesn't happen.
Fix the decision about whether to assume alignment to match
the code used by the linker when deciding what to align.
Fixes the linker failure in CL 626437 patch set 5.
Change-Id: Iedad862c6faee758d4a2c5120cab2d329265b134
Reviewed-on: https://go-review.googlesource.com/c/go/+/628835
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Bypass: Russ Cox <rsc@golang.org>
Add a new function, WithDataIndependentTiming, which takes a function as
an argument, and encloses it with calls to set/unset the DIT PSTATE bit
on Arm64.
Since DIT is OS thread-local, for the duration of the execution of
WithDataIndependentTiming, we lock the goroutine to the OS thread, using
LockOSThread. For long running operations, this is likely to not be
performant, but we expect this to be tightly scoped around cryptographic
operations that have bounded execution times.
If locking to the OS thread turns out to be too slow, another option is
to add a bit to the g state indicating if a goroutine has DIT enabled,
and then have the scheduler enable/disable DIT when scheduling a g.
Additionally, we add a new GODEBUG, dataindependenttiming, which allows
setting DIT for an entire program. Running a program with
dataindependenttiming=1 enables DIT for the program during
initialization. In an ideal world PSTATE.DIT would be inherited from
the parent thread, so we'd only need to set it in the main thread and
then all subsequent threads would inherit the value. While this does
happen in the Linux kernel [0], it is not the case for darwin [1].
Rather than add complex logic to only set it on darwin for each new
thread, we just unconditionally set it in mstart1 and cgocallbackg1
regardless of the OS. DIT will already impose some overhead, and the
cost of setting the bit is only ~two instructions (CALL, MSR), so it
should be cheap enough.
Fixes#66450
Updates #49702
[0] e8bdb3c8be/arch/arm64/kernel/process.c (L373)
[1] 8d741a5de7/osfmk/arm64/status.c (L1666)
Change-Id: I78eda691ff9254b0415f2b54770e5850a0179749
Reviewed-on: https://go-review.googlesource.com/c/go/+/598336
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Replace the tree of nodes with a sorted list of file replacements.
The most important property of this representation is that it
allows replacing directories: a replacement x -> y where y is
a directory could not be implemented before, because it would
require making a node for every file in the tree rooted at y,
or else it would require unsuccessful lookups for files like
x/a/b/c/d/e/f/g/h/i/j/k to try every possible parent in order
to discover the x -> y mapping.
The sorted list makes it easy to find the x -> y mapping:
when you do the binary search for x/a/b/c/d/e/f/g/h/i/j/k,
you end up immediately after the x -> y mapping, so stepping
backward one entry provides the mapping we need, if it exists.
This CL does not allow overlay files to include directories,
but now it is possible. This is at least useful for other kinds
of experiments (like FIPS).
Change-Id: Ief0afaee82e644dab8ae4eafeec20440afee2e36
Reviewed-on: https://go-review.googlesource.com/c/go/+/628701
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
These are most likely redundant, but cmd/compile/internal/amd64's
TestGoAMD64v1 turns them off when clobbering those instructions, so we
need to know to skip the assembly in those cases.
Thankfully we have Avo now that adds a helpful comment with the list of
features used by each generated function!
Also improve the error output of TestGoAMD64v1. It had broken before in
#49402 and had required the exact same patch.
Change-Id: I7fab8f36042cdff630f806723aa1d8124c294f60
Reviewed-on: https://go-review.googlesource.com/c/go/+/626876
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Refactor vfs lookup into 'func stat', which knows the internal
data structures for the vfs and returns information about a
given path. The callers can then all use stat and avoid direct
knowledge of the internal data structures.
This is setting up for a different internal data structure.
Change-Id: I496b7b3fb686cdde81b14687f65eb0bf51ec62be
Reviewed-on: https://go-review.googlesource.com/c/go/+/628699
Auto-Submit: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Many releases ago we migrated
from ioutil.ReadDir, which returned []os.FileInfo,
to os.ReadDir, which returns []fs.DirEntry.
The latter is faster, but the former is expected by go/build.Context.
Convert fsys to use the new ReadDir signature.
This should make the go command faster when scanning
source trees, and it brings cmd/go up to date with the rest
of the tree.
Similarly, convert Walk to WalkDir.
Change-Id: I767a8548d7ca7cc3c05f2ff073d18070a4e8a0da
Reviewed-on: https://go-review.googlesource.com/c/go/+/628698
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
TryBot-Bypass: Russ Cox <rsc@golang.org>
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
Rename canonicalize to abs.
Rename IsDirWithGoFiles to IsGoDir.
Remove Init argument.
Split OverlayPath into Actual and Renamed.
Clean up doc comments.
Other minor cleanups.
Preparation for larger changes.
Change-Id: Ida022588149a1618a63acc91e3800b09df873b6e
Reviewed-on: https://go-review.googlesource.com/c/go/+/628697
TryBot-Bypass: Russ Cox <rsc@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
The Glob and Walk code does not depend on any of the fsys internals;
it simply uses ReadDir as an opaque abstraction.
Move it to separate files so that when working on the
actual overlay abstraction, it is out of sight, out of mind.
Change-Id: Ifa98feaaaafe5c1d8d8edce82de4fd0c78f599c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/628696
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
TryBot-Bypass: Russ Cox <rsc@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
This re-enables the behavior of CL 536399 (by effectively reverting CL
628955), so now go test -json again includes build output and failures
as JSON rather than text.
However, since this behavior is clearly enough to trip up some build
systems, this CL includes a GODEBUG=gotestjsonbuildtext that can be
set to 1 to revert to the old behavior.
Fixes#70402.
Updates #62067.
Cq-Include-Trybots: luci.golang.try:gotip-darwin-arm64_13,gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Change-Id: I84e778cd844783dacfc83433e391b5ccb5925127
Reviewed-on: https://go-review.googlesource.com/c/go/+/629335
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>
Auto-Submit: Austin Clements <austin@google.com>
This is thought to be the cause of certain recent longtest failures.
Let's try it out.
This appears to fix the longtests fuzz failures. I suspect that the
sync.Map in internal/godebug is at fault with the implementation
changing. I'm not sure yet exactly why this is a problem, maybe inlining
that didn't happen before? I don't know exactly when coverage
instrumentation happens in the compiler, but this is definitely the
problem.
For good measure, let's add internal/sync. If sync is on the list,
internal/sync should be, too.
Fixes#70429.
Fixes#70430.
Fixes#70431.
Change-Id: Ic9f49daa0956e3a50192bcc7778983682b5d12b8
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/629475
Reviewed-by: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
[ ]
[ It has been [ 0 ] days since Filippo broke a TestAllocations. ]
[ ]
Concentrate all the skips in one place, so we don't have to re-discover
always the same ones via trial and error.
This might over-skip fixable allocations, but all these targets are not
fast anyway, so they are not worth going back for.
Removed the sysrand TestAllocations because it causes an import loop
with cryptotest and it's covered by TestAllocations in crypto/rand.
Change-Id: Icd40e97f9128e037f567147f8c9dafa758a47fac
Reviewed-on: https://go-review.googlesource.com/c/go/+/626438
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
The crypto/aes <-> crypto/cipher interfaces and the hardware support
upgrades were layered over the years, and had grown unwieldily.
Before: conditionally wrap the private crypto/aes type in private types
that implement an interface that's interface-upgraded by crypto/cipher
to replace the generic implementation in crypto/cipher.
crypto/aes depended on crypto/cipher, which is backwards.
After: provide concrete exported implementations of modes in
crypto/internal/fips/aes that crypto/cipher returns if the input Block
is the crypto/internal/fips/aes concrete implementation.
crypto/aes and crypto/cipher both depend on crypto/internal/fips/aes.
Also, made everything follow go.dev/wiki/TargetSpecific by only putting
the minimal code necessary and no exported functions in build-tagged
files.
The GCM integration still uses an interface upgrade, because the generic
implementation is complex enough that it was not trivial to duplicate.
This will be fixed in a future CL to make review easier.
For #69536
Change-Id: I21c2b93a498edb31c562b1aca824e21e8457fdff
Reviewed-on: https://go-review.googlesource.com/c/go/+/624395
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
The implementation runs up to 8 AES instructions in different registers
one after another in ASM code. Because CPU has instruction pipelining
and the instructions do not depend on each other, they can run in
parallel with this layout of code. This results in significant speedup
compared to the regular implementation in which blocks are processed in
the same registers so AES instructions do not run in parallel.
GCM mode already utilizes the approach.
The ASM implementation of ctrAble has most of its code in XORKeyStreamAt
method which has an additional argument, offset. It allows to use it
in a stateless way and to jump to any location in the stream. The method
does not exist in pure Go and boringcrypto implementations.
[ Mailed as CL 413594, then edited by filippo@ to manage the counter
with bits.Add64, remove bounds checks, make the assembly interface more
explicit, and to port the amd64 to Avo. Squeezed another -6.38% out. ]
goos: linux
goarch: amd64
pkg: crypto/cipher
cpu: AMD Ryzen 7 PRO 8700GE w/ Radeon 780M Graphics
│ 19df80d792 │ c8b0409d40 │
│ sec/op │ sec/op vs base │
AESCTR/50-8 64.68n ± 0% 26.89n ± 0% -58.42% (p=0.000 n=10)
AESCTR/1K-8 1145.0n ± 0% 135.8n ± 0% -88.14% (p=0.000 n=10)
AESCTR/8K-8 9145.0n ± 0% 917.5n ± 0% -89.97% (p=0.000 n=10)
geomean 878.2n 149.6n -82.96%
│ 19df80d792 │ c8b0409d40 │
│ B/s │ B/s vs base │
AESCTR/50-8 737.2Mi ± 0% 1773.3Mi ± 0% +140.54% (p=0.000 n=10)
AESCTR/1K-8 848.5Mi ± 0% 7156.6Mi ± 0% +743.40% (p=0.000 n=10)
AESCTR/8K-8 853.8Mi ± 0% 8509.9Mi ± 0% +896.70% (p=0.000 n=10)
geomean 811.4Mi 4.651Gi +486.94%
Fixes#20967
Updates #39365
Updates #26673
Co-authored-by: Filippo Valsorda <filippo@golang.org>
Change-Id: Iaeea29fb93a56456f2e54507bc25196edb31b84b
Reviewed-on: https://go-review.googlesource.com/c/go/+/621958
Auto-Submit: 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>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
This tweaks the inlining cost knob for closures
specifically, they receive a doubled budget. The
rationale for this is that closures have a lot of
"crud" in their IR that will disappear after inlining,
so the standard budget penalizes them unnecessarily.
This is also the cause of these bugs -- looking at the
code involved, these closures "should" be inlineable,
therefore tweak the parameters until behavior matches
expectations. It's not costly in binary size, because
the only-called-from-one-site case is common (especially
for rangefunc iterators).
I can imagine better fixes and I am going to try to
get that done, but this one is small and makes things
better.
Fixes#69411, #69539.
Change-Id: I8a892c40323173a723799e0ddad69dcc2724a8f9
Reviewed-on: https://go-review.googlesource.com/c/go/+/629195
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The linker knows the types of the global variables. We can use those
types to build the GC programs that describe the data and bss pointer masks.
That way we don't use the GC programs of the constituent types.
This is part of an effort to remove GC programs from the runtime.
There's a major complication in that when we're linking against a
shared library (typically, libstd.so), the relocations we need to
break apart arrays and structs into constituent types are difficult to
find. Load that additional data when linking against shared libraries.
Change-Id: I8516b24a0604479895c7b8a8a358d3cd8d421530
Reviewed-on: https://go-review.googlesource.com/c/go/+/546216
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>
This change adds a GOEXPERIMENT, synchashtriemap, which replaces the
internals of a sync.Map with internal/sync.HashTrieMap[any, any]. The
main purpose behind this change is improved performance. Across almost
every benchmark, HashTrieMap[any, any] performs better than Map.
Also, relax TestMapClearNoAllocations to allow for one allocation.
Currently, the HashTrieMap allocates a new empty root node and stores
it: that's the whole clear operation. At the cost of some complexity, we
could allow Clear to have zero allocations by clearing the root node.
The complexity comes down to allowing threads to race to install a new
root node *or* creating a top-level mutex for installing a root node.
But I'm not sure this is worth it. Whether Clear or some other operation
takes the hit for allocating a single node almost certainly doesn't
matter. And Clear is still much, much faster in the new implementation
than the old, so I don't consider this a regression.
Change-Id: I939aa70a0edf2e850cedbea239aaf29a11a77b79
Reviewed-on: https://go-review.googlesource.com/c/go/+/608335
Auto-Submit: 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>
We observe the CompareAndSwap and Swap can both be substantially faster
if the value in each entry node is mutable. This change modifies the
map entry node to store the value indirectly, allowing us to perform
swaps for existing nodes and compare-and-swaps without taking the
parent node's lock.
Change-Id: I371343aa81a843d3a7e6bc5ac87b8a96c12ca3a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/606462
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>
Currently the HashTrieMap requires both keys and values to be
comparable, but it's actually OK if the value is not comparable. Some
operations may fail, but others will not, and we can check comparability
dynamically on map initialization. This makes the implementation
substantially more flexible.
Change-Id: Idc9c30dfa273d80ae4d46a9eefb5c155294408aa
Reviewed-on: https://go-review.googlesource.com/c/go/+/594061
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: David Chase <drchase@google.com>
This CL refactors sync.Mutex such that its implementation lives in the
new internal/sync package. The purpose of this change is to eventually
reverse the dependency edge between internal/concurrent and sync, such
that sync can depend on internal/concurrent (or really, its contents,
which will likely end up in internal/sync).
The only change made to the sync.Mutex code is the frame skip count for
mutex profiling, so that the internal/sync frames are omitted in the
profile.
Change-Id: Ib3603d30e8e71508c4ea883a584ae2e51ce40c3f
Reviewed-on: https://go-review.googlesource.com/c/go/+/594056
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>
FreeBSD and Dragonfly have used the sysctl method for years, while
NetBSD has read the name of the executable from /proc. Unfortunately,
some folks are hitting errors when building Go software in a sandbox
that lacks a mounted /proc filesystem.
Switch NetBSD to use the same implementation as FreeBSD and Dragonfly.
Unfortunately, the order of the arguments in the MIB is also
OS-dependent.
Change-Id: I6fd774904af417ccd127e3779af45a20dc8696ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/629035
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Benny Siegert <bsiegert@gmail.com>
TryBot-Bypass: Ian Lance Taylor <iant@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Following CLs will refactor Mutex and change the internals of Map. This
ends up breaking tests in x/tools for the copylock vet check, because
the error message changes. Let's insulate ourselves from such things
permanently by adding an explicit noCopy field. We'll update the vet
check to accept that as the problem, rather than depend on less explicit
internals.
We capture Once here too to clean up the error message as well.
Change-Id: Iead985fc8ec9ef3ea5ff615f26dde17bb03aeadb
Reviewed-on: https://go-review.googlesource.com/c/go/+/627777
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>
Reviewed-by: Tim King <taking@google.com>
This is a two-pronged approach. First, try to keep large objects
off the stack frame. Second, if they do manage to appear anyway,
use straight bitmasks instead of gc programs.
Generally probably a good idea to keep large objects out of stack frames.
But particularly keeping gc programs off the stack simplifies
runtime code a bit.
This CL sets the limit of most stack objects to 131072 bytes (on 64-bit archs).
There can still be large objects if allocated by a late pass, like order, or
they are required to be on the stack, like function arguments.
But the size for the bitmasks for these objects isn't a huge deal,
as we have already have (probably several) bitmasks for the frame
liveness map itself.
Change-Id: I6d2bed0e9aa9ac7499955562c6154f9264061359
Reviewed-on: https://go-review.googlesource.com/c/go/+/542815
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>
It wasn't actually testing what it says it was testing.
A random permutation isn't cyclic. It only probably hits a few
elements before entering a cycle.
Use an algorithm that generates a random cyclic permutation instead.
Fixing the test makes the previous CL look less good. But it still helps.
(Theory: Fixing the test makes it less cache friendly, so there are
more misses all around. That makes the benchmark slower, suppressing
the differences seen. Also fixing the benchmark makes the loop
iteration count less predictable, which hurts the raw loop
implementation somewhat.)
(baseline = tip, experiment = tip+previous CL, noswiss = GOEXPERIMENT=noswissmap)
goos: darwin
goarch: arm64
pkg: runtime
cpu: Apple M2 Ultra
│ baseline │ experiment │
│ sec/op │ sec/op vs base │
MapCycle-24 20.59n ± 4% 18.99n ± 3% -7.77% (p=0.000 n=10)
khr@Mac-Studio src % benchstat noswiss experiment
goos: darwin
goarch: arm64
pkg: runtime
cpu: Apple M2 Ultra
│ noswiss │ experiment │
│ sec/op │ sec/op vs base │
MapCycle-24 16.12n ± 1% 18.99n ± 3% +17.83% (p=0.000 n=10)
Change-Id: I3a4edb814ba97fec020a6698c535ce3a87a9fc67
Reviewed-on: https://go-review.googlesource.com/c/go/+/625900
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@google.com>
XORBytes doesn't say anything about how it deals with destination and
source overlaps. Current implementations as written do work if the
destination overlaps perfectly with a source, but will unavoidably
return nonsensical results if the destination is ahead of the source.
Lock in the current behavior with tests, docs, and panics.
Note that this introduces a new panic, but if any applications run into
it we are potentially catching a security issue.
Also, expand the tests and move them outside the FIPS module per #69536
convention. (We want to minimize changes within the module boundary.)
Updates #53021
Change-Id: Ibb0875fd38da3818079e31b83b1a227b53755930
Reviewed-on: https://go-review.googlesource.com/c/go/+/622276
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently, the Printer interface has `Output`, which acts like Print
and `Errorf`, which acts like Printf. It's confusing that the
formatting style is tied to whether it's regular output or an error.
Fix this by replacing Output with Printf, so both use Printf-style
formatting.
Change-Id: I4c76f941e956f2599c5620b455bf41e21636b44e
Reviewed-on: https://go-review.googlesource.com/c/go/+/627795
Reviewed-by: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently, if a test or imported package fails to build during "go
test -json", the build error text will be interleaved with the JSON
output of tests. Furthermore, there’s currently no way to reliably
associate a build error with the test package or packages it affected.
This creates unnecessary friction and complexity in tools that consume
the "go test -json" output.
This CL makes "go test -json" enable JSON reporting of build errors.
It also adds a "FailedBuild" field to the "fail" TestEvent, which
gives the package ID of the package that failed to build and caused
the test to fail.
Using this, CI systems should be able to consume the entire output
stream from "go test -json" in a structured way and easily associate
build failures with test failures during reporting.
Fixes#62067.
Updates #35169.
Updates #37486.
Change-Id: I49091dcc7aa52db01fc9fa6042771633e97b8407
Reviewed-on: https://go-review.googlesource.com/c/go/+/536399
Reviewed-by: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently, each Action tracks whether it failed, which is propagated
up from dependencies. Shortly, we'll need to know the root cause if a
test fails because of a build failure. To support this, replace the
Failed boolean with a Failed *Action that tracks the root Action that
failed and caused other Actions to fail.
For #62067.
Change-Id: I8f84a51067354043ae9531a4368c6f8b11d688d5
Reviewed-on: https://go-review.googlesource.com/c/go/+/536398
Reviewed-by: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently, under *most* circumstances, if there's a package loading
error during "go test", that will get reported as a "FAIL p [setup
failed]" or "FAIL p [build failed] message and won't prevent running
unaffected test packages.
However, if there's a loading error from a non-test file in a package
listed directly on the "go test" command line, that gets reported as
an immediate fatal error, without any "FAIL" line, and without
attempting to run other tests listed on the command line. Likewise,
certain early build errors (like a package containing no Go files) are
currently immediately fatal rather than reporting a test failure.
Fix this by eliminating the check that causes that immediate failure.
This causes one minor follow-up problem: since
load.TestPackagesAndErrors was never passed a top-level package with
an error before, it doesn't currently propagate such an error to the
packages it synthesizes (even though it will propagate errors in
imported packages). Fix this by copying the error from the top-level
package into the synthesized test package while we're copying
everything else.
For #62067.
Change-Id: Icd563a3d9912256b53afd998050995e5260ebe5d
Reviewed-on: https://go-review.googlesource.com/c/go/+/558637
Reviewed-by: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
This replaces the existing Shell print function callback. The
interface also gives us a way to report build failures, which is the
other type of event that will appear in the build -json output.
This CL hooks up error reporting in two places:
- In Builder.Do, where all builder errors are reported.
- In load.CheckPackageErrors, where most loading errors are reported.
For #62067.
Change-Id: Id66a31b0d2c3786559c7d2bb376fffeffc9a66ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/536396
Reviewed-by: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Switch labelMap from map[string]string to use LabelSet as a data
structure. Optimize Labels() for the case where the keys are given in
sorted order without duplicates.
This is primarily motivated by reducing the overhead of distributed
tracing systems that use pprof labels. We have encountered cases where
users complained about the overhead relative to the rest of our
distributed tracing library code. Additionally, we see this as an
opportunity to free up hundreds of CPU cores across our fleet.
A secondary motivation is eBPF profilers that try to access pprof
labels. The current map[string]string requires them to implement Go map
access in eBPF, which is non-trivial. With the enablement of swiss maps,
this complexity is only increasing. The slice data structure introduced
in this CL will greatly lower the implementation complexity for eBPF
profilers in the future. But to be clear: This change does not imply
that the pprof label mechanism is now a stable ABI. They are still an
implementation detail and may change again in the future.
goos: darwin
goarch: arm64
pkg: runtime/pprof
cpu: Apple M1 Max
│ baseline.txt │ patch1.txt │
│ sec/op │ sec/op vs base │
Labels/set-one-10 153.50n ± 3% 75.00n ± 1% -51.14% (p=0.000 n=10)
Labels/merge-one-10 187.8n ± 1% 128.8n ± 1% -31.42% (p=0.000 n=10)
Labels/overwrite-one-10 193.1n ± 2% 102.0n ± 1% -47.18% (p=0.000 n=10)
Labels/ordered/set-many-10 502.6n ± 4% 146.1n ± 2% -70.94% (p=0.000 n=10)
Labels/ordered/merge-many-10 516.3n ± 2% 238.1n ± 1% -53.89% (p=0.000 n=10)
Labels/ordered/overwrite-many-10 569.3n ± 4% 247.6n ± 2% -56.51% (p=0.000 n=10)
Labels/unordered/set-many-10 488.9n ± 2% 308.3n ± 3% -36.94% (p=0.000 n=10)
Labels/unordered/merge-many-10 523.6n ± 1% 258.5n ± 1% -50.64% (p=0.000 n=10)
Labels/unordered/overwrite-many-10 571.4n ± 1% 412.1n ± 2% -27.89% (p=0.000 n=10)
geomean 366.8n 186.9n -49.05%
│ baseline.txt │ patch1b.txt │
│ B/op │ B/op vs base │
Labels/set-one-10 424.0 ± 0% 104.0 ± 0% -75.47% (p=0.000 n=10)
Labels/merge-one-10 424.0 ± 0% 200.0 ± 0% -52.83% (p=0.000 n=10)
Labels/overwrite-one-10 424.0 ± 0% 136.0 ± 0% -67.92% (p=0.000 n=10)
Labels/ordered/set-many-10 1344.0 ± 0% 392.0 ± 0% -70.83% (p=0.000 n=10)
Labels/ordered/merge-many-10 1184.0 ± 0% 712.0 ± 0% -39.86% (p=0.000 n=10)
Labels/ordered/overwrite-many-10 1056.0 ± 0% 712.0 ± 0% -32.58% (p=0.000 n=10)
Labels/unordered/set-many-10 1344.0 ± 0% 712.0 ± 0% -47.02% (p=0.000 n=10)
Labels/unordered/merge-many-10 1184.0 ± 0% 712.0 ± 0% -39.86% (p=0.000 n=10)
Labels/unordered/overwrite-many-10 1.031Ki ± 0% 1.008Ki ± 0% -2.27% (p=0.000 n=10)
geomean 843.1 405.1 -51.95%
│ baseline.txt │ patch1b.txt │
│ allocs/op │ allocs/op vs base │
Labels/set-one-10 5.000 ± 0% 3.000 ± 0% -40.00% (p=0.000 n=10)
Labels/merge-one-10 5.000 ± 0% 5.000 ± 0% ~ (p=1.000 n=10) ¹
Labels/overwrite-one-10 5.000 ± 0% 4.000 ± 0% -20.00% (p=0.000 n=10)
Labels/ordered/set-many-10 8.000 ± 0% 3.000 ± 0% -62.50% (p=0.000 n=10)
Labels/ordered/merge-many-10 8.000 ± 0% 5.000 ± 0% -37.50% (p=0.000 n=10)
Labels/ordered/overwrite-many-10 7.000 ± 0% 4.000 ± 0% -42.86% (p=0.000 n=10)
Labels/unordered/set-many-10 8.000 ± 0% 4.000 ± 0% -50.00% (p=0.000 n=10)
Labels/unordered/merge-many-10 8.000 ± 0% 5.000 ± 0% -37.50% (p=0.000 n=10)
Labels/unordered/overwrite-many-10 7.000 ± 0% 5.000 ± 0% -28.57% (p=0.000 n=10)
geomean 6.640 4.143 -37.60%
¹ all samples are equal
Change-Id: Ie68e960a25c2d97bcfb6239dc481832fa8a39754
Reviewed-on: https://go-review.googlesource.com/c/go/+/574516
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
This change introduces AddCleanup to the runtime package. AddCleanup attaches
a cleanup function to an pointer to an object.
The Stop method on Cleanups will be implemented in a followup CL.
AddCleanup is intended to be an incremental improvement over
SetFinalizer and will result in SetFinalizer being deprecated.
For #67535
Change-Id: I99645152e3fdcee85fcf42a4f312c6917e8aecb1
Reviewed-on: https://go-review.googlesource.com/c/go/+/627695
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
The tri-state mutex implementation (unlocked, locked, sleeping) avoids
sleep/wake syscalls when contention is low or absent, but its
performance degrades when many threads are contending for a mutex to
execute a fast critical section.
A fast critical section means frequent unlock2 calls. Each of those
finds the mutex in the "sleeping" state and so wakes a sleeping thread,
even if many other threads are already awake and in the spin loop of
lock2 attempting to acquire the mutex for themselves. Many spinning
threads means wasting energy and CPU time that could be used by other
processes on the machine. Many threads all spinning on the same cache
line leads to performance collapse.
Merge the futex- and semaphore-based mutex implementations by using a
semaphore abstraction for futex platforms. Then, add a bit to the mutex
state word that communicates whether one of the waiting threads is awake
and spinning. When threads in lock2 see the new "spinning" bit, they can
sleep immediately. In unlock2, the "spinning" bit means we can save a
syscall and not wake a sleeping thread.
This brings up the real possibility of starvation: waiting threads are
able to enter a deeper sleep than before, since one of their peers can
volunteer to be the sole "spinning" thread and thus cause unlock2 to
skip the semawakeup call. Additionally, the waiting threads form a LIFO
stack so any wakeups that do occur will target threads that have gone to
sleep most recently. Counteract those effects by periodically waking the
thread at the bottom of the stack and allowing it to spin.
Exempt sched.lock from most of the new behaviors; it's often used by
several threads in sequence to do thread-specific work, so low-latency
handoff is a priority over improved throughput.
Gate use of this implementation behind GOEXPERIMENT=spinbitmutex, so
it's easy to disable. Enable it by default on supported platforms (the
most efficient implementation requires atomic.Xchg8).
Fixes#68578
goos: linux
goarch: amd64
pkg: runtime
cpu: 13th Gen Intel(R) Core(TM) i7-13700H
│ old │ new │
│ sec/op │ sec/op vs base │
MutexContention 17.82n ± 0% 17.74n ± 0% -0.42% (p=0.000 n=10)
MutexContention-2 22.17n ± 9% 19.85n ± 12% ~ (p=0.089 n=10)
MutexContention-3 26.14n ± 14% 20.81n ± 13% -20.41% (p=0.000 n=10)
MutexContention-4 29.28n ± 8% 21.19n ± 10% -27.62% (p=0.000 n=10)
MutexContention-5 31.79n ± 2% 21.98n ± 10% -30.83% (p=0.000 n=10)
MutexContention-6 34.63n ± 1% 22.58n ± 5% -34.79% (p=0.000 n=10)
MutexContention-7 44.16n ± 2% 23.14n ± 7% -47.59% (p=0.000 n=10)
MutexContention-8 53.81n ± 3% 23.66n ± 6% -56.04% (p=0.000 n=10)
MutexContention-9 65.58n ± 4% 23.91n ± 9% -63.54% (p=0.000 n=10)
MutexContention-10 77.35n ± 3% 26.06n ± 9% -66.31% (p=0.000 n=10)
MutexContention-11 89.62n ± 1% 25.56n ± 9% -71.47% (p=0.000 n=10)
MutexContention-12 102.45n ± 2% 25.57n ± 7% -75.04% (p=0.000 n=10)
MutexContention-13 111.95n ± 1% 24.59n ± 8% -78.04% (p=0.000 n=10)
MutexContention-14 123.95n ± 3% 24.42n ± 6% -80.30% (p=0.000 n=10)
MutexContention-15 120.80n ± 10% 25.54n ± 6% -78.86% (p=0.000 n=10)
MutexContention-16 128.10n ± 25% 26.95n ± 4% -78.96% (p=0.000 n=10)
MutexContention-17 139.80n ± 18% 24.96n ± 5% -82.14% (p=0.000 n=10)
MutexContention-18 141.35n ± 7% 25.05n ± 8% -82.27% (p=0.000 n=10)
MutexContention-19 151.35n ± 18% 25.72n ± 6% -83.00% (p=0.000 n=10)
MutexContention-20 153.30n ± 20% 24.75n ± 6% -83.85% (p=0.000 n=10)
MutexHandoff/Solo-20 13.54n ± 1% 13.61n ± 4% ~ (p=0.206 n=10)
MutexHandoff/FastPingPong-20 141.3n ± 209% 164.8n ± 49% ~ (p=0.436 n=10)
MutexHandoff/SlowPingPong-20 1.572µ ± 16% 1.804µ ± 19% +14.76% (p=0.015 n=10)
geomean 74.34n 30.26n -59.30%
goos: darwin
goarch: arm64
pkg: runtime
cpu: Apple M1
│ old │ new │
│ sec/op │ sec/op vs base │
MutexContention 13.86n ± 3% 12.09n ± 3% -12.73% (p=0.000 n=10)
MutexContention-2 15.88n ± 1% 16.50n ± 2% +3.94% (p=0.001 n=10)
MutexContention-3 18.45n ± 2% 16.88n ± 2% -8.54% (p=0.000 n=10)
MutexContention-4 20.01n ± 2% 18.94n ± 18% ~ (p=0.469 n=10)
MutexContention-5 22.60n ± 1% 17.51n ± 9% -22.50% (p=0.000 n=10)
MutexContention-6 23.93n ± 2% 17.35n ± 2% -27.48% (p=0.000 n=10)
MutexContention-7 24.69n ± 1% 17.15n ± 3% -30.54% (p=0.000 n=10)
MutexContention-8 25.01n ± 1% 17.33n ± 2% -30.69% (p=0.000 n=10)
MutexHandoff/Solo-8 13.96n ± 4% 12.04n ± 4% -13.78% (p=0.000 n=10)
MutexHandoff/FastPingPong-8 68.89n ± 4% 64.62n ± 2% -6.20% (p=0.000 n=10)
MutexHandoff/SlowPingPong-8 9.698µ ± 22% 9.646µ ± 35% ~ (p=0.912 n=10)
geomean 38.20n 32.53n -14.84%
Change-Id: I0058c75eadf282d08eea7fce0d426f0518039f7c
Reviewed-on: https://go-review.googlesource.com/c/go/+/620435
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>
Auto-Submit: Rhys Hiltner <rhys.hiltner@gmail.com>
Implement sema{create,sleep,wakeup} in terms of the futex syscall when
available. Split the lock2/unlock2 implementations out of lock_sema.go
and lock_futex.go (which they shared with runtime.note) to allow
swapping in new implementations of those.
Let futex-based platforms use the semaphore-based mutex implementation.
Control that via the new "spinbitmutex" GOEXPERMENT value, disabled by
default.
This lays the groundwork for a "spinbit" mutex implementation; it does
not include the new mutex implementation.
For #68578.
Change-Id: I091289c85124212a87abec7079ecbd9e610b4270
Reviewed-on: https://go-review.googlesource.com/c/go/+/622996
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>
This is panicking on the darwin-amd64-longtest builders.
Not sure why, but it was added only to get a stack trace
during debugging. If there's still a problem, we should let
it proceed and find the real problem.
The test that was failing - internal/coverage/cfile - passes
with this CL, even when I set GODEBUG=fips140=on,
so there's hope that it will fix the longtest builders.
Change-Id: I9b3e743effdddcc0a76895922f87631527781dff
Reviewed-on: https://go-review.googlesource.com/c/go/+/628375
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
For now, FIPS does not work with ASAN: ASAN detects reads
it doesn't like during the scans of memory done by verification.
It could be made to work if there was a way to disable ASAN
during verification, but that doesn't appear to be possible.
Instead of a cryptic ASAN message, panic with a clear error.
And disable the test during ASAN.
Fixes#70321.
Change-Id: Ibc3876836abb83248a23c18c3b44c4cbb4a0c600
Reviewed-on: https://go-review.googlesource.com/c/go/+/627603
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The test "if(! ~ $#GOROOT_BOOTSTRAP 1)", to check for the environment
variable GOROOT_BOOTSTRAP being undefined, will not succeed if the
variable is set to the empty string (as the coordinator was doing).
A better test is "if(~ $"GOROOT_BOOTSTRAP '')", which succeeds if
the variable is undefined, or set to an empty list or an empty string.
For #69038
Change-Id: Ic6e6944e0c76461daea206ba9575b863f92f6228
Reviewed-on: https://go-review.googlesource.com/c/go/+/627944
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David du Colombier <0intro@gmail.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Go has never supported Cygwin as a C compiler, but users get the
following cryptic error message when they try to use it:
implicit declaration of function '_beginthread'
This is because Cygwin doesn't implement _beginthread. Note that
this is not the only problem with Cygwin, but it's the one that
users are most likely to run into first.
This CL improves the error message to make it clear that Cygwin
is not supported, and suggests using MinGW instead.
Fixes#59490Fixes#36691
Change-Id: Ifeec7a2cb38d7c5f50d6362c95504f72818c6a76
Reviewed-on: https://go-review.googlesource.com/c/go/+/627935
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>
For a wasmexport wrapper, we generate a call to the actual
exported Go function, and use the wrapper function's PC 1 as the
(fake) return address. This address is not used for returning,
which is handled by the Wasm call stack. It is used for stack
unwinding, and PC 1 makes it past the prologue and therefore has
the right SP delta. But if the function has no arguments and
results, the wrapper is frameless, with no prologue, and PC 1
doesn't exist. This causes the unwinder to fail. In this case, we
put PC 0, which also has the correct SP delta (0).
Fixes#69584.
Change-Id: Ic047a6e62100db540b5099cc5a56a1d0f16d58b9
Reviewed-on: https://go-review.googlesource.com/c/go/+/624000
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently it's possible for weak->strong conversions to create more GC
work during mark termination. When a weak->strong conversion happens
during the mark phase, we need to mark the newly-strong pointer, since
it may now be the only pointer to that object. In other words, the
object could be white.
But queueing new white objects creates GC work, and if this happens
during mark termination, we could end up violating mark termination
invariants. In the parlance of the mark termination algorithm, the
weak->strong conversion is a non-monotonic source of GC work, unlike the
write barriers (which will eventually only see black objects).
This change fixes the problem by forcing weak->strong conversions to
block during mark termination. We can do this efficiently by setting a
global flag before the ragged barrier that is checked at each
weak->strong conversion. If the flag is set, then the conversions block.
The ragged barrier ensures that all Ps have observed the flag and that
any weak->strong conversions which completed before the ragged barrier
have their newly-minted strong pointers visible in GC work queues if
necessary. We later unset the flag and wake all the blocked goroutines
during the mark termination STW.
There are a few subtleties that we need to account for. For one, it's
possible that a goroutine which blocked in a weak->strong conversion
wakes up only to find it's mark termination time again, so we need to
recheck the global flag on wake. We should also stay non-preemptible
while performing the check, so that if the check *does* appear as true,
it cannot switch back to false while we're actively trying to block. If
it switches to false while we try to block, then we'll be stuck in the
queue until the following GC.
All-in-all, this CL is more complicated than I would have liked, but
it's the only idea so far that is clearly correct to me at a high level.
This change adds a test which is somewhat invasive as it manipulates
mark termination, but hopefully that infrastructure will be useful for
debugging, fixing, and regression testing mark termination whenever we
do fix it.
Fixes#69803.
Change-Id: Ie314e6fd357c9e2a07a9be21f217f75f7aba8c4a
Reviewed-on: https://go-review.googlesource.com/c/go/+/623615
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Execution of the loop body previously either terminated
the iteration (returned false because of a break, goto, or
return) or actually panicked. The check against abi.RF_READY
ensures that the body can no longer run and also panics.
This CL in addition transitions the loop state to abi.RF_PANIC
so that if this already badly-behaved iterator defer-recovers
this panic, then the exit check at the loop context will
catch the problem and panic there.
Previously, panics triggered by attempted execution of a
no-longer active loop would not trigger a panic at the loop
context if they were defer-recovered.
Change-Id: Ieeed2fafd0d65edb66098dc27dc9ae8c1e6bcc8c
Reviewed-on: https://go-review.googlesource.com/c/go/+/625455
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Tim King <taking@google.com>
Iteration over swissmaps with low load (think map with large hint but
only one entry) is signicantly regressed vs old maps. See noswiss vs
swiss-tip below (+60%).
Currently we visit every single slot and individually check if the slot
is full or not.
We can do much better by using the control word to find all full slots
in a group in a single operation. This lets us skip completely empty
groups for instance.
Always using the control match approach is great for maps with low load,
but is a regression for mostly full maps. Mostly full maps have the
majority of slots full, so most calls to mapiternext will return the
next slot. In that case, doing the full group match on every call is
more expensive than checking the individual slot.
Thus we take a hybrid approach: on each call, we first check an
individual slot. If that slot is full, we're done. If that slot is
non-full, then we fall back to doing full group matches.
This trade-off works well. Both mostly empty and mostly full maps
perform nearly as well as doing all matching and all individual,
respectively.
The fast path is placed above the slow path loop rather than combined
(with some sort of `useMatch` variable) into a single loop to help the
compiler's code generation. The compiler really struggles with code
generation on a combined loop for some reason, yielding ~15% additional
instructions/op.
Comparison with old maps prior to this CL:
│ noswiss │ swiss-tip │
│ sec/op │ sec/op vs base │
MapIter/Key=int64/Elem=int64/len=6-12 11.53n ± 2% 10.64n ± 2% -7.72% (p=0.002 n=6)
MapIter/Key=int64/Elem=int64/len=64-12 10.180n ± 2% 9.670n ± 5% -5.01% (p=0.004 n=6)
MapIter/Key=int64/Elem=int64/len=65536-12 10.78n ± 1% 10.15n ± 2% -5.84% (p=0.002 n=6)
MapIterLowLoad/Key=int64/Elem=int64/len=6-12 6.116n ± 2% 6.840n ± 2% +11.84% (p=0.002 n=6)
MapIterLowLoad/Key=int64/Elem=int64/len=64-12 2.403n ± 2% 3.892n ± 0% +61.95% (p=0.002 n=6)
MapIterLowLoad/Key=int64/Elem=int64/len=65536-12 1.940n ± 3% 3.237n ± 1% +66.81% (p=0.002 n=6)
MapPop/Key=int64/Elem=int64/len=6-12 66.20n ± 2% 60.14n ± 3% -9.15% (p=0.002 n=6)
MapPop/Key=int64/Elem=int64/len=64-12 97.24n ± 1% 171.35n ± 1% +76.21% (p=0.002 n=6)
MapPop/Key=int64/Elem=int64/len=65536-12 826.1n ± 12% 842.5n ± 10% ~ (p=0.937 n=6)
geomean 17.93n 20.96n +16.88%
After this CL:
│ noswiss │ swiss-cl │
│ sec/op │ sec/op vs base │
MapIter/Key=int64/Elem=int64/len=6-12 11.53n ± 2% 10.90n ± 3% -5.42% (p=0.002 n=6)
MapIter/Key=int64/Elem=int64/len=64-12 10.180n ± 2% 9.719n ± 9% -4.53% (p=0.043 n=6)
MapIter/Key=int64/Elem=int64/len=65536-12 10.78n ± 1% 10.07n ± 2% -6.63% (p=0.002 n=6)
MapIterLowLoad/Key=int64/Elem=int64/len=6-12 6.116n ± 2% 7.022n ± 1% +14.82% (p=0.002 n=6)
MapIterLowLoad/Key=int64/Elem=int64/len=64-12 2.403n ± 2% 1.475n ± 1% -38.63% (p=0.002 n=6)
MapIterLowLoad/Key=int64/Elem=int64/len=65536-12 1.940n ± 3% 1.210n ± 6% -37.67% (p=0.002 n=6)
MapPop/Key=int64/Elem=int64/len=6-12 66.20n ± 2% 61.54n ± 2% -7.02% (p=0.002 n=6)
MapPop/Key=int64/Elem=int64/len=64-12 97.24n ± 1% 110.10n ± 1% +13.23% (p=0.002 n=6)
MapPop/Key=int64/Elem=int64/len=65536-12 826.1n ± 12% 504.7n ± 6% -38.91% (p=0.002 n=6)
geomean 17.93n 15.29n -14.74%
For #54766.
Cq-Include-Trybots: luci.golang.try:gotip-linux-ppc64_power10
Change-Id: Ic07f9df763239e85be57873103df5007144fdaef
Reviewed-on: https://go-review.googlesource.com/c/go/+/627156
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>
Reviewed-by: Keith Randall <khr@google.com>
This package is in charge of the FIPS init-time code+data verification.
If GODEBUG=fips140=off or the empty string, then no verification
happens. Otherwise, the setting must be "on", "debug", or "only",
all of which enable verification. If the setting is "debug", successful
verification prints a message to that effect. Otherwise successful
verification is quiet.
The linker leaves special information for this package to use.
See cmd/internal/obj/fips.go and cmd/link/internal/ld/fips.go,
both submitted in earlier CLs, for details.
For #69536.
Change-Id: Ie1fe29f316db290e0bd7df0a5a09108be4779d63
Reviewed-on: https://go-review.googlesource.com/c/go/+/625998
Reviewed-by: Filippo Valsorda <filippo@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
For FIPS init-time code+data verification, we need to arrange to
put the FIPS symbols into contiguous regions of the executable
and then record those sections along with the expected checksum.
The cmd/internal/obj changes identify the FIPS symbols and give
them distinguished types, which the linker then places in contiguous
regions. The linker also writes out information to use at run time
to find the FIPS sections, along with the expected hash.
See cmd/internal/obj/fips.go and cmd/link/internal/ld/fips.go
for more details.
The code is disabled in this commit.
CL 625998 and 625999 adds tests.
CL 626000 enables the code.
For #69536.
Change-Id: I48da6db94bc0bea7428c43d4abcf999527bccfcd
Reviewed-on: https://go-review.googlesource.com/c/go/+/625997
Auto-Submit: 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>
The failures in #70288 are consistent with and strongly imply
stack corruption during fault handling, and debug prints show
that the Go code run during fault handling is running about
300 bytes above the bottom of the goroutine stack.
That should be okay, but that implies the DLL code that called
Go's handler was running near the bottom of the stack too,
and maybe it called other deeper things before or after the
Go handler and smashed the stack that way.
stackSystem is already 4096 bytes on amd64;
making it match that on 386 makes the flaky failures go away.
It's a little unsatisfying not to be able to say exactly what is
overflowing the stack, but the circumstantial evidence is
very strong that it's Windows.
Fixes#70288.
Change-Id: Ife89385873d5e5062a71629dbfee40825edefa49
Reviewed-on: https://go-review.googlesource.com/c/go/+/627375
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This CL refers to the implementation of ARM64 and adds support for the following
types of SIMD instructions:
1. Move general-purpose register to a vector element, e.g.:
VMOVQ Rj, <Vd>.<T>[index]
<T> can have the following values:
B, H, W, V
2. Move vector element to general-purpose register, e.g.:
VMOVQ <Vj>.<T>[index], Rd
<T> can have the following values:
B, BU, H, HU, W, WU, VU
3. Duplicate general-purpose register to vector, e.g.:
VMOVQ Rj, <Vd>.<T>
<T> can have the following values:
B16, H8, W4, V2, B32, H16, W8, V4
4. Move vector, e.g.:
XVMOVQ Xj, <Xd>.<T>
<T> can have the following values:
B16, H8, W4, V2, Q1
5. Move vector element to scalar, e.g.:
XVMOVQ Xj, <Xd>.<T>[index]
XVMOVQ Xj.<T>[index], Xd
<T> can have the following values:
W, V
6. Move vector element to vector register, e.g.:
VMOVQ <Vn>.<T>[index], Vn.<T>
<T> can have the following values:
B, H, W, V
This CL only adds syntax and doesn't break any assembly that already exists.
Change-Id: I7656efac6def54da6c5ae182f39c2a21bfdf92bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/616258
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Meidan Li <limeidan@loongson.cn>
Reviewed-by: sophie zhao <zhaoxiaolin@loongson.cn>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This fixes a bug in the test only function Import where it looked for
the first instance of the string "\n$$\n" as the end of the exportdata
section. This should look for the last instance of "\n$$\n" within
the ar file.
Adds unit tests that demonstrate the error.
Added comments to tests that can correctly use the first instance.
Change-Id: I7a85afa41cf1c2902119516b757b7c6625d46d13
Reviewed-on: https://go-review.googlesource.com/c/go/+/626775
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Now that we support pointer types on wasmimport functions, use
them, instead of unsafe.Pointer. This removes unsafe conversions.
There is still one unsafe.Pointer argument left. It is actually a
*Stat_t, which is an exported type with an int field, which is not
allowed as a wasmimport field type. We probably cannot change it
at this point.
Updates #66984.
Change-Id: I445c70b356c3877a5604bee67d19d99a538c682e
Reviewed-on: https://go-review.googlesource.com/c/go/+/627059
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
As proposed on #66984, this CL allows more types to be used as
wasmimport/wasmexport function parameters and results.
Specifically, bool, string, and uintptr are now allowed, and also
pointer types that point to allowed element types. Allowed element
types includes sized integer and floating point types (including
small integer types like uint8 which are not directly allowed as
a parameter type), bool, array whose element type is allowed, and
struct whose fields are allowed element type and also include a
struct.HostLayout field.
For #66984.
Change-Id: Ie5452a1eda21c089780dfb4d4246de6008655c84
Reviewed-on: https://go-review.googlesource.com/c/go/+/626615
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Add FIPS symbol kinds that will be needed for FIPS support.
This is a separate CL to keep the re-generated changes in
the string methods separate from hand-written changes.
The separate symbol kinds will let us group the FIPS-related
code and data together, so that it can be checksummed at
startup, as required by FIPS.
It's also separate because it breaks buildall, by changing the
on-disk symbol kind enumeration. We want non-buildall
changes to be as simple as possible.
For #69536.
Change-Id: I2d5a238498929fff8b24736ee54330c17323bd86
Reviewed-on: https://go-review.googlesource.com/c/go/+/625995
Auto-Submit: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
As the comment notes, all calls to Errorf now pass nil,
so remove that argument entirely.
There is a TODO to remove uses of Errorf entirely, but
that seems wrong: sometimes there is no symbol on
which to report the error, and in that situation, Errorf is
appropriate. So clarify that in the docs.
Change-Id: I92b3b6e8e3f61ba8356ace8cd09573d0b55d7869
Reviewed-on: https://go-review.googlesource.com/c/go/+/625617
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The old API was to do
r := obj.AddRel(sym)
r.Type = this
r.Off = that
etc
The new API is:
sym.AddRel(ctxt, obj.Reloc{Type: this: Off: that, etc})
This new API is more idiomatic and avoids ever having relocations
that are only partially constructed. Most importantly, it sets up
for sym.AddRel being able to check relocation validity in the future.
(Passing ctxt is for use in validity checking.)
Passes golang.org/x/tools/cmd/toolstash/buildall.
Change-Id: I042ea76e61bb3bf6402f98ca11291a13f4799972
Reviewed-on: https://go-review.googlesource.com/c/go/+/625616
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
On a 301 redirect, the HTTP client changes the request to be
a GET with no body.
On a 308 redirect, the client leaves the request method and
body unchanged.
A 308 following a 301 should preserve the rewritten request
from the first redirect: GET with no body. We were preserving
the method, but sending the original body. Fix this.
Fixes#70180
Change-Id: Ie20027a6058a82bfdffc7197d07ac6c7f98099e2
Reviewed-on: https://go-review.googlesource.com/c/go/+/626055
Reviewed-by: Jonathan Amsterdam <jba@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Strictly speaking, the sort comparison was inconsistent
(and therefore invalid) for the sort-by-name case, if you had
a size 0
b size 1
c size 0
zerobase
That would result in the inconsistent comparison ordering:
a < b (by name)
b < c (by name)
c < zerobase (by zerobase rule)
zerobase < b (by zerobase rule)
This can't happen today because we only disable size-based
sort in a segment that has no zerobase symbol, but it's
confusing to reason through that, so clean up the code anyway.
Passes golang.org/x/tools/cmd/toolstash/buildall.
Change-Id: I21e4159cdedd2053952ba960530d1b0f28c6fb24
Reviewed-on: https://go-review.googlesource.com/c/go/+/625615
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
syscall.SyscallN is implemented by runtime.syscall_syscalln, which makes
sure that the variadic argument doesn't escape.
There is no need to worry about the lifetime of the elements of the
variadic argument, as the compiler will keep them live until the
function returns.
Fixes#70197.
Cq-Include-Trybots: luci.golang.try:gotip-windows-amd64-longtest,gotip-windows-amd64-race
Change-Id: I12991f0be12062eea68f2b103fa0a794c1b527eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/625297
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
For the SubFromLen64 codegen test case to work as intended, we need
to fold c-(-(x-d)) into x+(c-d).
Still, some instances of LeadingZeros are not optimized into single
CLZ instructions right now (actually, the LeadingZeros micro-benchmarks
are currently still compiled with redundant adds/subs of 64, due to
interference of loop optimizations before lowering), but perf numbers
indicate it's not that bad after all.
Micro-benchmark results on Loongson 3A5000 and 3A6000:
goos: linux
goarch: loong64
pkg: math/bits
cpu: Loongson-3A5000 @ 2500.00MHz
| bench.old | bench.new |
| sec/op | sec/op vs base |
LeadingZeros 3.660n ± 0% 1.348n ± 0% -63.17% (p=0.000 n=20)
LeadingZeros8 1.777n ± 0% 1.767n ± 0% -0.56% (p=0.000 n=20)
LeadingZeros16 2.816n ± 0% 1.770n ± 0% -37.14% (p=0.000 n=20)
LeadingZeros32 5.293n ± 1% 1.683n ± 0% -68.21% (p=0.000 n=20)
LeadingZeros64 3.622n ± 0% 1.349n ± 0% -62.76% (p=0.000 n=20)
geomean 3.229n 1.571n -51.35%
goos: linux
goarch: loong64
pkg: math/bits
cpu: Loongson-3A6000 @ 2500.00MHz
| bench.old | bench.new |
| sec/op | sec/op vs base |
LeadingZeros 2.410n ± 0% 1.103n ± 1% -54.23% (p=0.000 n=20)
LeadingZeros8 1.236n ± 0% 1.501n ± 0% +21.44% (p=0.000 n=20)
LeadingZeros16 2.106n ± 0% 1.501n ± 0% -28.73% (p=0.000 n=20)
LeadingZeros32 2.860n ± 0% 1.324n ± 0% -53.72% (p=0.000 n=20)
LeadingZeros64 2.6135n ± 0% 0.9509n ± 0% -63.62% (p=0.000 n=20)
geomean 2.159n 1.256n -41.81%
Updates #59120
This patch is a copy of CL 483356.
Co-authored-by: WANG Xuerui <git@xen0n.name>
Change-Id: Iee81a17f7da06d77a427e73dfcc016f2b15ae556
Reviewed-on: https://go-review.googlesource.com/c/go/+/624575
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
A part of the keeping Go's vendored dependencies and generated code
up to date.
For #36905.
[git-generate]
cd src
go get golang.org/x/sys@v0.26.1-0.20241105152852-e0753d469443
go mod tidy
go mod vendor
cd cmd
go get golang.org/x/sys@v0.26.1-0.20241105152852-e0753d469443
go mod tidy
go mod vendor
go generate syscall internal/syscall/...
Change-Id: Ia84505f8934399f7c4518c6218892b81d30e5c17
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/623821
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Bypass: Dmitri Shuralyov <dmitshur@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Compared with the version generated by dec64.rules based on Ctz32,
the number of assembly instructions is reduced by half.
SwissMap uses TrailingZeros64 to find the first match in its control
group and may benefit from this CL on 386 architectures.
goos: linux
goarch: 386
cpu: 13th Gen Intel(R) Core(TM) i7-13700H
│ old.txt │ new.txt │
│ sec/op │ sec/op vs base │
TrailingZeros64-20 0.8828n ± 1% 0.6299n ± 1% -28.65% (p=0.000 n=20)
Change-Id: Iba08a3f4e13efd3349715dfb7fcd5fd470286cd3
Reviewed-on: https://go-review.googlesource.com/c/go/+/624376
Reviewed-by: David Chase <drchase@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>
The TestProfilerStackDepth/heap test can spuriously fail if the profiler
happens to capture a stack with an allocation several frames deep into
runtime code. The pprof API hides runtime frames at the leaf-end of
stacks, but those frames still count against the profiler's stack depth
limit. The test checks only the first stack it finds with the desired
prefix and fails if it's not deep enough or doesn't have the right root
frame. So it can fail in that scenario, even though the implementation
isn't really broken.
Relax the test to check that there is at least one stack with desired
prefix, depth, and root frame.
Fixes#70112
Change-Id: I337fb3cccd1ddde76530b03aa1ec0f9608aa4112
Reviewed-on: https://go-review.googlesource.com/c/go/+/623998
Reviewed-by: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com>
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>
Add support for assembling the FMA instructions present in the LoongArch
base ISA v1.00. This requires adding a new instruction format and making
use of a third source operand, which is put in RestArgs[0].
The single-precision instructions have the `.s` prefix in their official
mnemonics, and similar Go asm instructions all have `S` prefix for the
other architectures having FMA support, but in this change they instead
have `F` prefix in Go asm because loong64 currently follows the mips
backends in the naming convention. This could be changed later because
FMA is fully expressible in pure Go, making it unlikely to have to hand-
write such assembly in the wild.
Example mapping between actual encoding and Go asm syntax:
fmadd.s fd, fj, fk, fa -> FMADDF fa, fk, fj, fd
(prog.From = fa, prog.Reg = fk, prog.RestArgs[0] = fj and prog.To = fd)
fmadd.s fd, fd, fk, fa -> FMADDF fa, fk, fd
(prog.From = fa, prog.Reg = fk and prog.To = fd)
This patch is a copy of CL 477716.
Co-authored-by: WANG Xuerui <git@xen0n.name>
Change-Id: I9b4e4c601d6c5a854ee238f085849666e4faf090
Reviewed-on: https://go-review.googlesource.com/c/go/+/623877
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Seems simple, but putting the return after fatal ensures that at the
point of the small group loop, no call has happened so the key is
still in a register. This ensures that we don't have to restore the
key from the stack before the comparison on each iteration. That gets
rid of a load from the inner loop.
name old time/op new time/op delta
MapAccessHit/Key=int64/Elem=int64/len=6-8 4.01ns ± 6% 3.85ns ± 3% -3.92% (p=0.001 n=10+10)
Change-Id: Ia23ac48e6c5522be88f7d9be0ff3489b2dfc52fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/624255
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@google.com>
Ever since we had to upgrade from our COS image, we've been experiencing
TSAN test failures. My best guess is that the ASLR randomization entropy
increased, causing TSAN to fail. TSAN already re-execs itself in Clang
18+ with ASLR disabled, so just execute the tests with ASLR disabled on
Linux.
Fixes#59418.
Change-Id: Icb4536ddf0f2f5e7850734564d40f5a208ab8d01
Cq-Include-Trybots: luci.golang.try:gotip-linux-386,gotip-linux-386-clang15,gotip-linux-amd64-clang15,gotip-linux-amd64-boringcrypto,gotip-linux-amd64-aliastypeparams,gotip-linux-amd64-asan-clang15,gotip-linux-amd64-msan-clang15,gotip-linux-amd64-goamd64v3
Reviewed-on: https://go-review.googlesource.com/c/go/+/623956
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
All remaining unary bitop instructions in the LoongArch v1.00 base ISA
are added with this change.
While at it, add the missing W suffix to the current CLO/CLZ names. They
are not used anywhere as far as we know, so no breakage is expected.
Also, stop reusing SLL's instruction format for simplicity, in favor of
a new but trivial instruction format case.
This patch is a copy of CL 477717.
Co-authored-by: WANG Xuerui <git@xen0n.name>
Change-Id: Idbcaca25dda1ed313674ef8b26da722e8d7151c0
Reviewed-on: https://go-review.googlesource.com/c/go/+/623876
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This tests fails sporadically on the aix-ppc64 CI. I suspect this is
an aix performance related issue. Skip the test.
AIX seems slow to perform a non-blocking reading on a pipe, and this
results in too many threads being created. This happens as far back
as go1.22, where I stopped looking.
On the GCC farm machine gcc119, The failure rate seemed coupled to
GOMAXPROCS; about 1% for <=8, up to 40%+ for >=30 for all releases
tested.
For #70131
Change-Id: If002b55e5a4586d10cc7876d7c25259e61b17163
Reviewed-on: https://go-review.googlesource.com/c/go/+/623817
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Avoid integer overflow when passing a number of bytes to sendfile.
Also, Solaris might not support passing a 0 length to read to
the end of a file, but it does support passing a very large length.
So just do that instead of looking up the source file size.
Change-Id: Ibf750892938d9e2bafb1256c6e380c88899495f4
Reviewed-on: https://go-review.googlesource.com/c/go/+/623315
TryBot-Bypass: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Currently, at a cgo callback where there is already a Go frame on
the stack (i.e. C->Go->C->Go), we require that at the inner Go
callback the SP is within the g0's stack bounds set by a previous
callback. This is to prevent that the C code switches stack while
having a Go frame on the stack, which we don't really support. But
this could also happen when we cannot get accurate stack bounds,
e.g. when pthread_getattr_np is not available. Since the stack
bounds are just estimates based on the current SP, if there are
multiple C->Go callbacks with various stack depth, it is possible
that the SP of a later callback falls out of a previous call's
estimate. This leads to runtime throw in a seemingly reasonable
program.
This CL changes it to save the old g0 stack bounds at cgocallback,
update the bounds, and restore the old bounds at return. So each
callback will get its own stack bounds based on the current SP,
and when it returns, the outer callback has the its old stack
bounds restored.
Also, at a cgo callback when there is no Go frame on the stack,
we currently always get new stack bounds. We do this because if
we can only get estimated bounds based on the SP, and the stack
depth varies a lot between two C->Go calls, the previous
estimates may be off and we fall out or nearly fall out of the
previous bounds. But this causes a performance problem: the
pthread API to get accurate stack bounds (pthread_getattr_np) is
very slow when called on the main thread. Getting the stack bounds
every time significantly slows down repeated C->Go calls on the
main thread.
This CL fixes it by "caching" the stack bounds if they are
accurate. I.e. at the second time Go calls into C, if the previous
stack bounds are accurate, and the current SP is in bounds, we can
be sure it is the same stack and we don't need to update the bounds.
This avoids the repeated calls to pthread_getattr_np. If we cannot
get the accurate bounds, we continue to update the stack bounds
based on the SP, and that operation is very cheap.
On a Linux/AMD64 machine with glibc:
name old time/op new time/op delta
CgoCallbackMainThread-8 96.4µs ± 3% 0.1µs ± 2% -99.92% (p=0.000 n=10+9)
Fixes#68285.
Fixes#68587.
Change-Id: I3422badd5ad8ff63e1a733152d05fb7a44d5d435
Reviewed-on: https://go-review.googlesource.com/c/go/+/600296
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
The compiler will stack allocate the Map struct and initial group if
possible.
Stack maps are initialized inline without calling into the runtime.
Small heap allocated maps use makemap_small.
These are the same heuristics as existing maps.
For #54766.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest-swissmap
Change-Id: I6c371d1309716fd1c38a3212d417b3c76db5c9b9
Reviewed-on: https://go-review.googlesource.com/c/go/+/622042
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>
Auto-Submit: Michael Pratt <mpratt@google.com>
Load the field we need from the type once outside the search loop.
Get rid of the multiply to compute the slot position. Instead compute
the slot position incrementally using addition.
Move the hashing later in access2.
Based on khr@'s CL 618959.
For #54766.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest-swissmap
Change-Id: Id11b5479fa5bc0130a1d8d9e664d0206d24942ea
Reviewed-on: https://go-review.googlesource.com/c/go/+/620217
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: Michael Pratt <mpratt@google.com>
Add all the specialized variants that exist for the existing maps.
Like the existing maps, the fast variants do not support indirect
key/elem.
Note that as of this CL, the Get and Put methods on Map/table are
effectively dead. They are only reachable from the internal/runtime/maps
unit tests.
For #54766.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest-swissmap
Change-Id: I95297750be6200f34ec483e4cfc897f048c26db7
Reviewed-on: https://go-review.googlesource.com/c/go/+/616463
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>
Reviewed-by: Keith Randall <khr@google.com>
Regenerate RISC-V instruction table from the riscv-opcodes repository,
due to various changes and shuffling upstream.
This has been changed to remove pseudo-instructions, since Go only
needs the instruction encodings and including the pseudo-instructions
is creating unnecessary complications (for example, the inclusion
of ANOP and ARET, as well as strangely named aliases such as
AJALPSEUDO/AJALRPSEUDO). Remove pseudo-instructions that are not
currently supported by the assembler and add specific handling for
RDCYCLE, RDTIME and RDINSTRET, which were previously implemented
via the instruction encodings.
Change-Id: I78be4506ba6b627eba1f321406081a63bab5b2e6
Cq-Include-Trybots: luci.golang.try:gotip-linux-riscv64
Reviewed-on: https://go-review.googlesource.com/c/go/+/616116
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
On a whim I decided to investigate the possibility of whether the
flakiness on the asan builder was due to a concurrently executing test.
Of the most recent failures there were a few candidates, and this test
was one of them. After disabling each candidate one by one, we had a
winner: this test causes other concurrently executing tests, running
pure Go code, to spuriously fail.
I do not know why yet, but this test doesn't seem like it would have
incredibly high value for ASAN, and does funky things like MAP_FIXED in
recently unmapped regions, so I think it's fine.
For #70054.
For #64257.
Change-Id: Ib9a84d9b69812e76c390d99b00698710ee1ece1a
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-asan-clang15
Reviewed-on: https://go-review.googlesource.com/c/go/+/623336
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
If there is a phi that is computing the minimum of its two inputs,
then we know the result of the phi is smaller than or equal to both
of its inputs. Similarly for maxiumum (although max seems less useful).
This pattern happens for the case
n := copy(a, b)
n is the minimum of len(a) and len(b), so with this optimization we
know both n <= len(a) and n <= len(b). That extra information is
helpful for subsequent slicing of a or b.
Fixes#16833
Change-Id: Ib4238fd1edae0f2940f62a5516a6b363bbe7928c
Reviewed-on: https://go-review.googlesource.com/c/go/+/622240
Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
These fail for the same reason as for the race detector, and is the most
frequently failing test in both.
For #70054.
For #64257.
For #64256.
Change-Id: I3649e58069190b4450f9d4deae6eb8eca5f827a3
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-asan-clang15,gotip-linux-amd64-msan-clang15
Reviewed-on: https://go-review.googlesource.com/c/go/+/623176
TryBot-Bypass: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
BGT, BLT, BLE, BGE, BNE, BVS, BVC, and BEQ support by assembler. This will simplify the usage of BC constructs like
BC 12, 30, LR <=> BEQ CR7, LR
BC 12, 2, LR <=> BEQ CR0, LR
BC 12, 0, target <=> BLT CR0, target
BC 12, 2, target <=> BEQ CR0, target
BC 12, 5, target <=> BGT CR1, target
BC 12, 30, target <=> BEQ CR7, target
BC 4, 6, target <=> BNE CR1, target
BC 4, 5, target <=> BLE CR1, target
code cleanup based on the above additions.
Change-Id: I02fdb212b6fe3f85ce447e05f4d42118c9ce63b5
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/+/612395
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Paul Murphy <murp@ibm.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
The internal/poll/sendfile_{bsd,linux,solaris}.go implementations
have more in common than not. Combine into a single sendfile_unix.go.
The net and os packages have redundant code dealing with sendfile
quirks on non-Linux Unix systems, such as the need to determine the
size of the source file before sending. Move the common code into
internal/poll.
Remove some obsolete or incorrect behaviors:
Drop the maximum sendfile chunk size. If we ask the kernel
to copy more data than it is willing to send, it'll copy up to
its limit.
There was a comment in net/sendfile_unix_alt.go indicating that
copying more bytes than a file contains results in the kernel
looping back to the start of the file. I am unable to replicate
this behavior anywhere. Dropped the comment, the workarounds,
and added a test covering this case.
Darwin, Dragonfly, and FreeBSD all support copying the entire
contents of a file by passing 0 for the copy limit.
Take advantage of this.
Change-Id: I9f707ac7a27c165020ae02a6b5bb8f6f16f3c530
Reviewed-on: https://go-review.googlesource.com/c/go/+/621416
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
First, skip all the allocation count tests.
In some cases this aligns with existing skips for -race, but in others
we've got new issues. These are debug modes, so some performance loss is
expected, and this is clearly no worse than today where the tests fail.
Next, skip internal linking and static linking tests for msan and asan.
With asan we get an explicit failure that neither are supported by the C
and/or Go compilers. With msan, we only get the Go compiler telling us
internal linking is unavailable. With static linking, we segfault
instead. Filed #70080 to track that.
Next, skip some malloc tests with asan that don't quite work because of
the redzone.
This is because of some sizeclass assumptions that get broken with the
redzone and the fact that the tiny allocator is effectively disabled
(again, due to the redzone).
Next, skip some runtime/pprof tests with asan, because of extra
allocations.
Next, skip some malloc tests with asan that also fail because of extra
allocations.
Next, fix up memstats accounting for arenas when asan is enabled. There
is a bug where more is added to the stats than subtracted. This also
simplifies the accounting a little.
Next, skip race tests with msan or asan enabled; they're mutually
incompatible.
Fixes#70054.
Fixes#64256.
Fixes#64257.
For #70079.
For #70080.
Change-Id: I99c02a0b9d621e44f1f918b307aa4a4944c3ec60
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-asan-clang15,gotip-linux-amd64-msan-clang15
Reviewed-on: https://go-review.googlesource.com/c/go/+/622855
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Bypass: Michael Knyszek <mknyszek@google.com>
We still use the hash and control word, but loop over all 8 bytes
instead of doing the match operation, which ends up being slightly
faster when there is only one group.
Note that specialized variants added later will avoid hashing at all.
For #54766.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest-swissmap
Change-Id: I3bb353b023dd6120b6585e87d3efe2f18ac9e1ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/611189
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
If the map contains 8 or fewer entries, it is wasteful to have a
directory that points to a table that points to a group.
Add a special case that replaces the directory with a direct pointer to
a group.
We could theoretically do similar for single table maps (no directory,
just point directly to a table), but that is left for later.
For #54766.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest-swissmap
Change-Id: I6fc04dfc11c31dadfe5b5d6481b4c4abd43d48ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/611188
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>
Reviewed-by: Keith Randall <khr@google.com>
While walking the probe sequence, Put keeps track of the first deleted
slot it encountered. If it reaches the end of the probe sequence without
finding a match, then it will prefer to use the deleted slot rather than
a new empty slot.
For #54766.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest-swissmap
Change-Id: I19356ef6780176506f57b42990ac15dc426f1b14
Reviewed-on: https://go-review.googlesource.com/c/go/+/618016
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
This change amends the long-form help output for 'go help build' and
'go help testflag' to specify that the '-coverpkg' flag operates
explicitly on import paths as well as package names. Import paths are
fundamental for precise specification of packages versus unqualified
package names, and the naming of the flag '-coverpkg' and its original
documentation leads a user to assume that it only operates on the
simple, unqualified package name form. The situation warrants
clarification.
Fixes#69653
Change-Id: Ifde6a974405ce1614e28898fc2b92ed5bad94e57
GitHub-Last-Rev: 466c662a70
GitHub-Pull-Request: golang/go#69655
Reviewed-on: https://go-review.googlesource.com/c/go/+/616257
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Adds a new crypto/internal/fips test binary that operates as both a unit
test fetching/driving the BoringSSL acvptool, and an acvptool module
wraper when invoked by the unit test. Initial support for testing the
SHA2 and SHA3 family of digests, and the HMAC family of MACs is
included.
Test vectors and expected answers are maintained in a separate repo,
`github.com/cpu/go-acvp` and fetched through the module proxy as part of
the test process.
The BSSL acvptool "lowers" the NIST ACVP server JSON test vectors into
a simpler stdin/stdout protocol that can be implemented by a module
wrapper. The tool will fork our acvpwrapper binary, request the
supported configuration, and then provide test cases over stdin,
expecting results to be returned on stdout.
See "Testing other FIPS modules" from the BoringSSL ACVP.md
documentation for a more detailed description of the protocol used
between the acvptool and module wrappers.
Updates #69642
Updates #69536
Change-Id: I6b568c67f2a71144fbf31db467c6fd25710457f5
Reviewed-on: https://go-review.googlesource.com/c/go/+/615816
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
It's a little annoying, but we can fit the IBM instructions on top of
the regular state, avoiding more intrusive interventions.
Going forward we should not accept assembly that replaces the whole
implementation, because it doubles the work to do any refactoring like
the one in this chain.
Also, it took me a while to find the specification of these
instructions, which should have been linked from the source for the next
person who'd have to touch this.
Finally, it's really painful to test this without a LUCI TryBot, per #67307.
For #69536
Change-Id: I90632a90f06b2aa2e863967de972b12dbaa5b2ae
Reviewed-on: https://go-review.googlesource.com/c/go/+/617359
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Main changes are
- return concrete *Digest and *SHAKE instead of interfaces
- make tests external (sha3_test) so they will be easy to move to
the public package
- drop most of the developer guidance docs (to be updated and
reintroduced in the public package)
- consolidate the _noasm.go files (matching the single _s390x.go)
- move TestAllocations from build tags to testenv
- temporarily disable s390x code, to refactor in a following CL
For #69536
Change-Id: Ie5fd3e2b589b9eb835b9e3174b7a79c2ac728ab1
Reviewed-on: https://go-review.googlesource.com/c/go/+/617357
Reviewed-by: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
A GODEBUG is actually a security risk here: most programs will start to
ignore errors from Read because they can't happen (which is the intended
behavior), but then if a program is run with GODEBUG=randcrash=0 it will
use a partial buffer in case an error occurs, which may be catastrophic.
Note that the proposal was accepted without the GODEBUG, which was only
added later.
This (partially) reverts CL 608435. I kept the tests.
Updates #66821
Change-Id: I3fd20f9cae0d34115133fe935f0cfc7a741a2662
Reviewed-on: https://go-review.googlesource.com/c/go/+/622115
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
With LDREXB/STREXB now available for the arm assembler we can implement these operations natively. The instructions are armv6k+ but for simplicity I only use them on armv7.
Benchmark results for a raspberry Pi 3 model B+:
goos: linux
goarch: arm
pkg: internal/runtime/atomic
cpu: ARMv7 Processor rev 4 (v7l)
│ old.txt │ new.txt │
│ sec/op │ sec/op vs base │
And8-4 127.65n ± 0% 68.74n ± 0% -46.15% (p=0.000 n=10)
Change-Id: Ic87f307c35f7d7f56010980302f253056f6d54dc
GitHub-Last-Rev: a7351802fd
GitHub-Pull-Request: golang/go#70002
Cq-Include-Trybots: luci.golang.try:gotip-linux-arm
Reviewed-on: https://go-review.googlesource.com/c/go/+/622075
Reviewed-by: Keith Randall <khr@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>
This change finally fully fixes mallocgc for asan after the recent
refactoring. Here is everything that changed:
Fix the accounting for the alloc header; large objects don't have them.
Mask out extra bits set from unrolling the bitmap for slice backing
stores in writeHeapBitsSmall. The redzone in asan mode makes it so that
dataSize is no longer an exact multiple of typ.Size_ in this case (a
new assumption I have recently discovered) but we didn't mask out any
extra bits, so we'd accidentally set bits in other allocations. Oops.
Move the initHeapBits optimization for the 8-byte scan sizeclass on
64-bit platforms up to mallocgc, out from writeHeapBitsSmall. So, this
actually caused a problem with asan when the optimization first landed,
but we missed it. The issue was then masked once we started passing the
redzone down into writeHeapBitsSmall, since the optimization would no
longer erroneously fire on asan. What happened was that dataSize would
be 8 (because that was the user-provided alloc size) so we'd skip
writing heap bits, but it would turn out the redzone bumped the size
class, so we'd actually *have* to write the heap bits for that size
class. This is not really a problem now *but* it caused problems for me
when debugging, since I would try to remove the red zone from dataSize
and this would trigger this bug again. Ultimately, this whole situation
is confusing because the check in writeHeapBitsSmall is *not* the same
as the check in initHeapBits. By moving this check up to mallocgc, we
can make the checks align better by matching on the sizeclass, so this
should be less error-prone in the future.
Change-Id: I1e9819223be23f722f3bf21e63e812f5fb557194
Reviewed-on: https://go-review.googlesource.com/c/go/+/622041
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 622235 would fix#70000 while resulting in one extra sendfile(2) system
call when sendfile(2) returns (>0, EAGAIN).
That's also why I left sendfile_bsd.go behind, and didn't make it line up
with other two implementations: sendfile_linux.go and sendfile_solaris.go.
Unlike sendfile(2)'s on Linux and Solaris that always return (0, EAGAIN),
sendfile(2)'s on *BSD and macOS may return (>0, EAGAIN) when using a socket
marked for non-blocking I/O. In that case, the current code will try to re-call
sendfile(2) immediately, which will most likely get us a (0, EAGAIN).
After that, it goes to `dstFD.pd.waitWrite(dstFD.isFile)` below,
which should have been done in the first place.
Thus, the real problem that leads to #70000 is that the old code doesn't handle
the special case of sendfile(2) sending the exact number of bytes the caller requested.
Fixes#70000
Change-Id: I6073d6b9feb58b3d7e114ec21e4e80d9727bca66
Reviewed-on: https://go-review.googlesource.com/c/go/+/622255
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Andy Pan <panjf2000@gmail.com>
Sometimes the runtime needs to reserve some memory with a large
alignment, which the OS usually won't directly satisfy. So, it
asks size+align bytes instead, and frees the unaligned portions.
On sbrk systems, this doesn't work that well, as freeing the tail
portion doesn't really free the memory to the OS. Instead, we
could simply round the current break up, then reserve the given
size, without wasting the tail portion.
Also, don't create heap arena hints on sbrk systems. We can only
grow the break sequentially, and reserving specific addresses
would not succeed anyway.
For #69018.
Change-Id: Iadc2c54d62b00ad7befa5bbf71146523483a8c47
Reviewed-on: https://go-review.googlesource.com/c/go/+/621715
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Goroutine profiles require checking in with the profiler before any
goroutine starts running. coroswitch is a place where a goroutine may
start running, but where we do not check in with the profiler, which
leads to crashes. Fix this by checking in with the profiler the same way
execute does.
Fixes#69998.
Change-Id: Idef6dd31b70a73dd1c967b56c307c7a46a26ba73
Reviewed-on: https://go-review.googlesource.com/c/go/+/622016
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
A previous CL broke the ASAN poisoning calculation in mallocgc by not
taking into account a possible allocation header, so the beginning of
the following allocation could have been poisoned.
This mostly isn't a problem, actually, since the following slot would
usually just have an allocation header in it that programs shouldn't be
touching anyway, but if we're going a word-past-the-end at the end of a
span, we could be poisoning a valid heap allocation.
Change-Id: I76a4f59bcef01af513a1640c4c212c0eb6be85b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/622295
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>
Replace Transport's limit of 5 1xx responses with a limit based
on MaxResponseHeaderBytes: The total number of responses
(including 1xx reponses and the final response) must not exceed
this value.
When the user is reading 1xx responses using a Got1xxResponse
client trace hook, disable the limit: Each 1xx response is
individually limited by MaxResponseHeaderBytes, but there
is no limit on the total number of responses. The user is
responsible for imposing a limit if they want one.
For #65035
Change-Id: If4bbbbb0b808cb5016701d50963c89f0ce1229f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/615255
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The BSD implementation of poll.SendFile incorrectly halted
copying after succesfully writing one full chunk of data.
Adjust the copy loop to match the Linux and Solaris
implementations.
In testing, empirically macOS appears to sometimes return
EAGAIN from sendfile after successfully copying a full
chunk. Add a check to all implementations to return nil
after successfully copying all data if the last sendfile
call returns EAGAIN.
For #70000
Change-Id: I57ba649491fc078c7330310b23e1cfd85135c8ff
Reviewed-on: https://go-review.googlesource.com/c/go/+/622235
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
This will be required for #69536 but is also good hygiene and required
by go.dev/wiki/AssemblyPolicy.
> The code must be tested in our CI. This means there need to be
> builders that support the instructions, and if there are multiple (or
> fallback) paths they must be tested separately.
The new crypto/internal/impl registry lets us select alternative
implementations from both the same package and importers (such as
crypto/sha256 tests once we have crypto/internal/fips/sha256, or
crypto/hmac).
Updates #69592
Updates #69593
Change-Id: Ifea22a9fc9ccffcaf4924ff6bd08da7c9bd39e99
Cq-Include-Trybots: luci.golang.try:gotip-linux-arm64-longtest,gotip-linux-amd64-longtest,gotip-linux-ppc64le_power8,gotip-linux-ppc64_power8
Reviewed-on: https://go-review.googlesource.com/c/go/+/614656
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Change the description of an operand x that has a named type of sorts
by providing a description of the type structure (array, struct, slice,
pointer, etc).
For instance, given a (variable) operand x of a struct type T, the
operand is mentioned as (new):
x (variable of struct type T)
instead of (old):
x (variable of type T)
This approach is also used when a basic type is renamed, for instance
as in:
x (value of uint type big.Word)
which makes it clear that big.Word is a uint.
This change is expected to produce more informative error messages.
Fixes#69955.
Change-Id: I544b0698f753a522c3b6e1800a492a94974fbab7
Reviewed-on: https://go-review.googlesource.com/c/go/+/621458
Reviewed-by: Alan Donovan <adonovan@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This change improves error message for recursive types.
Currently, compilation of the [following program](https://go.dev/play/p/3ef84ObpzfG):
package main
type T1[T T2] struct{}
type T2[T T1] struct{}
returns an error:
./prog.go:3:6: invalid recursive type T1
./prog.go:3:6: T1 refers to
./prog.go:4:6: T2 refers to
./prog.go:3:6: T1
With the patch applied the error message looks like:
./prog.go:3:6: invalid recursive type T1
./prog.go:3:6: T1 refers to T2
./prog.go:4:6: T2 refers to T1
Change-Id: Ic07cdffcffb1483c672b241fede4e694269b5b79
GitHub-Last-Rev: cd042fdc38
GitHub-Pull-Request: golang/go#69574
Reviewed-on: https://go-review.googlesource.com/c/go/+/614084
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Tim King <taking@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
If a function f being considered for inlining calls
one of its parameters, reduce the normal cost of that
call (57) to 17 to increase the chance that f will
be inlined and (with luck) that parameter will be
revealed as a constant function (which unblocks
escape analysis) or perhaps even be inlined.
The least-change value for that was still effective for
iter_test benchmarks was 32; however tests showed no
particular harm even when reduced as low as 7, and there
have been reports of other performance problems with
rangefunc overheads and so I picked a middling number
in hopes of warding off such reports.
Updates #69015
Change-Id: I2a525c1beffb9f88daa14caa8a622864b023675c
Reviewed-on: https://go-review.googlesource.com/c/go/+/609095
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Tim King <taking@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
The spill/restore code around morestack is almost never exectued, so
we should make it as small as possible. Using 2-register loads/stores
makes sense here. Also, the offsets from SP are pretty small so the
offset almost always fits in the (smaller than a normal load/store)
offset field of the instruction.
Makes cmd/go 0.6% smaller.
Change-Id: I8845283c1b269a259498153924428f6173bda293
Reviewed-on: https://go-review.googlesource.com/c/go/+/621556
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>
As described in issue #69912, type checking dot-imported identifiers can
result in a call to objDecl on an imported object, which leads to a data
race to the color_ field.
There are multiple potential fixes for this race. Opt for avoiding the
call to objDecl altogether, rather than setting color_ during import.
The color_ field is an internal property of objects that should only be
valid during the type checking of their package. We should not be
calling objDecl on imported objects.
Fixes#69912
Change-Id: I55eb652479715f2a7ac84104db2f448091c4e7ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/621637
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Robert Findley <rfindley@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Currently, for Wasm, the linker sets the initial memory size to
the size of global data plus 16 MB. The intention is that it
covers the global data and runtime initialization without growing
the linear memory. However, the code accounts only the data
"section", not the bss "section", therefore the extra 16 MB is
actually used to cover bss variables. Also, as seen on the
previous CL, the runtime actually didn't use the extra space,
which means the program can start without that space.
This CL corrects the global data size calculation, and reduces the
extra to 1 MB. Currently the runtime's allocation pattern at
startup is that it allocates a few pages for the page allocator's
metadata, the an 8 MB reservation for the first 4 MB size, 4 MB
aligned heap arena (it may be possible to reduce that, but we'll
leave that for later). Here we use 1 MB extra space to cover the
small allocations, but let the runtime allocate the heap arena, so
the linker code and the runtime's allocator are not tightly
coupled.
For #69018.
Change-Id: I39fe1172382ecc03f4b537e43ec710af8075eab3
Reviewed-on: https://go-review.googlesource.com/c/go/+/621636
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
CL 476717 adopted the memory management mechanism on Plan 9 to
manage Wasm's linear memory. But the Plan 9 code uses global
variable bloc and blocMax to keep track of the runtime's and the
OS's sense of break, whereas the Wasm sbrk function doesn't use
those global variables, and directly goes to grow the linear
memory instead. This causes that if there is any unused portion at
the end of the linear memory, the runtime doesn't use it. This CL
fixes it, adopts the same mechanism as the Plan 9 code.
In particular, the runtime is not aware of any unused initial
memory at startup. Therefore, (most of) the extra initial memory
set by the linker are not actually used. This CL fixes this as
well.
For #69018.
Change-Id: I2ea6a138310627eda5f19a1c76b1e1327362e5f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/621635
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This change switches isSending to be an atomic.Int32 instead of an
atomic.Uint8. The Int32 version is managed as a counter, which is
something that we couldn't do with Uint8 without adding a new intrinsic
which may not be available on all architectures.
That is, instead of only being able to support 8 concurrent timer
firings on the same timer because we only have 8 independent bits to set
for each concurrent timer firing, we can now have 2^31-1 concurrent
timer firings before running into any issues. Like the fact that each
bit-set was matched with a clear, here we match increments with
decrements to indicate that we're in the "sending on a channel" critical
section in the timer code, so we can report the correct result back on
Stop or Reset.
We choose an Int32 instead of a Uint32 because it's easier to check for
obviously bad values (negative values are always bad) and 2^31-1
concurrent timer firings should be enough for anyone.
Previously, we avoided anything bigger than a Uint8 because we could
pack it into some padding in the runtime.timer struct. But it turns out
that the type that actually matters, runtime.timeTimer, is exactly 96
bytes in size. This means its in the next size class up in the 112 byte
size class because of an allocation header. We thus have some free space
to work with. This change increases the size of this struct from 96
bytes to 104 bytes.
(I'm not sure if runtime.timer is often allocated directly, but if it
is, we get lucky in the same way too. It's exactly 80 bytes in size,
which means its in the 96-byte size class, leaving us with some space to
work with.)
Fixes#69969.
Related to #69880 and #69312.
Change-Id: I9fd59cb6a69365c62971d1f225490a65c58f3e77
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/621616
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently, on Mach-O, the -B UUID setting is only applied in
internal linking mode, whereas in external linking mode the UUID
is always rewritten to a hash of Go build ID. This CL makes it
apply to external linking as well. This makes the behavior
consistent on both linkmodes, and also consistent with the -B
flag's behavior for GNU build ID on ELF.
Add tests.
Updates #68678.
Cq-Include-Trybots: luci.golang.try:gotip-darwin-amd64_14,gotip-darwin-arm64_13
Change-Id: I276a5930e231141440cdba16e8812df28ac4237b
Reviewed-on: https://go-review.googlesource.com/c/go/+/618599
Reviewed-by: Than McIntosh <thanm@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
With the "-B gobuildid" linker option (which will be the default
on some platforms), the host build ID (GNU build ID, Mach-O UUID)
depends on the Go buildid. If the host build ID is included in the
Go buildid computation, it will lead to convergence problem for
the toolchain binaries. So ignore the host build ID in the buildid
computation.
This CL only handles Mach-O UUID. ELF GNU build ID will be handled
later.
For #68678.
For #63934.
Cq-Include-Trybots: luci.golang.try:gotip-darwin-amd64_14,gotip-darwin-arm64_13
Change-Id: Ie8ff20402a1c6083246d25dea391140c75be40d0
Reviewed-on: https://go-review.googlesource.com/c/go/+/618597
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Than McIntosh <thanm@golang.org>
Currently the linker has some code handling and manipulating
Mach-O files. Specifically, it augments the debug/macho package
with file offset and length, so the content can be handled or
updated easily with the file.
Move this code to an internal package, so it can be used by other
part of the toolchain, e.g. buildid computation.
For #68678.
Cq-Include-Trybots: luci.golang.try:gotip-darwin-amd64_14,gotip-darwin-arm64_13
Change-Id: I2311af0a06441b7fd887ca5c6ed9e6fc44670a16
Reviewed-on: https://go-review.googlesource.com/c/go/+/618596
Reviewed-by: Than McIntosh <thanm@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently, on Mach-O, the Go linker doesn't generate LC_UUID in
internal linking mode. This causes some macOS system tools unable
to track the binary, as well as in some cases the binary unable
to access local network on macOS 15.
This CL makes the linker start generate LC_UUID. Currently, the
UUID is generated if the -B flag is specified. And we'll make it
generate UUID by default in a later CL. The -B flag is currently
for generating GNU build ID on ELF, which is a similar concept to
Mach-O's UUID. Instead of introducing another flag, we just use
the same flag and the same setting. Specifically, "-B gobuildid"
will generate a UUID based on the Go build ID.
For #68678.
Cq-Include-Trybots: luci.golang.try:gotip-darwin-amd64_14,gotip-darwin-arm64_13
Change-Id: I90089a78ba144110bf06c1c6836daf2d737ff10a
Reviewed-on: https://go-review.googlesource.com/c/go/+/618595
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ingo Oeser <nightlyone@googlemail.com>
Reviewed-by: Than McIntosh <thanm@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This is a peace-of-mind change to make sure that delayed-zeroed memory
(in the large alloc case) is globally visible from the moment the
allocation is published back to the caller.
The way it's written right now is good enough for the garbage collector
(we already have a publication barrier for a nil span.largeType, so the
GC will ignore the noscan span) but this might matter for user code on
weak memory architectures.
Change-Id: I06ac9b95863074e5f09382629083b19bfa87fdb8
Reviewed-on: https://go-review.googlesource.com/c/go/+/619036
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>
Last CL we separated mallocgc into several specialized paths. Let's
split up heapSetType too. This will make the specialized heapSetType
functions inlineable and cut out some branches as well as a function
call.
Microbenchmark results at this point in the stack:
│ before.out │ after-5.out │
│ sec/op │ sec/op vs base │
Malloc8-4 13.52n ± 3% 12.15n ± 2% -10.13% (p=0.002 n=6)
Malloc16-4 21.49n ± 2% 18.32n ± 4% -14.75% (p=0.002 n=6)
MallocTypeInfo8-4 27.12n ± 1% 18.64n ± 2% -31.30% (p=0.002 n=6)
MallocTypeInfo16-4 28.71n ± 3% 21.63n ± 5% -24.65% (p=0.002 n=6)
geomean 21.81n 17.31n -20.64%
Change-Id: I5de9ac5089b9eb49bf563af2a74e6dc564420e05
Reviewed-on: https://go-review.googlesource.com/c/go/+/614795
Auto-Submit: 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>
Reviewed-by: Keith Randall <khr@google.com>
Right now mallocgc is a monster of a function. In real programs, we see
that a substantial amount of time in mallocgc is spent in mallocgc
itself. It's very branch-y, holds a lot of state, and handles quite a few
disparate cases, trying to merge them together.
This change breaks apart mallocgc into separate, leaner functions.
There's some duplication now, but there are a lot of branches that can
be pruned as a result.
There's definitely still more we can do here. heapSetType can be inlined
and broken down for each case, since its internals roughly map to each
case anyway (done in a follow-up CL). We can probably also do more with
the size class lookups, since we know more about the size of the object
in each case than before.
Below are the savings for the full stack up until now.
│ after-3.out │ after-4.out │
│ sec/op │ sec/op vs base │
Malloc8-4 13.32n ± 2% 12.17n ± 1% -8.63% (p=0.002 n=6)
Malloc16-4 21.64n ± 3% 19.38n ± 10% -10.47% (p=0.002 n=6)
MallocTypeInfo8-4 23.15n ± 2% 19.91n ± 2% -14.00% (p=0.002 n=6)
MallocTypeInfo16-4 25.86n ± 4% 22.48n ± 5% -13.11% (p=0.002 n=6)
MallocLargeStruct-4 270.0n ± ∞ ¹
geomean 20.38n 30.97n -11.58%
Change-Id: I681029c0b442f9221c4429950626f06299a5cfe4
Reviewed-on: https://go-review.googlesource.com/c/go/+/614257
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
This change breaks out the debug.malloc codepaths into dedicated
functions, both for making mallocgc easier to read, and to reduce the
function's size (currently all that code is inlined and really doesn't
need to be).
This is a microoptimization that on its own changes very little, but
together with other optimizations and a breaking up of the various
malloc paths will matter all together ("death by a thousand cuts").
Change-Id: I30b3ab4a1f349ba85b4a1b5b2c399abcdfe4844f
Reviewed-on: https://go-review.googlesource.com/c/go/+/617879
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: 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>
These debug checks are very occasionally helpful, but they do cost real
time. The biggest issue seems to be the bloat of mallocgc due to the
"throw" paths. Overall, after some follow-ups, this change cuts about
1ns off of the mallocgc fast path.
This is a microoptimization that on its own changes very little, but
together with other optimizations and a breaking up of the various
malloc paths will matter all together ("death by a thousand cuts").
Change-Id: I07c4547ad724b9f94281320846677fb558957721
Reviewed-on: https://go-review.googlesource.com/c/go/+/617878
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
This change stops tracking assistG across malloc to reduce number of
slots the compiler must keep track of in mallocgc, which adds to
register pressure. It also makes the call to deductAssistCredit only
happen if the GC is running.
This is a microoptimization that on its own changes very little, but
together with other optimizations and a breaking up of the various
malloc paths will matter all together ("death by a thousand cuts").
Change-Id: I4cfac7f3e8e873ba66ff3b553072737a4707e2c2
Reviewed-on: https://go-review.googlesource.com/c/go/+/617876
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 Knyszek <mknyszek@google.com>
This is an allocator microoptimization. There's no reason to check
gcphase in general, since it's mostly for debugging anyway.
writeBarrier.enabled is set in all the same cases here, and we force one
fewer cache line (probably) to be touched during malloc.
Conceptually, it also makes a bit more sense. The allocate-black policy
is partly informed by the write barrier design.
Change-Id: Ia5ff593d64c29cf7f4d1bced3204056566444a98
Reviewed-on: https://go-review.googlesource.com/c/go/+/617875
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>
Checking whether the current allocation needs to be profiled is
currently branch-y and weirdly a lot of code. The branches are
generally predictable, but it's a surprising number of instructions.
Part of the problem is that MemProfileRate is just a global that can be
set at any time, so we need to load it and check certain settings
explicitly. In an ideal world, we would just always subtract from
nextSample and have a single branch to take the slow path if we
subtract below zero.
If MemProfileRate were a function, we could trash all the nextSample
values intentionally in each mcache. This would be slow, but
MemProfileRate changes rarely while the malloc hot path is well, hot.
Unfortunate...
Although this ideal world is, AFAICT, impossible, we can still get
close. If we cache the value of MemProfileRate in each mcache, then we
can force malloc to take the slow path whenever MemProfileRate changes.
This does require two additional loads, but crucially, these loads are
independent of everything else in mallocgc. Furthermore, the branch
dependent on those loads is incredibly predictable in practice.
This CL on its own has little-to-no impact on mallocgc. But this
codepath is going to be duplicated in several places in the next CL, so
it'll pay to simplify it. Also, we're very much trying to remedy a
death-by-a-thousand-cuts situation, and malloc is currently still kind
of a monster -- it will not help if mallocgc isn't really streamlined
itself.
Lastly, there's a nice property now that all nextSample values get
immediately re-sampled when MemProfileRate changes.
Change-Id: I6443d0cf9bd7861595584442b675ac1be8ea3455
Reviewed-on: https://go-review.googlesource.com/c/go/+/615815
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
This change brings back a minor optimization lost in the Go 1.22 cycle
wherein the 8-byte pointer-ful span class spans would have the pointer
bitmap written ahead of time in bulk, because there's only one possible
pattern.
│ before │ after │
│ sec/op │ sec/op vs base │
MallocTypeInfo8-4 25.13n ± 1% 23.59n ± 2% -6.15% (p=0.002 n=6)
Change-Id: I135b84bb1d5b7e678b841b56430930bc73c0a038
Reviewed-on: https://go-review.googlesource.com/c/go/+/614256
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: 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>
For whatever reason, span.heapBits is kind of slow. It accounts for
about a quarter of the cost of writeHeapBitsSmall, which is absurd. We
get a nice speed improvement for small allocations by eliminating this
call.
│ before │ after │
│ sec/op │ sec/op vs base │
MallocTypeInfo16-4 29.47n ± 1% 27.02n ± 1% -8.31% (p=0.002 n=6)
Change-Id: I6270e26902e5a9254cf1503fac81c3c799c59d6a
Reviewed-on: https://go-review.googlesource.com/c/go/+/614255
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>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
src/runtime/testdata/testprogcgo/threadprof.go contains C code with a
variable called nullptr. This conflicts with the nullptr keyword in
the C23 revision of the C standard (showing up as gccgo test build
failures when updating GCC to use C23 by default when building C
code).
Rename that variable to nullpointer to avoid the clash with the
keyword (any other name that's not a keyword would work just as well).
Change-Id: Ida5ef371a3f856c611409884e185c3d5ded8e86c
GitHub-Last-Rev: 2ec464703b
GitHub-Pull-Request: golang/go#69927
Reviewed-on: https://go-review.googlesource.com/c/go/+/620955
Auto-Submit: 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>
Reviewed-by: Ian Lance Taylor <iant@google.com>
This commit fixes the issue where tls testdata recordings made with the
newer version of the prerecorded tls conversation test harness, doesn't
end up capturing the final close notify message. The fix simply ensures
that the tls.Client closes before the recording of the conversation is
closed. The closing of the client connection directly is no longer
needed when updating the recording since it will be closed when the
tls.Client is closed.
Fixesgolang/go#69846
Change-Id: I93898de32abd89659a32ed240df6daea5aeaa7fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/620395
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Refactor TestOpenError to use relative paths in test cases,
in preparation for extending it to test os.Root.
Use a test temporary directory instead of system directory
with presumed-known contents.
Move the testcase type and case definitions inline with the test.
For #67002
Change-Id: Idc53dd9fcecf763d3e4eb3b4643032e3003d7ef4
Reviewed-on: https://go-review.googlesource.com/c/go/+/620157
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Use the new SwissTable-based map in internal/runtime/maps as the basis
for the runtime map when GOEXPERIMENT=swissmap.
Integration is complete enough to pass all.bash. Notable missing
features:
* Race integration / concurrent write detection
* Stack-allocated maps
* Specialized "fast" map variants
* Indirect key / elem
For #54766.
Cq-Include-Trybots: luci.golang.try:gotip-linux-ppc64_power10,gotip-linux-amd64-longtest-swissmap
Change-Id: Ie97b656b6d8e05c0403311ae08fef9f51756a639
Reviewed-on: https://go-review.googlesource.com/c/go/+/594596
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The PR is to add more details for the error, so that it would be easier to troubleshoot the cyclic imports error.
The change for the error looks like the following:
package cyclic-import-example
imports cyclic-import-example/packageA from /Users/personal/cyclic-import-example/main.go:4:5
imports cyclic-import-example/packageB from /Users/personal/cyclic-import-example/packageA/a.go:5:2
imports cyclic-import-example/packageA from /Users/personal/cyclic-import-example/packageB/bb.go:5:2: import cycle not allowed
Fixes#66078
Change-Id: I162cd348004bf4e4774b195f8355151c1bf0a652
GitHub-Last-Rev: c5a16256d1
GitHub-Pull-Request: golang/go#68337
Reviewed-on: https://go-review.googlesource.com/c/go/+/597035
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This is similar to CL 478196 and CL 477296,
but this is for -buildmode=shared.
When using "go install -buildmode=shared std",
because the gold linker is used by default on Linux arm64,
it will cause temporary paths to be included in libstd.so.
Based on the changes of CL 478196,
I speculate that this may also have issues on other platforms.
So, this change is for all platform.
Fixes#69464
Change-Id: I4493c82be030186e61aef597ea0e6f43bcf95a32
GitHub-Last-Rev: ee40cf81ac
GitHub-Pull-Request: golang/go#69394
Reviewed-on: https://go-review.googlesource.com/c/go/+/612396
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
syscall.Open param names are confusing, mainly because what should be
named flag is named mode and what should be named mode is named perm.
The name perm is used as synonym for mode in other places, so keep
it as is. Rename mode to flag to match the real meaning of the
parameter. Also, rename path to name for consistency with other
usage of the same parameter.
Change-Id: Ideed09839d80c0383584c2268afbb6cc09ffda8c
Reviewed-on: https://go-review.googlesource.com/c/go/+/619276
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>
syscall.Open is the functions that maps Unix/Go flags into Windows
concepts. Part of the flag validation logic was still implemented
in os.OpenFile, move it to syscall.Open for consistency.
A nice side effect is that we don't have to translate the file name
twice in case of an access denied error.
Change-Id: I32c647a9a2a066277c78f53bacb45fb3036f6353
Reviewed-on: https://go-review.googlesource.com/c/go/+/619275
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
The current implementation of O_TRUNC in syscall.Open on Windows is
prone to TOCTOU issues, as it opens the file twice if the first open
detects that the file doesn't exist. The file could
be created in between the two open calls, leading to the creation
of a new file with the undesired readonly attribute.
This CL implements O_TRUNC by just calling CreateFile once without
taking O_TRUNCATE into account, and then using Ftruncate if O_TRUNC is
set to truncate the file.
Updates #38225.
Change-Id: Ic3ad1bab75c9a1c16f99c8c5bed867c5dbc3a23b
Reviewed-on: https://go-review.googlesource.com/c/go/+/618836
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The syscall package is mostly frozen, but wasip1 file syscall
support was added to syscall and the Open and Openat
implementations overlap. Implement Openat in syscall for
overall simplicity.
We already have syscall.Openat for some platforms, so this
doesn't add any new functions to syscall.
For #67002
Change-Id: Ia34b12ef11fc7a3b7832e07b3546a760c23efe5b
Reviewed-on: https://go-review.googlesource.com/c/go/+/617378
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The TestMkdirStickyUmask modifies the umask for testing purpose.
When run in parallel with TestCopyFS, this temporary umask change can cause TestCopyFS to create files with unintended permissions, leading to test failures.
This change removes the t.Parallel call in TestMkdirStickyUmask to prevent interference with TestCopyFS, ensuring it doesn't run concurrently with the other tests that require umask.
Fixes#69788
Change-Id: I9cf1da9f92283340ff85d2721781760a750d124c
Reviewed-on: https://go-review.googlesource.com/c/go/+/618055
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Commit-Queue: Ian Lance Taylor <iant@google.com>
This change replaces the MD5 hash used to identify coverage files with a
128-bit FNV-1a hash. This change is motivated by the fact that MD5
should only be used for legacy cryptographic purposes.
The 128-bit FNV-1a hash is sufficient for the purpose of identifying
coverage files, it having the same theoretical collision resistance as
MD5, but with the added benefit of being faster to compute.
Change-Id: I7b547ce2ea784f8f4071599a10fcb512b87ee469
Reviewed-on: https://go-review.googlesource.com/c/go/+/617360
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Than McIntosh <thanm@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
OpenBSD system calls are mediated by libc anyway, and arc4random_buf()
is the preferred mechanism to obtain random bytes.
Also, rename NetBSD's function to reflect it's not actually calling
getentropy(3).
Cq-Include-Trybots: luci.golang.try:gotip-openbsd-amd64
Change-Id: Id1f3f7af16750537e2420bcf44b086de5854198c
Reviewed-on: https://go-review.googlesource.com/c/go/+/608395
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Bypass: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reintroduce the urandom fallback, but this time with a robust set of
tests all pointing guns at each other, including a seccomp'd respawn
simulating the lack of getrandom, to make sure the fallback both works
and is never hit unexpectedly.
Unlike the Go 1.23 fallback, the new one only triggers on ENOSYS (which
is cached by unix.GetRandom) and doesn't handle the EAGAIN errors we
never got an explanation for.
We still crash the program from Read if we have to go to /dev/urandom
and we fail to open it.
For #67001
Updates #66821
Tested on legacy SlowBots (without plan9 and illumos, which don't work):
TRY=aix-ppc64,dragonfly-amd64,freebsd-amd64,freebsd-386,netbsd-amd64
Cq-Include-Trybots: luci.golang.try:gotip-darwin-amd64_14,gotip-solaris-amd64,gotip-js-wasm,gotip-wasip1-wasm_wasmtime,gotip-wasip1-wasm_wazero,gotip-windows-amd64,gotip-windows-386,gotip-linux-386,gotip-linux-amd64-longtest-race,gotip-linux-amd64-boringcrypto
Change-Id: Idecc96a18cd6363087f5b2a4671c6fd1c41a3b0e
Reviewed-on: https://go-review.googlesource.com/c/go/+/608175
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
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>
The fallback was reachable on
- Linux, where starting in Go 1.24 we require a kernel with
getrandom(2), see #67001.
- FreeBSD, which added getrandom(2) in FreeBSD 12.0, which we
require since Go 1.19.
- OpenBSD, which added getentropy(2) in OpenBSD 5.6, and we only
support the latest version.
- DragonFly BSD, which has getrandom(2) and where we support only
the latest version.
- NetBSD, where we switched to kern.arandom in CL 511036, available
since NetBSD 4.0.
- illumos, which has getrandom(2). (Supported versions unclear.)
- Solaris, which had getrandom(2) at least since Oracle
Solaris 11.4.
- AIX, which... ugh, fine, but that code is now in rand_aix.go.
At the end of the day the platform-specific code is just a global
func(b []byte) error, so simplified the package around that assumption.
This also includes the following change, which used to be a separate CL.
crypto/rand: improve getrandom batching and retry logic
The previous logic assumed getrandom never returned short, and then
applied stricter-than-necessary batch size limits, presumably to
avoid short returns.
This was still not sufficient because above 256 bytes getrandom(2)
can be interrupted by a signal and return short *or* it can simply
return EINTR if the pool is not initialized (regardless of buffer
size).
https://man.archlinux.org/man/getrandom.2#Interruption_by_a_signal_handler
Whether this ever failed in practice is unknown: it would have been
masked by the /dev/urandom fallback before.
Instead, we apply buffer size limits only where necessary (really,
only Solaris in practice and FreeBSD in theory) and then handle
gracefully short returns and EINTR.
Change-Id: I8677b457aab68a8fb6137a3b43538efc62eb7c93
It turns out that we now know that large getrandom calls *did* fail in
practice, falling back on /dev/urandom, because when we removed the
fallback TestBidiStreamReverseProxy with its 4KiB read started failing.
https://cr-buildbucket.appspot.com/build/8740779846954406033
For #66821
Change-Id: Iaca62997604f326501a51401cdc2659c2790ff22
Reviewed-on: https://go-review.googlesource.com/c/go/+/602495
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
During type inference, when comparing type parameters against their
constraints, if a type argument is completely known it must implement
its constraint. In this case, always unify the type argument's methods
against the constraint methods, if any.
Before this CL, this step was only attempted if the constraint had no
core type. That left information unused which led to type inference
failures where it should have succeeded.
Fixes#66751.
Change-Id: I71e96b71258624212186cf17ec47e67a589817b9
Reviewed-on: https://go-review.googlesource.com/c/go/+/617896
Reviewed-by: Tim King <taking@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Inside Google we have seen issues with QEMU user mode failing to wake a
parent waitid when this child exits with SYS_EXIT. This bug appears to
not affect SYS_EXIT_GROUP.
It is currently unclear if this is a general QEMU or specific to
Google's configuration, but SYS_EXIT and SYS_EXIT_GROUP are semantically
equivalent here, so we can use the latter here in case this is a general
QEMU bug.
For #68976.
Change-Id: I34e51088c9a6b7493a060e2a719a3cc4a3d54aa0
Reviewed-on: https://go-review.googlesource.com/c/go/+/617417
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
I've done some more testing of the new isSending field.
I'm not able to get more than 2 bits set. That said,
with this change it's significantly less likely to have even
2 bits set. The idea here is to clear the bit before possibly
locking the channel we are sending the value on, thus avoiding
some delay and some serialization.
For #69312
Change-Id: I8b5f167f162bbcbcbf7ea47305967f349b62b0f4
Reviewed-on: https://go-review.googlesource.com/c/go/+/617497
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Knyszek <mknyszek@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>
While working on CL 611241 and CL 616375, I introduced a bug that wasn't
caught by any test. CL 611241 added more inline expansion at sample time
for block/mutex profile stacks collected via frame pointer unwinding.
CL 616375 then changed how inline expansion for those stacks is done at
reporting time. So some frames passed through multiple rounds of inline
expansion, and this lead to duplicate stack frames in some cases. The
stacks from TestBlockMutexProfileInlineExpansion looked like
sync.(*Mutex).Unlock
runtime/pprof.inlineF
runtime/pprof.inlineE
runtime/pprof.inlineD
runtime/pprof.inlineD
runtime.goexit
after those two CLs, and in particular after CL 616375. Note the extra
inlineD frame. The test didn't catch that since it was only looking for
a few frames in the stacks rather than checking the entire stacks.
This CL makes that test stricter by checking the entire expected stacks
rather than just a portion of the stacks.
Change-Id: I0acc739d826586e9a63a081bb98ef512d72cdc9a
Reviewed-on: https://go-review.googlesource.com/c/go/+/617235
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>
I noticed in pprof that acquirem() was a bit of a hotspot. It turns out
that we can use the same trick that runtime.rand() does, and only
acquirem if we're doing something non-nosplit -- in this case, getting a
new state -- but otherwise just do getg().m, which is safe because we're
inside runtime and don't call split functions.
cpu: 11th Gen Intel(R) Core(TM) i7-11850H @ 2.50GHz
│ sec/op │ sec/op vs base │
ParallelGetRandom-16 2.651n ± 4% 2.416n ± 7% -8.87% (p=0.001 n=10)
│ B/s │ B/s vs base │
ParallelGetRandom-16 1.406Gi ± 4% 1.542Gi ± 6% +9.72% (p=0.001 n=10)
Change-Id: Iae075f4e298b923e499cd01adfabacab725a8684
Reviewed-on: https://go-review.googlesource.com/c/go/+/616738
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>
The existing prose for struct identity did only require that two structs
"have the same sequence of fields, and if corresponding fields have the
same names, and identical types, and identical tags" for the structs to
be identical.
The implementation (forever) has also required that two corresponding
fields are either both embedded or not embedded. This is arguably part
of a struct's structure but is not explicitly specified.
This CL makes a minor change to the prose to address that.
Fixes#69472.
Change-Id: Ifa4ca69717986675642a09d03ce683ba8235efcb
Reviewed-on: https://go-review.googlesource.com/c/go/+/616697
Reviewed-by: Rob Pike <r@golang.org>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Before this patch, the documentation of Dialer.Control and
ListenConfig.Control did not specify what networks would be
passed to the Control function other than the "tcp" case.
It was thus challenging to use the Control function to filter
out certain networks. This patch documents all known networks.
Fixes#69693
Change-Id: I2ab10d68c4e4fac66d51d2cc232f02cf3b305e89
Reviewed-on: https://go-review.googlesource.com/c/go/+/617055
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
CL 615915 simplified test for issue 69434, using gcflags maymorestack to
force stack moving, making program failed with invalid stack pointer.
However, it seems that this maymorestack is broken on riscv64. At least
gotip-linux-riscv64 is currently broken.
This CL fixes this problem by using the initial approach, growing stack
size big enough to force stack moving.
Updates #69434Fixes#69714
Cq-Include-Trybots: luci.golang.try:gotip-linux-riscv64
Change-Id: I95255fba884a200f75bcda34d58e9717e4a952ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/616698
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: David Chase <drchase@google.com>
Over the years we've had various bugs in pprof stack handling resulting
in appendLocsForStack crashing because stk is too short for a cached
location. i.e., the cached location claims several inlined frames. Those
should always appear together in stk. If some frames are missing from
stk, appendLocsForStack.
If we find this case, replace the slice out of bounds panic with an
explicit panic that contains more context.
Change-Id: I52725a689baf42b8db627ce3e1bc6c654ef245d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/617135
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>
This change adds a new environment variable GOAUTH which takes a semicolon-separated list of commands to run for authentication during go-import resolution and HTTPS module mirror protocol interactions.
This CL only supports netrc and off. Future CLs to follow will extend support to git and a custom authenticator command.
For #26232
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Change-Id: I6cfa4c89fd27a7a4e7d25c8713d191dc82b7e28a
Reviewed-on: https://go-review.googlesource.com/c/go/+/605256
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
Using a different build of Go (specifically, a different GOROOT) to
maintain the vendor directory doesn't always reproduce the same results.
This can result in unknowingly creating a vendor directory that isn't
able to build Go.
Add a note to README.vendor to point this out. Specifically, mention
that a mismatched GOROOT is an issue, and recommend using a fresh build
of Go to maintain the vendor directory.
Updates #69235
Change-Id: Id80c7607bf28bd76e43e1fdc672811c50f2bffb3
Reviewed-on: https://go-review.googlesource.com/c/go/+/616815
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Sam Thanawalla <samthanawalla@google.com>
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
This commit amends package errors' documentation to include a reference
to the https://go.dev/blog/go1.13-errors blog article. The motivation
is multi-fold, but chiefly the article includes good information about
error philosophy (e.g., when to wrap), and developers who have come to
Go in the intervening five years are likely not have seen this article
at all given the nature of blog publishing and post fanfare. The
material deserves a promotion in visibility.
Change-Id: Ia6f8307784521dd59de3a3d638dbc0a7fcd445e6
GitHub-Last-Rev: 20980dd507
GitHub-Pull-Request: golang/go#69698
Reviewed-on: https://go-review.googlesource.com/c/go/+/616341
Reviewed-by: Jonathan Amsterdam <jba@google.com>
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>
The source code quoted tailscale's development fork, which is only a
development fork. The canonical github url is actually
github.com/wireguard/wireguard-go, but that's really just a mirror of
git.zx2c4.com/wireguard-go, and in any case, the proper go package name
is golang.zx2c4.com/wireguard, so just use that.
Change-Id: Ifa63c1c538989b3fcebcf06d1c238469bc73724d
Reviewed-on: https://go-review.googlesource.com/c/go/+/616736
Auto-Submit: Jason Donenfeld <Jason@zx2c4.com>
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>
This prevents false sharing, which makes a large difference on machines
with several NUMA nodes, such as this dual socket server:
cpu: Intel(R) Xeon(R) Gold 6338 CPU @ 2.00GHz
│ sec/op │ sec/op vs base │
ParallelGetRandom-128 0.7944n ± 5% 0.4503n ± 0% -43.31% (p=0.000 n=10)
│ B/s │ B/s vs base │
ParallelGetRandom-128 4.690Gi ± 5% 8.272Gi ± 0% +76.38% (p=0.000 n=10)
Change-Id: Id4421e9a4c190b38aff0be4c59e9067b0a38ccd7
Reviewed-on: https://go-review.googlesource.com/c/go/+/616535
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Jason Donenfeld <Jason@zx2c4.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
This CL adds a local only VCS lookup for Mercurial.
It fixes a bug in pkg.go by passing in the repo directory to
the LookupLocal function instead of the module directory. It could be
the case that a binary is built in a subdirectory of the repo.
For: #50603
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Change-Id: Ic36b5a361a8ba3b0ba1a6968cde5f5263c9c8dd0
Reviewed-on: https://go-review.googlesource.com/c/go/+/609155
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Linux 6.11 supports calling getrandom() from the vDSO. It operates on a
thread-local opaque state allocated with mmap using flags specified by
the vDSO.
Opaque states are allocated in chunks, ideally ncpu at a time as a hint,
rounding up to as many fit in a complete page. On first use, a state is
assigned to an m, which owns that state, until the m exits, at which
point it is given back to the pool.
Performance appears to be quite good:
│ sec/op │ sec/op vs base │
Read/4-16 222.45n ± 3% 27.13n ± 6% -87.80% (p=0.000 n=10)
│ B/s │ B/s vs base │
Read/4-16 17.15Mi ± 3% 140.61Mi ± 6% +719.82% (p=0.000 n=10)
Fixes#69577.
Change-Id: Ib6f44e8f2f3940c94d970eaada0eb566ec297dc7
Reviewed-on: https://go-review.googlesource.com/c/go/+/614835
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Jason Donenfeld <Jason@zx2c4.com>
Reviewed-by: Paul Murphy <murp@ibm.com>
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>
There were a few Mercurial command line uses that could cause the wrong
data to be used:
* The log command needs '-r.' to specify the currently checked out commit
* HGPLAIN is needed to disable optional output on commands
* '-S' is needed to for the 'status' command to recurse into any subrepos
The most likely issue to be seen here was the use of '-l1' instead of
'-r.', which prints the most recent commit instead of the current checkout.
Since tagging in Mercurial creates a new commit, this basically means the
data was wrong for every tagged build.
This also adds an hgrc config file to the test, with config options to
keep the time and author values fixed. It's what's used in the Mercurial
test harness to keep the commit hashes stable, and allows the tests here to
also match the time and the revision ID, to prevent regressing.
Fixes#63532
Change-Id: I5b9971ce87c83431ec77e4a002bdc33fcf393856
GitHub-Last-Rev: 62c9db0a28
GitHub-Pull-Request: golang/go#63557
Reviewed-on: https://go-review.googlesource.com/c/go/+/535377
Reviewed-by: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
Auto-Submit: Sam Thanawalla <samthanawalla@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
This moves the implementation of Scope.LookupParent into
environment.lookupScope where it encapsulates the use of
the current environment's position. At least in types2,
that position can be removed, because it is never set.
With this, the type checker doesn't rely on position
information anymore for looking up objects during type
checking.
LookupParent is still called from tests and some go/types
code.
Updates #69673.
Change-Id: I7159ba95b71cf33cc3b16058aa19327e166224b1
Reviewed-on: https://go-review.googlesource.com/c/go/+/616337
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
In extremely rare cases of receiver base types of the form
C.foo where C refers to an `import "C"`, we needed Scope.Contains
to lookup the file scope containing the "C" import.
Replace the position-dependent Scope.Contains with an explicit
scope search that doesn't require a position.
Also, make the surrounding code match more closely between
go/types and types2.
Change-Id: Ic007108928dd8b382a06e2bbf09ef8bd6bd0ff36
Reviewed-on: https://go-review.googlesource.com/c/go/+/616256
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
On Arch Linux with gdb version 15.1, the test for TestGdbAutotmpTypes print
the following output,
----
~/src/go/src/runtime
$ go test -run=TestGdbAutotmpTypes -v
=== RUN TestGdbAutotmpTypes
=== PAUSE TestGdbAutotmpTypes
=== CONT TestGdbAutotmpTypes
runtime-gdb_test.go:78: gdb version 15.1
runtime-gdb_test.go:570: gdb output:
Loading Go Runtime support.
Target 'exec' cannot support this command.
Breakpoint 1 at 0x46e416: file /tmp/TestGdbAutotmpTypes750485513/001/main.go, line 8.
This GDB supports auto-downloading debuginfo from the following URLs:
<https://debuginfod.archlinux.org>
Enable debuginfod for this session? (y or [n]) [answered N; input not from terminal]
Debuginfod has been disabled.
To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit.
[New LWP 355373]
[New LWP 355374]
[New LWP 355375]
[New LWP 355376]
Thread 1 "a.exe" hit Breakpoint 1, main.main () at /tmp/TestGdbAutotmpTypes750485513/001/main.go:8
8 func main() {
9 var iface interface{} = map[string]astruct{}
All types matching regular expression "astruct":
File runtime:
[]main.astruct
bucket<string,main.astruct>
hash<string,main.astruct>
main.astruct
typedef hash<string,main.astruct> * map[string]main.astruct;
typedef noalg.[8]main.astruct noalg.[8]main.astruct;
noalg.map.bucket[string]main.astruct
runtime-gdb_test.go:587: could not find []main.astruct; in 'info typrs astruct' output
!!! FAIL
exit status 1
FAIL runtime 0.273s
$
----
In the back trace for "File runtime", each output lines does not end with
";" anymore, while in test we check the string with it.
While at it, print the expected string with "%q" instead of "%s" for
better error message.
Fixes#67089
Change-Id: If6019ee68c0d8e495c920f98568741462c7d0fd0
Reviewed-on: https://go-review.googlesource.com/c/go/+/598135
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
The timer code is careful to ensure that if stop/reset is called
while a timer is being run, we cancel the run. However, the code
failed to ensure that in that case stop/reset returned true,
meaning that the timer had been stopped. In the racing case
stop/reset could see that t.when had been set to zero,
and return false, even though the timer had not and never would fire.
Fix this by tracking whether a timer run is in progress,
and using that to reliably detect that the run was cancelled,
meaning that stop/reset should return true.
Fixes#69312
Change-Id: I78e870063eb96650638f12c056e32c931417c84a
Reviewed-on: https://go-review.googlesource.com/c/go/+/611496
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
When using the -x or -n option, we were printing the external
linker error messages from producing the dynimport file.
This was confusing because those linker errors are unimportant and
ignored; only the linker exit status matters, and failure doesn't
drop the build.
Change cmd/go -x to not print the error messages, and to instead
print the linker command line with a notation of whether the
link succeeded or failed.
Fixes#68743
Change-Id: Ie3cc58d2d6a7d33d7baa6f1273b4fb5a7deee7e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/615916
Reviewed-by: Michael Matloob <matloob@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The old calculation just looked whether PC was within a page of a vDSO
symbol. This doesn't work because the vDSO .text might span two whole
pages, with trampolines and such redirecting PC around between them.
This manifests itself with the new vDSO getrandom() function, where on
PowerPC, the trampoline is quite far away from the actual C function it
jumps into. The effect is that the signal handler doesn't know it's
interrupting a vDSO call and forgets to restore g to R30, resulting in a
crash.
Fix this by storing the start and end of the LOAD section from the
program headers. We could be more specific and parse out the .text
section, but PT_LOAD is good enough and appears to work well.
Change-Id: I3cf16955177eedb51e28b3b1a0191b32c3327a42
Reviewed-on: https://go-review.googlesource.com/c/go/+/616015
Auto-Submit: Jason Donenfeld <Jason@zx2c4.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Previously, the Checker.allowVersion method would use a token.Pos
to try to infer which file of the current package the checker
was "in". This proved fragile when type-checking syntax that
had been modified or synthesized and whose positions were invalid.
This change records the effective version in the checker state
(checker.environment.version). Just like other aspects of the
environment, the version changes from one file to the next
and must be saved and restored with each check.later closure.
Similarly, declInfo captures and temporarily reinstates
the effective version when checking each object.
+ Test of position independence in go/types and types2
+ Test of panic avoidance in go/types
Fixesgolang/go#69477Fixesgolang/go#69338
Change-Id: Ic06f9d88151c64a4f7848f8942d08e3c312cdd6f
Reviewed-on: https://go-review.googlesource.com/c/go/+/613735
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The SSA backend currently only handle struct with up to 4 fields. Thus,
there are different operations corresponding to number fields of the
struct.
This CL generalizes these with just one OpStructMake, allow struct types
with arbitrary number of fields.
However, the ssa.MaxStruct is still kept as-is, and future CL will
increase this value to optimize large structs.
Updates #24416
Change-Id: I192ffbea881186693584476b5639394e79be45c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/611075
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>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
The SignPSS hash override happened after the boringcrypto block, meaning
if a boringcrypto user passed a hash in the PSSOptions which did not
match the hash argument, it wouldn't be overriden. This change moves the
check above the boring block to make sure the override is honored.
Thanks to Quim Muntal of Microsoft for spotting this issue.
Change-Id: I05082a84ccb1863798ac6eae7a15cf4d1e59f12d
Reviewed-on: https://go-review.googlesource.com/c/go/+/614276
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: David Chase <drchase@google.com>
Fix a regression introduced in CL 572396 causing goroutine stacks not
getting null terminated.
This bug impacts callers that reuse the []StackRecord slice for multiple
calls to GoroutineProfile. See https://github.com/felixge/fgprof/issues/33
for an example of the problem.
Add a test case to prevent similar regressions in the future. Use null
padding instead of null termination to be consistent with other profile
types and because it's less code to implement. Also fix the
ThreadCreateProfile code path.
Fixes#69243
Change-Id: I0b9414f6c694c304bc03a5682586f619e9bf0588
Reviewed-on: https://go-review.googlesource.com/c/go/+/609815
Reviewed-by: Tim King <taking@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Fix a regression introduced in CL 598515 causing runtime.MutexProfile
stack traces to omit their root frames.
In most cases this was merely causing the `runtime.goexit` frame to go
missing. But in the case of runtime._LostContendedRuntimeLock, an empty
stack trace was being produced.
Add a test that catches this regression by checking for a stack trace
with the `runtime.goexit` frame.
Also fix a separate problem in expandFrame that could cause
out-of-bounds panics when profstackdepth is set to a value below 32.
There is no test for this fix because profstackdepth can't be changed at
runtime right now.
Fixes#69335
Change-Id: I1600fe62548ea84981df0916d25072c3ddf1ea1a
Reviewed-on: https://go-review.googlesource.com/c/go/+/611615
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Nick Ripley <nick.ripley@datadoghq.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Preparation for removing the existing non-standard iterators
(is, underIs). Note that we cannot use typeset iterators in
range-over-func because the bootstrap compiler doesn't have
access to it yet.
While at it, move underIs from expr.go to under.go
and adjust some doc strings in typset.go to match
prevailing style in that file.
Change-Id: Iecd014eeb5b3fca56a807381c148c5f7a29bfb78
Reviewed-on: https://go-review.googlesource.com/c/go/+/614239
Reviewed-by: Tim King <taking@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>
Commit-Queue: Robert Griesemer <gri@google.com>
Like for Named types, print type parameters for Alias types.
Add test case for Alias object string to existing test.
To make the test work, factor out the mechanism to set
GOEXPERIMENT=aliastypeparams at test time and use it
for this test as well.
No test case for un-instantiated generic type Alias type
string: there's no existing test framework, the code is
identical as for Named types, and these strings only appear
in tracing output. Tested manually.
Change-Id: I476d04d0b6a7c18b79be1d34a9e3e072941df83f
Reviewed-on: https://go-review.googlesource.com/c/go/+/615195
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Tim King <taking@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Since we added a local context to git lookups, we need to be more
careful about fetching from remote.
We should not fetch when we are stamping a binary because that could
slow down builds.
For #50603
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Change-Id: I81a719b7609e8d30b32ffb3c12a05074c5fd0c22
Reviewed-on: https://go-review.googlesource.com/c/go/+/611916
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
They are constant time, but some constants were incorrect. This
resulting in reading beyond the tables.
I've added linux specific tests which verify these functions are not
reading beyond the limits of their table.
Thank you Sun Yimin, @emmansun for catching this bug and suggesting
corrected constants.
Fixes#69080
Cq-Include-Trybots: luci.golang.try:gotip-linux-ppc64_power10,gotip-linux-ppc64_power8,gotip-linux-ppc64le_power10,gotip-linux-ppc64le_power8,gotip-linux-ppc64le_power9
Change-Id: Id37e0e22b2278ea20adaa1c84cbb32c3f20d4cf7
Reviewed-on: https://go-review.googlesource.com/c/go/+/608816
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Archana Ravindar <aravinda@redhat.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The Frames function is almost an iter.Seq, except for its bool return
value.
Since none of the callers in the Go tree rely on the bool, we can remove
it. However, doing so might still obscure the intended usage as an iterator.
This refactor changes the API to return iter.Seq, making the intended
usage explicit. Refactoring the existing callers to take advantage of
the new interface will be done in a follow-up CL.
Change-Id: I03e4d6d762910e418cc37d59a6c519eb7f39b3b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/608855
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TestScript is very slow on Plan 9 because this test
is particularly i/o intensive.
This is leading the plan9/386 and plan9/amd64 builders
to time out. This test was already skipped on plan9/arm
because arm is part of the "slow architectures" list.
This change skips TestScript on Plan 9 on short mode.
Change-Id: I3e68046dac825cd14fa8daca601c492cf11c6fff
Reviewed-on: https://go-review.googlesource.com/c/go/+/614855
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: David du Colombier <0intro@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Bypass: Ian Lance Taylor <iant@golang.org>
With b.Loop() in place, the time measurement of loop scaling could be improved to be tighter. By identifying the first call to b.Loop(), we can avoid measuring the expensive ramp-up time by reset the timer tightly before the loop starts. The remaining loop scaling logic of b.N style loop is largely reused.
For #61515.
Change-Id: Ia7b8f0a8838f57c00ac6c5ef779d86f8d713c9b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/612835
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>
It makes use of the hiter structure which matches runtime.hiter's.
This change mainly improves the performance of Next method of MapIter.
goos: darwin
goarch: arm64
pkg: reflect
cpu: Apple M2
│ ./old.txt │ ./new.txt │
│ sec/op │ sec/op vs base │
MapIterNext-8 61.95n ± 0% 54.95n ± 0% -11.28% (p=0.000 n=10)
for the change of `test/escape_reflect.go`:
removing mapiterkey, mapiterelem would cause leaking MapIter content
when calling SetIterKey and SetIterValue,
and this may cause map bucket to be allocated on heap instead of stack.
Reproduce:
```
{
m := map[int]int{1: 2} // escapes to heap after this change
it := reflect.ValueOf(m).MapRange()
it.Next()
var k, v int
reflect.ValueOf(&k).Elem().SetIterKey(it)
reflect.ValueOf(&v).Elem().SetIterValue(it)
println(k, v)
}
```
This CL would not introduce abi.NoEscape to fix this. It may need futher
optimization and tests on hiter field usage and its escape analysis.
Fixes#69416
Change-Id: Ibaa33bcf86228070b4a505b9512680791aa59f04
Reviewed-on: https://go-review.googlesource.com/c/go/+/612616
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>
This CL introduces the ability to print information about the toolchain switch used in the
go command, controlled by the `toolchaintrace` setting. This setting defaults to `toolchaintrace=0`,
meaning no information is printed. Setting it to `toolchaintrace=1` will cause the go command
to print a message indicating the toolchain used and where it was found.
Fixes: #63939
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Change-Id: Idc58e3d5bc76573aa48e1f7df352caa13004c25e
Reviewed-on: https://go-review.googlesource.com/c/go/+/610235
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This CL special-case User.GroupIds to get the group IDs from the user's
token when the user is the current user.
This approach is more efficient than calling NetUserGetLocalGroups.
It is also more reliable for users joined to an Active Directory domain,
where NetUserGetLocalGroups is likely to fail.
Updates #26041.
Fixes#62712.
Cq-Include-Trybots: luci.golang.try:gotip-windows-arm64
Change-Id: If7c30287192872077b98a514bd6346dbd1a64fb4
Reviewed-on: https://go-review.googlesource.com/c/go/+/611116
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Tim King <taking@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Before this change, test binaries didn't have build info populated on them
unless they were tests for package main. Now we generate them for all
test binaries so that they can be inspected like other binaries.
We don't need to add the default GODEBUG in printLinkerConfig because it
will now always be present on the build info, and when build info is
present we use it to generate the hash.
Fixes#33976
Change-Id: Ib4f51c04f87df3c7f2f21c400ab446e70d66a101
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/613096
Auto-Submit: 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>
CL 28490 speeded up non-ASCII rune decoding, and ASCII rune is also
decoded faster now.
Benchmark using:
perflock -governor 70% go test -run=NONE -bench=BenchmarkRuneCountInString -count=10
Result:
name old time/op new time/op delta
RuneCountInStringTenASCIIChars-8 10.2ns ± 0% 7.1ns ± 1% -30.53% (p=0.000 n=8+9)
RuneCountInStringTenJapaneseChars-8 49.3ns ± 2% 38.5ns ± 2% -21.84% (p=0.000 n=8+8)
Fixes#13162
Change-Id: Ifb01f3799c5c93e7f7c7af13a95becfde85ae807
Reviewed-on: https://go-review.googlesource.com/c/go/+/612617
Reviewed-by: Tim King <taking@google.com>
Reviewed-by: Ian Lance Taylor <iant@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>
Auto-Submit: Tim King <taking@google.com>
clone(CLONE_PIDFD) was added in Linux 5.2 and pidfd_open was added in
Linux 5.3. Thus our feature check for pidfd_open should be sufficient to
ensure that clone(CLONE_PIDFD) works.
Unfortuantely, some alternative Linux implementations may not follow
this strict ordering. For example, QEMU 7.2 (Dec 2022) added pidfd_open,
but clone(CLONE_PIDFD) was only added in QEMU 8.0 (Apr 2023).
Debian bookworm provides QEMU 7.2 by default.
Fixes#69259.
Change-Id: Ie3f3dc51f0cd76944871bf98690abf59f68fd7bf
Reviewed-on: https://go-review.googlesource.com/c/go/+/592078
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The ANDN, ORN and XNOR RISC-V Zbb extension instructions are easily
synthesised. Make them always available by adding support to the
riscv64 assembler so that we either emit two instruction sequences,
or a single instruction, when permitted by the GORISCV64 profile.
This means that these instructions can be used unconditionally,
simplifying compiler rewrite rules, codegen tests and manually
written assembly.
Around 180 instructions are removed from the Go binary on riscv64
when built with rva22u64.
Change-Id: Ib2d90f2593a306530dc0ed08a981acde4d01be20
Reviewed-on: https://go-review.googlesource.com/c/go/+/611895
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com>
Reviewed-by: Tim King <taking@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Previously we expected the default GODEBUG that's embedded in the binary
to be taken into account for build actionIDs through the build info. The
build info contains the default GODEBUG for a package main, and then
that build info is used to generate the action id. But tests of packages
other than main do not have buildinfo set on them. So the default
GODEBUG isn't taken into account in the action id for those tests.
Explicitly include GODEBUG when generating all link actions' action ids
to make sure it's always present.
Fixes#69203
Change-Id: Ifbc58482454ecfb51ba09cfcff02972cac3270c1
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/610875
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
The function resultsToWasmFields was originally for only
wasmimport. I adopted it for wasmexport as well, but forgot to
update a few places that were wasmimport-specific. This leads to
compiler panic if an invalid result type is passed, and also
unsafe.Pointer not actually supported. This CL fixes it.
Updates #65199.
Change-Id: I9bbd7154b70422504994840ff541c39ee596ee8f
Reviewed-on: https://go-review.googlesource.com/c/go/+/611315
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Achille Roussel <achille.roussel@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
asm_riscv64.h will be used to define macros for each riscv64
extension that is not part of the rva20u64 base profile but that the
_riscv64.s assembly files are allowed to use because the user has
specified a more capable profile in the GORISCV64 variable. This will
allow us, for example, to test for the hasZba macro in those assembly
files instead of the GORISCV64_rva22u64 macro before using a Zba
instruction. This is important as it means that in the future when
we add support for new profiles that support Zba, e.g., rva23u64,
we only need to update asm_riscv64.h to indicate rva23u64 supports
Zba. We will not need to update every assembly language file that
already uses Zba instructions.
Updates #61476
Change-Id: I83abfeb20d08a87ac8ea88f4d8a93437f0631353
Reviewed-on: https://go-review.googlesource.com/c/go/+/608255
Auto-Submit: Tim King <taking@google.com>
Reviewed-by: Tim King <taking@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com>
Reviewed-by: Joel Sing <joel@sing.id.au>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This field is present during the initial development of generic support
inside compiler, and indicating whether a type is fully instantiated is
the solely purpose at this moment. Further, its name is also confused,
and there have been a TODO to chose a better name for it.
Instead, just using a bit to track whether a type is fully instantiated,
then this rparams field can be removed to simplify the code.
Change-Id: Ia29c6dd5792487c440b83b0f3b77bd60917c2019
Reviewed-on: https://go-review.googlesource.com/c/go/+/611255
Reviewed-by: Tim King <taking@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Use OTAILCALL in wrapper if the receiver and method are both pointers and it is
not going to be inlined, similar to how it is done in reflectdata.methodWrapper.
Currently tail call may be used for functions with identical argument types.
This change updates wrappers where both wrapper and the wrapped method's
receiver are pointers. In this case, we have the same signature for the
wrapper and the wrapped method (modulo the receiver's pointed-to types),
and do not need any local variables in the generated wrapper (on stack)
because the arguments are immediately passed to the wrapped method in place
(without need to move some value passed to other register or to change any
argument/return passed through stack). Thus, the wrapper does not need its
own stack frame.
This applies to promoted methods, e.g. when we have some struct type U with
an embedded type *T and construct a wrapper like
func (recv *U) M(arg int) bool { return recv.T.M(i) }
See also test/abi/method_wrapper.go for a running example.
Code size difference measured with this change (tried for x86_64):
etcd binary:
.text section size: 21472251 -> 21432350 (0.2%)
total binary size: 32226640 -> 32191136 (0.1%)
compile binary:
.text section size: 17419073 -> 17413929 (0.03%)
total binary size: 26744743 -> 26737567 (0.03%)
Change-Id: I9bbe730568f6def21a8e61118a6b6f503d98049c
Reviewed-on: https://go-review.googlesource.com/c/go/+/578235
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>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
The telemetry script test checks for the existence of telemetry data as
a baseline before checking that the act of setting telemtetry to off
while in local mode doesn't produce telemetry data. Of course, when
we're running on platforms where telemetry is not supported, telemetry
data won't be produced on disk either way. Only check for the existence
of telemetry data on supported platforms.
For #69269
Change-Id: I3a06bbc3d3ca0cf0203b84883f632ecfd9445aae
Reviewed-on: https://go-review.googlesource.com/c/go/+/611876
Reviewed-by: Robert Findley <rfindley@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Matloob <matloob@golang.org>
There is the expectation that if 'go telemetry off' is run with a clean
home directory that no counter files are written. But we were writing
counters in that case because the act of turning telemetry off was done
after the act of opening the counter files, so the counter files were
opened depending on what the previous mode was. Add a special check that
the command is not 'go telemetry off' before opening counter files.
Fixes#69269
Change-Id: I8fc37dfe24ec7f454676cc2fdd4b79a13a7aba9d
Reviewed-on: https://go-review.googlesource.com/c/go/+/611456
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Michael Matloob <matloob@golang.org>
On Android, faccessat2 syscall (which supports flags like AT_EACCESS) is
not allowed, so syscall.Faccessat tries to emulate AT_EACCESS check in
userspace using os.Stat, os.Geteuid etc.
Also, according to [1],
> Android doesn't have setuid programs, and never runs code with euid!=uid.
This means on Android the proper AT_EACCESS check is neither possible
nor really needed.
Let's skip the syscall.Faccessat userspace emulation of AT_EACCESS
check and return ENOSYS, so the callers can use a fallback.
This should speed up exec.LookPath on Android.
[1]: 508b2f6e5c/libc/bionic/faccessat.cpp (50)
Change-Id: If7b529fa314480b70e9ae9cdd8c7ce82cd55d233
Reviewed-on: https://go-review.googlesource.com/c/go/+/611298
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Eaccess, initially added by CL 414824 for linux only, was later
implemented for freebsd (CL 531155), netbsd (CL 531876), dragonfly
(CL 532675), openbsd (CL 538836), and darwin (CL 579976).
The only unix platforms which lack Eaccess are Solaris/Illumos and AIX.
For AIX, syscall.Faccessat is already available, the only missing piece
was AT_EACCESS constant. Let's take it from [1], which, judging by a few
other known AT_ constants, appears to be accurate.
For Solaris, wire the faccessat using the same logic as in the syscall
package.
Now, when we have faccessat for every unix, we can drop eaccess_other.go
and consolidate Eaccess implementations to use faccessat.
[1]: https://github.com/rust-lang/libc/blob/main/src/unix/aix/mod.rs
Change-Id: I7e1b90dedc5d8174235d3a79d5c662f3dcb909c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/611295
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@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: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Kirill Kolyshkin <kolyshkin@gmail.com>
Generally, the parser strips (i.e., does not record in the syntax tree)
unnecessary parentheses. Specifically, given a type parameter list of
the form
[P (C),]
it records it as
[P C]
and then no comma is required when printing. However it did only strip
one level of parentheses, and
[P ((C)),]
made it through, causing a panic when printing. Somewhat related,
the printer stripped parentheses around constraints as well.
This CL implements a more consistent behavior:
1) The parser strips all parentheses around constraints. For testing
purposes, a local flag (keep_parens) can be set to retain the
parentheses.
2) The printer code now correctly intruces a comma if parentheses
are present (e.g., when testing with keep_parens). This case does
not occur in normal operation.
3) The printer does not strip parentheses around constraints since
the parser does it already.
For #69206.
Change-Id: I974a800265625e8daf9477faa9ee4dd74dbd17ce
Reviewed-on: https://go-review.googlesource.com/c/go/+/610758
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
This change makes sure that we do not format comments
as doc comments inside of a declaration and makes the
go doc formatter idempotent:
Previously:
// test comment
//go:directive2
// test comment
func main() {
}
was formatted to:
// test comment
//go:directive2
// test comment
func main() {
}
after another formatting, it got formatted with doc rules into:
// test comment
// test comment
//
//go:directive2
func main() {
}
With this change it gets directly to the correct form (last one).
Change-Id: Id7d8f03e43474357cd714e0672e886652c3fce86
GitHub-Last-Rev: 9833b87536
GitHub-Pull-Request: golang/go#69134
Reviewed-on: https://go-review.googlesource.com/c/go/+/609077
Reviewed-by: Dmitri Shuralyov <dmitshur@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>
When testing with PWD set, it's possible for the stat of PWD to fail
with ENAMETOOLONG, and for syscall.Getwd to fail for the same reason.
If PWD contains symlinks, the fallback code won't know about them.
If Getwd returns the same result as PWD with resolved symlinks,
the test should not fail.
Change-Id: I39587ddb826d4e18339e185aad0cdd60167b1079
Reviewed-on: https://go-review.googlesource.com/c/go/+/610759
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>
Commit-Queue: Ian Lance Taylor <iant@google.com>
Reviewed-by: Tim King <taking@google.com>
Among other things, this should fix a regression in printf
whereby materialized aliases caused "any" and "interface{}"
in printf signatures not to be recognized as identical.
It also updates ureader.go used by vendored x/tools during
some tests, including cmd/internal/moddeps.TestAllDependencies.
This test uses golang.org/x/tools/cmd/bundle which uses x/reader.
Fixes#68796
Change-Id: I9f0711e66a5c4daaffe695c515aea3b8fb3d01e0
Reviewed-on: https://go-review.googlesource.com/c/go/+/610736
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Alan Donovan <adonovan@google.com>
Reviewed-by: Tim King <taking@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This implementation utilizes the same registers found in the reference
implementation, aiming to produce a minimal semantic diff between the
Avo-generated output and the original hand-written assembly.
To verify the Avo implementation, the reference and Avo-generated
assembly files are fed to `go tool asm`, capturing the debug output into
corresponding temp files. The debug output contains supplementary
metadata (line numbers, instruction offsets, and source file references)
that must be removed in order to obtain a semantic diff of the two
files. This is accomplished via a small utility script written in awk.
The reference assembly file does not specify a frame size for a number
of the defined assembly functions. Avo automatically infers the frame
size when generating the TEXT directive, leading to a diff on those
lines.
Commands used to verify Avo output:
GOROOT=$(go env GOROOT)
ASM_PATH="src/crypto/internal/nistec/p256_asm_amd64.s"
REFERENCE="54fe0fd43fcf8609666c16ae6d15ed92873b1564"
go tool asm -o /dev/null -I "$GOROOT"/src/runtime -debug \
<(git cat-file -p "$REFERENCE:$ASM_PATH") \
> /tmp/reference.s
go tool asm -o /dev/null -I "$GOROOT"/src/runtime -debug \
"$ASM_PATH" \
> /tmp/avo.s
normalize(){
awk '{
$1=$2=$3="";
print substr($0,4)
}'
}
diff <(normalize < /tmp/reference.s) <(normalize < /tmp/avo.s)
1c1
< TEXT <unlinkable>.p256OrdLittleToBig(SB), NOSPLIT, $0
---
> TEXT <unlinkable>.p256OrdLittleToBig(SB), NOSPLIT, $0-16
3c3
< TEXT <unlinkable>.p256OrdBigToLittle(SB), NOSPLIT, $0
---
> TEXT <unlinkable>.p256OrdBigToLittle(SB), NOSPLIT, $0-16
5c5
< TEXT <unlinkable>.p256LittleToBig(SB), NOSPLIT, $0
---
> TEXT <unlinkable>.p256LittleToBig(SB), NOSPLIT, $0-16
7c7
< TEXT <unlinkable>.p256BigToLittle(SB), NOSPLIT, $0
---
> TEXT <unlinkable>.p256BigToLittle(SB), NOSPLIT, $0-16
23c23
< TEXT <unlinkable>.p256MovCond(SB), NOSPLIT, $0
---
> TEXT <unlinkable>.p256MovCond(SB), NOSPLIT, $0-32
74c74
< TEXT <unlinkable>.p256NegCond(SB), NOSPLIT, $0
---
> TEXT <unlinkable>.p256NegCond(SB), NOSPLIT, $0-16
99c99
< TEXT <unlinkable>.p256Sqr(SB), NOSPLIT, $0
---
> TEXT <unlinkable>.p256Sqr(SB), NOSPLIT, $0-24
234c234
< TEXT <unlinkable>.p256Mul(SB), NOSPLIT, $0
---
> TEXT <unlinkable>.p256Mul(SB), NOSPLIT, $0-24
401c401
< TEXT <unlinkable>.p256FromMont(SB), NOSPLIT, $0
---
> TEXT <unlinkable>.p256FromMont(SB), NOSPLIT, $0-16
465c465
< TEXT <unlinkable>.p256Select(SB), NOSPLIT, $0
---
> TEXT <unlinkable>.p256Select(SB), NOSPLIT, $0-24
513c513
< TEXT <unlinkable>.p256SelectAffine(SB), NOSPLIT, $0
---
> TEXT <unlinkable>.p256SelectAffine(SB), NOSPLIT, $0-24
566c566
< TEXT <unlinkable>.p256OrdMul(SB), NOSPLIT, $0
---
> TEXT <unlinkable>.p256OrdMul(SB), NOSPLIT, $0-24
806c806
< TEXT <unlinkable>.p256OrdSqr(SB), NOSPLIT, $0
---
> TEXT <unlinkable>.p256OrdSqr(SB), NOSPLIT, $0-24
Change-Id: I610b097c573b9d9018f0e26bc2afde5edb3f954b
Reviewed-on: https://go-review.googlesource.com/c/go/+/599875
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
This implementation utilizes the same registers found in the reference
implementation, aiming to produce a minimal semantic diff between the
Avo-generated output and the original hand-written assembly.
To verify the Avo implementation, the reference and Avo-generated
assembly files are fed to `go tool asm`, capturing the debug output into
corresponding temp files. The debug output contains supplementary
metadata (line numbers, instruction offsets, and source file references)
that must be removed in order to obtain a semantic diff of the two
files. This is accomplished via a small utility script written in awk.
The reference assembly file does not specify a frame size for some of
the defined assembly functions. Avo automatically infers the frame size
when generating TEXT directives, leading to a diff on those lines.
Commands used to verify Avo output:
GOROOT=$(go env GOROOT)
ASM_PATH="src/crypto/aes/asm_amd64.s"
REFERENCE="54fe0fd43fcf8609666c16ae6d15ed92873b1564"
go tool asm -o /dev/null -I "$GOROOT"/src/runtime -debug \
<(git cat-file -p "$REFERENCE:$ASM_PATH") \
> /tmp/reference.s
go tool asm -o /dev/null -I "$GOROOT"/src/runtime -debug \
"$ASM_PATH" \
> /tmp/avo.s
normalize(){
awk '{
$1=$2=$3="";
print substr($0,4)
}'
}
diff <(normalize < /tmp/reference.s) <(normalize < /tmp/avo.s)
1c1
< TEXT <unlinkable>.encryptBlockAsm(SB), NOSPLIT, $0
---
> TEXT <unlinkable>.encryptBlockAsm(SB), NOSPLIT, $0-32
45c45
< TEXT <unlinkable>.decryptBlockAsm(SB), NOSPLIT, $0
---
> TEXT <unlinkable>.decryptBlockAsm(SB), NOSPLIT, $0-32
89c89
< TEXT <unlinkable>.expandKeyAsm(SB), NOSPLIT, $0
---
> TEXT <unlinkable>.expandKeyAsm(SB), NOSPLIT, $0-32
Change-Id: If647584df4137146d355f91ac0f6a8285d07c932
Reviewed-on: https://go-review.googlesource.com/c/go/+/600375
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>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
This implementation utilizes the same registers found in the reference
implementation, aiming to produce a minimal semantic diff between the
Avo-generated output and the original hand-written assembly.
To verify the Avo implementation, the reference and Avo-generated
assembly files are fed to `go tool asm`, capturing the debug output into
corresponding temp files. The debug output contains supplementary
metadata (line numbers, instruction offsets, and source file references)
that must be removed in order to obtain a semantic diff of the two
files. This is accomplished via a small utility script written in awk.
The reference assembly file does not specify a frame size for some of
the defined assembly functions. Avo automatically infers the frame size
when generating TEXT directives, leading to a diff on those lines. Some
metadata not included in the reference assembly has also been added,
which leads to a diff in the lines where that parameter symbol is
referenced.
Commands used to verify Avo output:
GOROOT=$(go env GOROOT)
ASM_PATH="src/crypto/aes/gcm_amd64.s"
REFERENCE="54fe0fd43fcf8609666c16ae6d15ed92873b1564"
go tool asm -o /dev/null -I "$GOROOT"/src/runtime -debug \
<(git cat-file -p "$REFERENCE:$ASM_PATH") \
> /tmp/reference.s
go tool asm -o /dev/null -I "$GOROOT"/src/runtime -debug \
"$ASM_PATH" \
> /tmp/avo.s
normalize(){
awk '{
$1=$2=$3="";
print substr($0,4)
}'
}
diff <(normalize < /tmp/reference.s) <(normalize < /tmp/avo.s)
1c1
< TEXT <unlinkable>.gcmAesFinish(SB), NOSPLIT, $0
---
> TEXT <unlinkable>.gcmAesFinish(SB), NOSPLIT, $0-40
44c44
< TEXT <unlinkable>.gcmAesInit(SB), NOSPLIT, $0
---
> TEXT <unlinkable>.gcmAesInit(SB), NOSPLIT, $0-32
131c131
< TEXT <unlinkable>.gcmAesData(SB), NOSPLIT, $0
---
> TEXT <unlinkable>.gcmAesData(SB), NOSPLIT, $0-40
325c325
< MOVQ dst+8(FP), DX
---
> MOVQ dst_base+8(FP), DX
1207c1207
< MOVQ dst+8(FP), SI
---
> MOVQ dst_base+8(FP), SI
Change-Id: Iad8f8c6ea5d50ac093c8535adc9d23fbf2612fc2
Reviewed-on: https://go-review.googlesource.com/c/go/+/601462
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>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
This implementation utilizes the same registers found in the reference
implementation, aiming to produce a minimal semantic diff between the
Avo-generated output and the original hand-written assembly.
To verify the Avo implementation, the reference and Avo-generated
assembly files are fed to `go tool asm`, capturing the debug output into
corresponding temp files. The debug output contains supplementary
metadata (line numbers, instruction offsets, and source file references)
that must be removed in order to obtain a semantic diff of the two
files. This is accomplished via a small utility script written in awk.
Metadata not found in the reference assembly file has been added to one
parameter symbol, resulting in a single line diff.
Commands used to verify Avo output:
GOROOT=$(go env GOROOT)
ASM_PATH="src/crypto/md5/md5block_amd64.s"
REFERENCE="54fe0fd43fcf8609666c16ae6d15ed92873b1564"
go tool asm -o /dev/null -I "$GOROOT"/src/runtime -debug \
<(git cat-file -p "$REFERENCE:$ASM_PATH") \
> /tmp/reference.s
go tool asm -o /dev/null -I "$GOROOT"/src/runtime -debug \
"$ASM_PATH" \
> /tmp/avo.s
normalize(){
awk '{
$1=$2=$3="";
print substr($0,4)
}'
}
diff <(normalize < /tmp/reference.s) <(normalize < /tmp/avo.s)
3c3
< MOVQ p+8(FP), SI
---
> MOVQ p_base+8(FP), SI
Change-Id: Ifecc84fd0f5a39a88350e6eaffb45ed3fdacf2fb
Reviewed-on: https://go-review.googlesource.com/c/go/+/599935
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>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
This implementation utilizes the same registers found in the reference
implementation, aiming to produce a minimal semantic diff between the
Avo-generated output and the original hand-written assembly.
To verify the Avo implementation, the reference and Avo-generated
assembly files are fed to `go tool asm`, capturing the debug output into
corresponding temp files. The debug output contains supplementary
metadata (line numbers, instruction offsets, and source file references)
that must be removed in order to obtain a semantic diff of the two
files. This is accomplished via a small utility script written in awk.
Commands used to verify Avo output:
GOROOT=$(go env GOROOT)
ASM_PATH="src/crypto/sha512/sha512block_amd64.s"
REFERENCE="54fe0fd43fcf8609666c16ae6d15ed92873b1564"
go tool asm -o /dev/null -I "$GOROOT"/src/runtime -debug \
<(git cat-file -p "$REFERENCE:$ASM_PATH") \
> /tmp/reference.s
go tool asm -o /dev/null -I "$GOROOT"/src/runtime -debug \
"$ASM_PATH" \
> /tmp/avo.s
normalize(){
awk '{
$1=$2=$3="";
print substr($0,4)
}'
}
diff <(normalize < /tmp/reference.s) <(normalize < /tmp/avo.s)
Change-Id: I172f0cb97252635c657efe82d1b547e6b6f40ebb
Reviewed-on: https://go-review.googlesource.com/c/go/+/598958
Reviewed-by: Roland Shoemaker <roland@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>
This implementation utilizes the same registers found in the reference
implementation, aiming to produce a minimal semantic diff between the
Avo-generated output and the original hand-written assembly.
To verify the Avo implementation, the reference and Avo-generated
assembly files are fed to `go tool asm`, capturing the debug output into
corresponding temp files. The debug output contains supplementary
metadata (line numbers, instruction offsets, and source file references)
that must be removed in order to obtain a semantic diff of the two
files. This is accomplished via a small utility script written in awk.
Commands used to verify Avo output:
GOROOT=$(go env GOROOT)
ASM_PATH="src/crypto/sha1/sha1block_amd64.s"
REFERENCE="54fe0fd43fcf8609666c16ae6d15ed92873b1564"
go tool asm -o /dev/null -I "$GOROOT"/src/runtime -debug \
<(git cat-file -p "$REFERENCE:$ASM_PATH") \
> /tmp/reference.s
go tool asm -o /dev/null -I "$GOROOT"/src/runtime -debug \
"$ASM_PATH" \
> /tmp/avo.s
normalize(){
awk '{
$1=$2=$3="";
print substr($0,4)
}'
}
diff <(normalize < /tmp/reference.s) <(normalize < /tmp/avo.s)
1273c1273
< MOVQ $K_XMM_AR<>(SB), R8
---
> LEAQ K_XMM_AR<>(SB), R8
Change-Id: I39168fadb01baa9a96bc2b432fc94b492d036ce4
Reviewed-on: https://go-review.googlesource.com/c/go/+/598795
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
This implementation utilizes the same registers found in the reference
implementation, aiming to produce a minimal semantic diff between the
Avo-generated output and the original hand-written assembly.
To verify the Avo implementation, the reference and Avo-generated
assembly files are fed to `go tool asm`, capturing the debug output into
corresponding temp files. The debug output contains supplementary
metadata (line numbers, instruction offsets, and source file references)
that must be removed in order to obtain a semantic diff of the two
files. This is accomplished via a small utility script written in awk.
Commands used to verify Avo output:
GOROOT=$(go env GOROOT)
ASM_PATH="src/crypto/sha256/sha256block_amd64.s"
REFERENCE="54fe0fd43fcf8609666c16ae6d15ed92873b1564"
go tool asm -o /dev/null -I "$GOROOT"/src/runtime -debug \
<(git cat-file -p "$REFERENCE:$ASM_PATH") \
> /tmp/reference.s
go tool asm -o /dev/null -I $GOROOT/src/runtime -debug \
"$ASM_PATH" \
> /tmp/avo.s
normalize(){
awk '{
$1=$2=$3="";
print substr($0,4)
}'
}
diff <(normalize < /tmp/reference.s) <(normalize < /tmp/avo.s)
3513c3513
< MOVQ $K256<>(SB), BP
---
> LEAQ K256<>(SB), BP
4572c4572
< MOVQ $K256<>(SB), BP
---
> LEAQ K256<>(SB), BP
Change-Id: I637c01d746ca775b8a09f874f7925ffc3b4965ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/595559
Reviewed-by: Russell Webb <russell.webb@protonmail.com>
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: Dmitri Shuralyov <dmitshur@google.com>
Currently the unique package tries to clone strings that get stored in
its internal map to avoid retaining large strings.
However, this falls over entirely due to the fact that the original
string is *still* stored in the map as a key. Whoops. Fix this by
storing the cloned value in the map instead.
This change also adds a test which fails without this change.
Change-Id: I1a6bb68ed79b869ea12ab6be061a5ae4b4377ddb
Reviewed-on: https://go-review.googlesource.com/c/go/+/610738
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>
There's a bug in the weak-to-strong conversion in that creating the
*only* strong pointer to some weakly-held object during the mark phase
may result in that object not being properly marked.
The exact mechanism for this is that the new strong pointer will always
point to a white object (because it was only weakly referenced up until
this point) and it can then be stored in a blackened stack, hiding it
from the garbage collector.
This "hide a white pointer in the stack" problem is pretty much exactly
what the Yuasa part of the hybrid write barrier is trying to catch, so
we need to do the same thing the write barrier would do: shade the
pointer.
Added a test and confirmed that it fails with high probability if the
pointer shading is missing.
Fixes#69210.
Change-Id: Iaae64ae95ea7e975c2f2c3d4d1960e74e1bd1c3f
Reviewed-on: https://go-review.googlesource.com/c/go/+/610396
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>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
In rare situations, like during same-sized grows, the source map for
maps.Clone may be overloaded (has more than 6.5 entries per
bucket). This causes the runtime to allocate a larger bucket array for
the destination map than for the source map. The maps.Clone code
walks off the end of the source array if it is smaller than the
destination array.
This is a pretty simple fix, ensuring that the destination bucket
array is never longer than the source bucket array. Maybe a better fix
is to make the Clone code handle shorter source arrays correctly, but
this fix is deliberately simple to reduce the risk of backporting this
fix.
Fixes#69110
Change-Id: I824c93d1db690999f25a3c43b2816fc28ace7509
Reviewed-on: https://go-review.googlesource.com/c/go/+/609757
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
We can see ENOMEM on FreeBSD.
Also don't fail the test if we get an EPERM error when reading
all the way up the tree; on Android we get that, perhaps because
the root directory is unreadable.
Also accept an EFAULT from a stat of a long name on Dragonfly,
which we see on the builders.
Change-Id: If37e6bf414b7b568c9a06130f71e79af153bfb75
Reviewed-on: https://go-review.googlesource.com/c/go/+/610415
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Commit-Queue: Ian Lance Taylor <iant@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Change SimpleFold to search the CaseRanges table only once when no
folding is specified for the rune (previously up to two searches could
be performed). This improves performance by 2x for runes that have no
folds or are already upper case. As a side effect this improves the
performance of To by roughly ~15%
goos: darwin
goarch: arm64
pkg: unicode
cpu: Apple M1 Max
│ base.10.txt │ new.10.txt │
│ sec/op │ sec/op vs base │
ToUpper-10 11.860n ± 1% 9.731n ± 1% -17.95% (p=0.000 n=10)
ToLower-10 12.31n ± 1% 10.34n ± 1% -16.00% (p=0.000 n=10)
SimpleFold/Upper-10 19.16n ± 0% 15.98n ± 1% -16.64% (p=0.000 n=10)
SimpleFold/Lower-10 32.41n ± 1% 17.09n ± 1% -47.27% (p=0.000 n=10)
SimpleFold/Fold-10 8.884n ± 4% 8.856n ± 8% ~ (p=0.700 n=10)
SimpleFold/NoFold-10 30.87n ± 0% 15.49n ± 3% -49.84% (p=0.000 n=10)
geomean 17.09n 12.47n -26.99%
Change-Id: I6e5c7554106842955aadeef7b266c4c7944d3a97
Reviewed-on: https://go-review.googlesource.com/c/go/+/454958
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>
Auto-Submit: Ian Lance Taylor <iant@google.com>
addLocalFacts loop already ft.update which sets up limits correctly, but doing this in flowLimit help us since other values might depend on this limit.
Updates #68857
We could improve this further:
- remove mod alltogheter when we can prove a < b.
- we could do more adhoc computation in flowLimit to set umax and umin tighter
Change-Id: I5184913577b6a51a07cb53a6e6b73552a982de0b
Reviewed-on: https://go-review.googlesource.com/c/go/+/605156
Reviewed-by: Keith Randall <khr@golang.org>
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>
As of CL 257637, all currently supported platforms have syscall.Getwd
implemented, so the code which deduces wd by traversing up to root
directory is never used and thus can be removed.
Or, as it was suggested by Ian Lance Taylor in CL 607436 review
comments, it can be reused when syscall.Getwd returns ENAMETOOLONG
(which usually happens than the current working dir is longer than
syscall.PathMax).
Let's do that. The only caveat is, such a long path returned from Getwd
couldn't be used for any file-related operations (they will probably
fail with ENAMETOOLONG).
While at it:
- make the stat(".") code conditional, slightly improving the
performance on Unix when $PWD is not set;
- reuse variables dir and err;
- use openDirNolog instead of openFileNolog to obtain a dirfd;
- ensure the errors returned are wrapped;
- document the new functionality;
- add test cases (which fail before this change).
Change-Id: I60f7a70e6ebb1751699416f587688a1a97305fd7
Reviewed-on: https://go-review.googlesource.com/c/go/+/608635
Reviewed-by: Ian Lance Taylor <iant@google.com>
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>
```
export CC="zig cc -target x86_64-linux"
hyperfine '../pkg/tool/darwin_arm64/cgo -objdir /tmp net/cgo_linux.go net/cgo_resnew.go net/cgo_socknew.go net/cgo_unix_cgo.go net/cgo_unix_cgo_res.go'
```
**Before**
```
Time (mean ± sig): 1.293 s ± 0.017 s [User: 0.472 s, System: 0.451 s]
Range (min ... max): 1.263 s ... 1.316 s 10 runs
```
**After**
```
Time (mean ±sig): 986.5 ms ± 22.6 ms [User: 487.0 ms, System: 519.5 ms]
Range (min ... max): 950.7 ms ... 1022.2 ms 10 runs
```
The version after changes is 25% faster for 5 input files (std "net" package).
I also tried to make CC artifictially slower (wrapper with sleep 0.2) and it showes same 25% performance increase.
Change-Id: I7a26fdc8d8a23b0df9bc71d30b96e82e2ddb943b
Reviewed-on: https://go-review.googlesource.com/c/go/+/581336
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
A previous change [1] was introduced to enable MPTCP by default
for both the clients and servers, based on the discussions [2] in
golang#56539, where MPTCP would be an opt-in for a release or
two, and then would become an opt-out.
This change was not accepted at the time because the support for
a few socket options was missing [3]. Now that this support has been
added [4] and backported to stable versions not to block MPTCP
deployment with Go, it sounds like a good time to reconsider the use
of MPTCP by default.
Instead of enabling MPTCP on both ends by default, as a first step,
it seems safer to change the default behaviour only for the server
side (Listeners). On the server side, the impact is minimal: when
clients don't request to use MPTCP, server applications will create
"plain" TCP sockets within the kernel when connections are accepted,
making the performance impact minimal. This should also ease
experiments where MPTCP is enabled by default on the client side
(Dialer).
The changes in this patch consist of a duplication of the mptcpStatus
enumeration to have both a mptcpStatusDial and a mptcpStatusListen,
where MPTCP is enabled by default in mptcpStatusListen, but disabled
by default in mptcpStatusDial. It is still possible to turn MPTCP support
on and off by using GODEBUG=multipathtcp=1.
[1] https://go-review.googlesource.com/c/go/+/563575
[2] https://go.dev/issue/56539#issuecomment-1309294637
[3] https://github.com/multipath-tcp/mptcp_net-next/issues/383
[4] bd11dc4fb9
[5] https://www.mptcp.dev/faq.html#why--when-should-mptcp-be-enabled-by-default
Updates #56539
Change-Id: I1ca0d6aaf74d3bda5468af135e29cdb405d3fd00
GitHub-Last-Rev: 5f9f29bfc1
GitHub-Pull-Request: golang/go#69016
Reviewed-on: https://go-review.googlesource.com/c/go/+/607715
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Matthieu Baerts <matttbe@kernel.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
On Linux one process can call prlimit to change the resource limit
of another process. With this change we treat that as though the
current process called prlimit (or setrlimit) to set its own limit.
The cost is one additional getrlimit system call per fork/exec,
for cases in which the rlimit Cur and Max values differ at startup.
This revealed a bug: the setrlimit (not Setrlimit) function should not
change the cached rlimit. That means that it must call prlimit1, not prlimit.
Fixes#66797
Change-Id: I46bfd06e09ab7273fe8dd9b5b744dffdf31d828b
Reviewed-on: https://go-review.googlesource.com/c/go/+/607516
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Aleksa Sarai <cyphar@cyphar.com>
Reviewed-by: Kirill Kolyshkin <kolyshkin@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
If the aligned offset isn't sufficient for the field offset,
we were padding based on the aligned offset. We need to pad
based on the original offset instead.
Also set the Go alignment correctly for int128. We were defaulting
to the maximum alignment, but since we translate int128 into an
array of uint8 the correct Go alignment is 1.
Fixes#69086
Change-Id: I23ce583335c81beac2ac51f7f9336ac97ccebf09
Reviewed-on: https://go-review.googlesource.com/c/go/+/608815
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Change the rules for how //go:build "file versions" are applied: instead
of considering whether a file version is an upgrade or downgrade from
the -lang version, always use max(fileVersion, go1.21). This prevents
file versions from downgrading the version below go1.21. Before Go 1.21
the //go:build version did not have the meaning of setting the file's
langage version.
This fixes an issue that was appearing in GOPATH builds: Go 1.23.0
started providing -lang versions to the compiler in GOPATH mode (among
other places) which it wasn't doing before, and it set -lang to the
toolchain version (1.23). Because the -lang version was greater than
go1.21, language version used to compile the file would be set to the
//go:build file version. //go:build file versions below 1.21 could cause
files that could previously build to stop building.
For example, take a Go file with a //go:build line specifying go1.10.
If that file used a 1.18 feature, that use would compile fine with a Go
1.22 toolchain. But it would produce an error when compiling with the
1.23.0 toolchain because it set the language version to 1.10 and
disallowed the 1.18 feature. This breaks backwards compatibility: when
the build tag was added, it did not have the meaning of restricting the
language version.
For #68658
Change-Id: I6cedda81a55bcccffaa3501eef9e2be6541b6ece
Reviewed-on: https://go-review.googlesource.com/c/go/+/607955
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Griesemer <gri@google.com>
As of CL 580255, the runtime tracks the frame pointer (or base pointer,
bp) when entering syscalls, so that we can use fpTracebackPCs on
goroutines that are sitting in syscalls. That CL mostly got things
right, but missed one very subtle detail.
When calling from Go->C->Go, the goroutine stack performing the calls
when returning to Go is free to move around in memory due to growth,
shrinking, etc. But upon returning back to C, it needs to restore
gp.syscall*, including gp.syscallsp and gp.syscallbp. The way syscallsp
currently gets updated is automagically: it's stored as an
unsafe.Pointer on the stack so that it shows up in a stack map. If the
stack ever moves, it'll get updated correctly. But gp.syscallbp isn't
saved to the stack as an unsafe.Pointer, but rather as a uintptr, so it
never gets updated! As a result, in rare circumstances, fpTracebackPCs
can correctly try to use gp.syscallbp as the starting point for the
traceback, but the value is stale.
This change fixes the problem by just storing gp.syscallbp to the stack
on cgocallback as an unsafe.Pointer, like gp.syscallsp. It also adds a
comment documenting this subtlety; the lack of explanation for the
unsafe.Pointer type on syscallsp meant this detail was missed -- let's
not miss it again in the future.
Now, we have a fix, what about a test? Unfortunately, testing this is
going to be incredibly annoying because the circumstances under which
gp.syscallbp are actually used for traceback are non-deterministic and
hard to arrange, especially from within testprogcgo where we don't have
export_test.go and can't reach into the runtime.
So, instead, add a gp.syscallbp check to reentersyscall and
entersyscallblock that mirrors the gp.syscallbp consistency check. This
probably causes some miniscule slowdown to the syscall path, but it'll
catch the issue without having to actually perform a traceback.
Fixes#69085.
Change-Id: Iaf771758f1666024b854f5fbe2b2c63cbe35b201
Reviewed-on: https://go-review.googlesource.com/c/go/+/608775
Reviewed-by: Nick Ripley <nick.ripley@datadoghq.com>
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>
An invalid executable may claim to have a data section bigger than the
executable, causing readData in searchMagic to hit EOF. Since readData
suppresses all EOF errors, searchData would keep attempting to search
through a potentially huge "section" despite readData continuously
failing.
Fix by suppressing EOF only on partial read. If nothing is read, allow
EOF. Note that most of the admittedly tedious EOF handling in this
package is around ensuring we return errNotGoExe in most cases.
This was discovered by the new fuzz test. This fuzz test was inspired
by #69066, though it has not found that specific bug.
Change-Id: Icf413e996cecc583c084c9e44249b9294c3d8f10
Reviewed-on: https://go-review.googlesource.com/c/go/+/608637
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The $HOME/sdk/go1.17 and $HOME/go1.17 paths were initially added as
places to look for a bootstrap toolchain to make.{bash,bat,rc} scripts
and in cmd/dist (CL 370274). Those two go1.17 directories have since
been updated in the make scripts to go1.20.6 (CL 512275) and later on
to go1.22.6 (CL 606156), but the same list in cmd/dist was missed.
Fix the inconsistency now. But maybe cmd/dist doesn't need to maintain
this logic, if it's required to be invoked via one of the make scripts,
since they're responsible for setting GOROOT_BOOTSTRAP?
For #64751.
Change-Id: I0988005c559014791363138f2f722cc1f9a78bcf
Reviewed-on: https://go-review.googlesource.com/c/go/+/607821
Reviewed-by: Ian Lance Taylor <iant@google.com>
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>
If the length reported for the object file is more than the amount of
data we actually read, then the count can tell us that there is
sufficient remaining data but the slice operation can fail.
No test case because the problem can only happen for invalid data.
Let the fuzzer find cases like this.
Fixes#69066
Change-Id: I8d12ca8ade3330517ade45c7578b477772b7efd2
Reviewed-on: https://go-review.googlesource.com/c/go/+/608517
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Commit-Queue: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Create an intrinsicBuilders type that has functions for adding and
looking up intrinsics. This makes the implementation more self contained,
readable and testable. Additionally, pass an *intrinsicBuildConfig to
initIntrinsics to improve testability without needing to modify package
level variables.
Change-Id: I0ee0a19c192dd6da9f1c5f1c29b98a3ad8161fe2
Reviewed-on: https://go-review.googlesource.com/c/go/+/605478
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Joel Sing <joel@sing.id.au>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
filepath.Rel can sometimes return the a relative path that doesn't work.
If the basepath contains a symlink as a path component, and the targpath
does not exist with the directory pointed to by the innermost symlink,
the relative path can "cross" the symlink. The issue is that for the
return value for filepath.Rel to be correct, the ".." components of the
relative path would need to be collapsed before the symlinks are
expanded, but it was verified by doing local testing that the opposite
is true.
go work use (and cmd/go/internal/modload.ReadModFile) both try to
shorten absolute path arguments to relative paths from the working
directory (for better error messages, for instance). Avoid doing so when
the relative path could be wrong using a more conservative rule than the
above: if expanding the symlinks in the current directory produces a
different result, and the relative path we'd return starts with ".." and
then the path separator.
Fixes#68383
Change-Id: I0a6202be672484d4000fc753c69f2165615f3f72
Reviewed-on: https://go-review.googlesource.com/c/go/+/603136
TryBot-Bypass: Michael Matloob <matloob@golang.org>
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The current implementation has a panic when the database is closed
concurrently with a new connection attempt.
connRequestSet.CloseAndRemoveAll sets connRequestSet.s to a nil slice.
If this happens between calls to connRequestSet.Add and
connRequestSet.Delete, there is a panic when trying to write to the nil
slice. This is sequence is likely to occur in DB.conn, where the mutex
is released between calls to db.connRequests.Add and
db.connRequests.Delete
This change updates connRequestSet.CloseAndRemoveAll to set the curIdx
to -1 for all pending requests before setting its internal slice to nil.
CloseAndRemoveAll already iterates the full slice to close all the request
channels. It seems appropriate to set curIdx to -1 before deleting the
slice for 3 reasons:
1. connRequestSet.deleteIndex also sets curIdx to -1
2. curIdx will not be relevant to anything after the slice is set to nil
3. connRequestSet.Delete already checks for negative indices
Fixes#68949
Change-Id: I6b7ebc5a71b67322908271d13865fa12f2469b87
GitHub-Last-Rev: 7d2669155b
GitHub-Pull-Request: golang/go#68953
Reviewed-on: https://go-review.googlesource.com/c/go/+/607238
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Commit-Queue: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
CL 574695 added caching the os.Chdir argument for Windows, and used the
cached value to assess the length of the current working directory in
addExtendedPrefix (used by fixLongPath).
It did not take into account that Chdir can accept relative paths, and
thus the pathLength calculation in addExtendedPrefix can be wrong.
Let's only cache the os.Chdir argument if it's absolute, and clean the
cache otherwise, thus improving the correctness of fixLongPath.
For #41734
For #21782
For #36375
Change-Id: Ie24a5ed763a7aacc310666d2e4cbb8e298768670
Reviewed-on: https://go-review.googlesource.com/c/go/+/607437
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The commands to build the bootstrap toolchains and go commands are run
from modules created by two bootstrap go.mod files: one is used when
building toolchain1 and go_bootstrap, and the other is used for
toolchain2 and toolchain3, and the final build. Currently the first has
a go directive specifying go 1.20, and the second one does not have a go
directive at all. This affects the default GODEBUG setting when building
the final toolchain: the default GODEBUG value is based on the go
version of the go.mod file, and when the go.mod file does not have a
version it defaults to go1.16. We should set the go directive on the
bootstrap used for the second half of the builds to use the current go
verison from the std's go.mod file (which is the same as the version on
cmd's go.mod file).
The go.mod file used for the initial bootstrap should have a go
directive with the minimum version of the toolchain required for
bootstrapping. That version is the current version - 2 rounded down to
an even number.
For #64751Fixes#68797
Change-Id: Ibdddf4bc36dc963291979d603c4f3fc55264f65b
Reviewed-on: https://go-review.googlesource.com/c/go/+/604799
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 a roll-forward of CL 597255, which had to be rolled back
because it broke the windows-arm64 builder, whose current user display
name is unavailable. This new CL fixes the issue by reintroducing the
historical behavior of falling back to the user name instead of
returning an error].
user.Current is slow on Windows sessions connected to an Active
Directory domain. This is because it uses Windows APIs that do RPC
calls to the domain controller, such as TranslateAccountW and
NetUserGetInfo.
This change speeds up user.Current by using the GetUserNameEx API
instead, which is already optimized for retrieving the current user
name in different formats.
These are the improvements I see with the new implementation:
goos: windows
goarch: amd64
pkg: os/user
cpu: Intel(R) Core(TM) i7-10850H CPU @ 2.70GHz
│ old.txt │ new.txt │
│ sec/op │ sec/op vs base │
Current-12 501.8µ ± 7% 118.6µ ± 11% -76.36% (p=0.000 n=10)
│ old.txt │ new.txt │
│ B/op │ B/op vs base │
Current-12 888.0 ± 0% 832.0 ± 0% -6.31% (p=0.000 n=10)
│ old.txt │ new.txt │
│ allocs/op │ allocs/op vs base │
Current-12 15.00 ± 0% 11.00 ± 0% -26.67% (p=0.000 n=10)
Updates #5298Fixes#21867Fixes#68312
Cq-Include-Trybots: luci.golang.try:gotip-windows-amd64-longtest,gotip-windows-arm64
Change-Id: Ib7f77086d389cccb9d91cb77ea688d438a0ee5fd
Reviewed-on: https://go-review.googlesource.com/c/go/+/605135
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Mauri de Souza Meneguzzo <mauri870@gmail.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently the first thing Make does it get the abi.Type of its argument,
and uses abi.TypeOf to do it. However, this has a problem for interface
types, since the type of the value stored in the interface value will
bleed through. This is a classic reflection mistake.
Fix this by implementing and using a generic TypeFor which matches
reflect.TypeFor. This gets the type of the type parameter, which is far
less ambiguous and error-prone.
Fixes#68990.
Change-Id: Idd8d9a1095ef017e9cd7c7779314f7d4034f01a7
Reviewed-on: https://go-review.googlesource.com/c/go/+/607355
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Adds a new Version type to pkgbits to represent the version of the
bitstream. Versions let readers and writers know when different data is
expected to be present or not in the bitstream. These different pieces
of data are called Fields, as an analogy with fields of a struct.
Fields can be added, removed or changed in a Version. Extends Encoder
and Decoder to report which version they are.
Updates #68778
Change-Id: Iaffa1828544fb4cbc47a905de853449bc8e5b91f
Reviewed-on: https://go-review.googlesource.com/c/go/+/605655
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Adds a -gomodversion flag to testdir. This sets the go version
in generated go.mod files. This is just runindir tests at the moment.
This is a building block so that tests can be written for exported
type parameterized aliases (like reproducing #68526).
This also adds a test that uses this feature. A type parameterized
alias is used so aliastypeparams and gotypesalias must be enabled.
gotypesalias is enabled by the go module version. The alias is not
exported and will not appear in exportdata. The test shows the
package containing the alias can be imported. This encapsulates
the level of support of type parameterized aliases in 1.23.
Updates #68526
Updates #68778
Change-Id: I8e20df6baa178e1d427d0fff627a16714d9c3b18
Reviewed-on: https://go-review.googlesource.com/c/go/+/604102
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Austin Clements <austin@google.com>
The AIX ABI requires allocating parameter save space when calling
a function, even if the arguments are passed via registers.
gcc sometimes uses this space. In the case of the cgo c-archive
tests, it clobbered the storage space of argc/argv which prevented
the test program from running the expected test.
Fixes#68957
Change-Id: I8a267b463b1abb2b37ac85231f6c328f406b7515
Reviewed-on: https://go-review.googlesource.com/c/go/+/606895
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Mutex contention events with delay of 0 need more than CL 604355 added:
When deciding which event to store in the M's single available slot,
always choose to drop the zero-delay event. Store an explicit flag for
whether we have an event to store, rather than relying on a non-zero
delay.
And, fix a test of sync.Mutex contention that expects those events to
have non-zero delay. The reporting of non-runtime contention like this
has long allowed zero-delay events, which we see when cputicks has low
resolution.
Fixes#68892Fixes#68906
Change-Id: Id412141e4eb09724f3ce195899a20d59c92d7b78
Reviewed-on: https://go-review.googlesource.com/c/go/+/606115
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Rhys Hiltner <rhys.hiltner@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Some tests need to use os.Chdir, but the use is complicated because
- they must change back to the old working directory;
- they must not use t.Parallel.
Add Chdir that covers these cases, and sets PWD environment variable
to the new directory for the duration of the test for Unix platforms.
Unify the panic message when t.Parallel is used together with t.Setenv
or t.Chdir.
Add some tests.
For #62516.
Change-Id: Ib050d173b26eb28a27dba5a206b2d0d877d761c1
Reviewed-on: https://go-review.googlesource.com/c/go/+/529895
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
In Go 1.22 we added code to the go/build package to ignore #cgo noescape
and nocallback directives. That permits us to enable these directives in Go 1.24.
Also, this fixed a Bug in CL 497837:
After retiring _Cgo_use for parameters, the compiler will treat the
parameters, start from the second, as non-alive. Then, they will be marked
as scalar in stackmap, which means the pointer won't be copied correctly
in copystack.
Fixes#56378.
Fixes#63739.
Change-Id: I46e773240f8a467c3c4ba201dc5b4ee473cf6e3e
GitHub-Last-Rev: 42fcc506d6
GitHub-Pull-Request: golang/go#66879
Reviewed-on: https://go-review.googlesource.com/c/go/+/579955
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
For the moment, Go calls sendfile(2) to transfer at most 4MB at a time
while sendfile(2) actually allows a larger amount of data on one call.
To reduce system calls of sendfile(2) during data copying, we should
specify the number of bytes to copy as large as possible.
This optimization is especially advantageous for bulky file-to-file copies,
it would lead to a performance boost, the magnitude of this performance
increase may not be very exciting, but it can also cut down the CPU overhead
by decreasing the number of system calls.
This is also how we've done in sendfile_windows.go with TransmitFile.
goos: linux
goarch: amd64
pkg: os
cpu: DO-Premium-AMD
│ old │ new │
│ sec/op │ sec/op vs base │
SendFile-8 1.135 ± 4% 1.052 ± 3% -7.24% (p=0.000 n=10)
│ old │ new │
│ B/s │ B/s vs base │
SendFile-8 902.5Mi ± 4% 973.0Mi ± 3% +7.81% (p=0.000 n=10)
│ old │ new │
│ B/op │ B/op vs base │
SendFile-8 272.0 ± 0% 272.0 ± 0% ~ (p=1.000 n=10) ¹
¹ all samples are equal
│ old │ new │
│ allocs/op │ allocs/op vs base │
SendFile-8 20.00 ± 0% 20.00 ± 0% ~ (p=1.000 n=10) ¹
¹ all samples are equal
Change-Id: Ib4d4c6bc693e23db24697363b29226f0c9776bb0
Reviewed-on: https://go-review.googlesource.com/c/go/+/605235
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Jorropo <jorropo.pgm@gmail.com>
Run-TryBot: Andy Pan <panjf2000@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
The block and mutex profiles have slightly different behaviors when a
sampled event has a negative (or zero) duration. The block profile
enforces a minimum duration for each event of "1" in the cputicks unit.
It does so by clamping the duration to 1 if it was originally reported
as being smaller. The mutex profile for app-level contention enforces a
minimum duration of 0 in a similar way: by reporting any negative values
as 0 instead.
The mutex profile for runtime-internal contention had a different
behavior: to enforce a minimum event duration of "1" by dropping any
non-conforming samples.
Stop dropping samples, and use the same minimum (0) that's in place for
the other mutex profile events.
Fixes#64253Fixes#68453Fixes#68781
Change-Id: I4c5d23a2675501226eef5b9bc1ada2efc1a55b9e
Reviewed-on: https://go-review.googlesource.com/c/go/+/604355
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Mauri de Souza Meneguzzo <mauri870@gmail.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Auto-Submit: Rhys Hiltner <rhys.hiltner@gmail.com>
After newobject, we don't need to write zeroes to initialize the
object. It has already been zeroed by the allocator.
This is already handled in most cases, but because we run builtin
decomposition after the opt pass, we don't handle cases where the zero
of a compound builtin is being written. Improve the zero detector to
handle those cases.
Fixes#68845
Change-Id: If3dde2e304a05e5a6a6723565191d5444b334bcc
Reviewed-on: https://go-review.googlesource.com/c/go/+/605255
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
This CL adds support of "library", i.e. c-shared, build mode on
wasip1. When -buildmode=c-shared is set, it builds a Wasm module
that is intended to be used as a library, instead of an executable.
It does not have the _start function. Instead, it has an
_initialize function, which initializes the runtime, but not call
the main function.
This is similar to the c-shared build mode on other platforms. One
difference is that unlike cgo callbacks, where Ms are created on-
demand, on Wasm we have only one M, so we just keep the M (and the
G) for callbacks.
For #65199.
Change-Id: Ieb21da96b25c1a9f3989d945cddc964c26f9085b
Reviewed-on: https://go-review.googlesource.com/c/go/+/604316
Reviewed-by: Achille Roussel <achille.roussel@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Changes the type inference error message so that the position is
proceeded by a space. cmd/go rewrites the output of gc to replace
absolute paths at the beginning of lines and those proceeded by a
space or a tab to relative paths.
Updates testdir to do the same post processing on the output
of tests as cmd/go.
Fixes#68292
Change-Id: Ie109b51143e68f6e7ab4cd19064110db0e609a7e
Reviewed-on: https://go-review.googlesource.com/c/go/+/603097
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>
Get rid of TODO in prove pass.
We currently avoid marking shifts of constants as bounded, where
bounded means we don't have to worry about <0 or >=bitwidth shifts.
We do this because it causes different rule applications during lowering
which cause some codegen tests to fail.
Add some new rules which ensure that we get the right final instruction
sequence regardless of the ordering. Then we can remove this special case.
Change-Id: I4e962d4f09992b42ab47e123de5ded3b8b8fb205
Reviewed-on: https://go-review.googlesource.com/c/go/+/602935
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>
The spec says that an embedded field must be specified
as a type name (or a pointer to a type name). This is
explicit in the prose and the FieldDecl syntax.
However, the prose on promoted methods required a named
type (originally the term used for a "defined type").
Before the introduction of alias types, type names could
only refer to named/defined types, so the prose was ok.
With the introduction of alias types in Go 1.9, we
distinguished between defined types (i.e., types given
a name through a type declaration) and type aliases
(types given an alternative name), and retired the notion
of a named type since any type with a name (alias type
and defined type) could be considered a "named type".
To make things worse, with Go 1.18 we re-introduced the
notion of a named type which now includes predeclared
types, defined types, type parameters (and with that
type aliases denoting named types).
In the process some of the wording on method promotion
didn't get updated correctly. At attempt to fix this
was made with CL 406054, but while that CL's description
correctly explained the intent, the CL changed the prose
from "defined type" to "named type" (which had the new
meaning after Go 1.18), and thus did not fix the issue.
This CL fixes that fix by using the term "type name".
This makes the prose consistent for embedded types and
in turn clarifies that methods of embedded alias types
(defined or not) can be promoted, consistent with the
implementation.
While at it, also document that the type of an embedded
field cannot be a type parameter. This restriction has
been in place since the introduction of type parameters
with Go 1.18 and is enforced by the compiler.
Fixes#66540.
For #41687.
Change-Id: If9e6a03d7b84d24a3e6a5ceda1d46bda99bdf1f4
Reviewed-on: https://go-review.googlesource.com/c/go/+/603958
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Reviewed-by: Axel Wagner <axel.wagner.hh@googlemail.com>
Only honor //go:build language version downgrades if the version
specified is 1.21 or greater. Before 1.21 the version in //go:build
lines didn't have the meaning of setting the file's language version.
This fixes an issue that was appearing in GOPATH builds: Go 1.23 started
providing -lang versions to the compiler in GOPATH mode (among other
places) which it wasn't doing before.
For example, take a go file with a //go:build line specifying go1.10.
If that file used a 1.18 feature, that use would compile fine with a Go
1.22 toolchain. But, before this change, it would produce an error when
compiling with the 1.23 toolchain because it set the language version to
1.20 and disallowed the 1.18 feature. This breaks backwards
compatibility: when the build tag was added, it did not have the meaning
of restricting the language version.
Fixes#68658
Change-Id: I4ac2b45a981cd019183d52ba324ba8f0fed93a8e
Reviewed-on: https://go-review.googlesource.com/c/go/+/603895
Reviewed-by: Robert Griesemer <gri@google.com>
Commit-Queue: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Matloob <matloob@golang.org>
Currently the crash function on Wasm is implemented as a nil
pointer dereference, which turns into a sigpanic, which turns into
"panic during runtime execution" as we're already in runtime when
crash is called. Instead, just abort, which crashes hard and
terminates the Wasm module execution, and the execution engine
often dumps a stack trace.
Change-Id: I3c57f8ff7a0c0015e4abcd7bf262bf9001624b85
Reviewed-on: https://go-review.googlesource.com/c/go/+/604515
Reviewed-by: Achille Roussel <achille.roussel@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
CL 603055 added basic support of wasmexport. This CL follows it
and adds stack unwinding handling. If the wasmexport Go function
returns normally, we directly return to the host. If the Go
function unwinds the stack (e.g. goroutine switch, stack growth),
we need to run a PC loop to call functions on the new stack,
similar to wasm_pc_f_loop. One difference is that when the
wasmexport function returns normally, we need to exit the loop and
return to the host.
Now a wasmimport function can call back into the Go via wasmexport.
During the callback the stack could have moved. The wasmimport
code needs to read a new SP after the host function returns,
instead of assuming the SP doesn't change.
For #65199.
Change-Id: I62c1cde1c46f7eb72625892dea41e8137b361891
Reviewed-on: https://go-review.googlesource.com/c/go/+/603836
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Achille Roussel <achille.roussel@gmail.com>
When running a go binary compiled to wasm using node.js on a Windows platform,
the absolute path passed in is also incorrectly forced to expand.
For example:
E:\Project\CS_Project\gsv\testdata\result.gob.gz
will results to
open C:\Users\zxilly\AppData\Local\wasm-exec\go1.23rc1\E:\Project\CS_Project\gsv\testdata\result.gob.gz: No such file or directory
C:\Users\zxilly\AppData\Local\wasm-exec\go1.23rc1 is the place of
wasm_exec_node.js
Fixes: #68820
Change-Id: Ic30c6242302f8915ac1b8ea9f24546935cbb791e
GitHub-Last-Rev: f35ff1a2ee
GitHub-Pull-Request: golang/go#68255
Reviewed-on: https://go-review.googlesource.com/c/go/+/595797
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: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
This CL adds a compiler directive go:wasmexport, which applies to
a Go function and makes it an exported function of the Wasm module
being built, so it can be called directly from the host. As
proposed in #65199, parameter and result types are limited to
32-bit and 64-bit integers and floats, and there can be at most
one result.
As the Go and Wasm calling conventions are different, for a
wasmexport function we generate a wrapper function does the ABI
conversion at compile time.
Currently this CL only adds basic support. In particular,
- it only supports executable mode, i.e. the Go wasm module calls
into the host via wasmimport, which then calls back to Go via
wasmexport. Library (c-shared) mode is not implemented yet.
- only supports wasip1, not js.
- if the exported function unwinds stacks (goroutine switch, stack
growth, etc.), it probably doesn't work.
TODO: support stack unwinding, c-shared mode, js.
For #65199.
Change-Id: Id1777c2d44f7d51942c1caed3173c0a82f120cc4
Reviewed-on: https://go-review.googlesource.com/c/go/+/603055
Reviewed-by: Than McIntosh <thanm@golang.org>
Reviewed-by: Randy Reddig <randy.reddig@fastly.com>
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
(Second attempt at CL 529816 (f1d6050), reverted in
CL 571695 (1304d98) due to broken longtest builder.)
The tests analyser reports structural problems in test
declarations. Presumably most of these would be caught by
go test itself, which compiles and runs (some subset of) the
tests, but Benchmark and Fuzz functions are executed less
frequently and may benefit more from static checks.
A number of tests of "go vet" needed to be updated, either
to avoid mistakes caught by the analyzer, or to suppress
the analyzer when the mistakes were intended.
Also, reflect the change in go test help message.
+ release note
Fixesgolang/go#44251
Change-Id: I1c311086815fe55a66cce001eaab9b41e27d1144
Reviewed-on: https://go-review.googlesource.com/c/go/+/603476
Auto-Submit: Alan Donovan <adonovan@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
user.Current is slow on Windows sessions connected to an Active
Directory domain. This is because it uses Windows APIs that do RPC
calls to the domain controller, such as TranslateAccountW and
NetUserGetInfo.
This change speeds up user.Current by using the GetUserNameEx API
instead, which is already optimized for retrieving the current user
name in different formats.
These are the improvements I see with the new implementation:
goos: windows
goarch: amd64
pkg: os/user
cpu: Intel(R) Core(TM) i7-10850H CPU @ 2.70GHz
│ old.txt │ new.txt │
│ sec/op │ sec/op vs base │
Current-12 501.8µ ± 7% 118.6µ ± 11% -76.36% (p=0.000 n=10)
│ old.txt │ new.txt │
│ B/op │ B/op vs base │
Current-12 888.0 ± 0% 832.0 ± 0% -6.31% (p=0.000 n=10)
│ old.txt │ new.txt │
│ allocs/op │ allocs/op vs base │
Current-12 15.00 ± 0% 11.00 ± 0% -26.67% (p=0.000 n=10)
Updates #5298Fixes#21867Fixes#68312
Cq-Include-Trybots: luci.golang.try:gotip-windows-amd64-longtest
Change-Id: I893c5fcca6969050d73a20ed34770846becd5f5e
Reviewed-on: https://go-review.googlesource.com/c/go/+/597255
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
It appears that some builders (notably, linux-arm) have some additional
security software installed, which apparently reads the files created by
tests. As a result, test file atime is changed, making the test fail
like these:
=== RUN TestChtimesOmit
...
os_test.go:1475: atime mismatch, got: "2024-07-30 18:42:03.450932494 +0000 UTC", want: "2024-07-30 18:42:02.450932494 +0000 UTC"
=== RUN TestChtimes
...
os_test.go:1539: AccessTime didn't go backwards; was=2024-07-31 20:45:53.390326147 +0000 UTC, after=2024-07-31 20:45:53.394326118 +0000 UTC
According to inode(7), atime is changed when more than 0 bytes are read
from the file. So, one possible solution to these flakes is to make the
test files empty, so no one can read more than 0 bytes from them.
Fixes#68687Fixes#68663
Change-Id: Ib9234567883ef7b16ff8811e3360cd26c2d6bdab
Reviewed-on: https://go-review.googlesource.com/c/go/+/604315
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Kirill Kolyshkin <kolyshkin@gmail.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Commit-Queue: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Go utilizes copy_file_range(2) for file-to-file copying only on kernel 5.3+,
but even on 5.3+ this system call can still go wrong for some reason (check
out the comment inside poll.CopyFileRange).
Before Linux 2.6.33, out_fd must refer to a socket, but since Linux 2.6.33
it can be any file. Thus, we can employ sendfile(2) for copy between files
when copy_file_range(2) fails to handle the copy, that way we can still
benefit from the zero-copy technique on kernel <5.3 and wherever
copy_file_range(2) is available but broken.
Change-Id: I3922218c95ad34ee649ccdf3ccfbd1ce692bebcc
Reviewed-on: https://go-review.googlesource.com/c/go/+/603295
Reviewed-by: David Chase <drchase@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>
We don't need noLimit checks in a bunch of places.
Also simplify folding of provable constant results.
At this point in the CL stack, compilebench reports no performance
changes. The only thing of note is that binaries got a bit smaller.
name old text-bytes new text-bytes delta
HelloSize 960kB ± 0% 952kB ± 0% -0.83% (p=0.000 n=10+10)
CmdGoSize 12.3MB ± 0% 12.1MB ± 0% -1.53% (p=0.000 n=10+10)
Change-Id: Id4be75eec0f8c93f2f3b93a8521ce2278ee2ee2c
Reviewed-on: https://go-review.googlesource.com/c/go/+/599197
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>
Here begins a pretty major rewrite of the prove pass. The fundamental
observation is that although keeping facts about relations between
two SSA values could use O(n^2) space, keeping facts about relations
between an SSA value and constants needs only O(n) space. We can just
keep track of min/max for every SSA value at little cost.
Redo the limit table to just keep track of limits for all SSA values.
Use just a slice instead of a map. It may use more space (but still
just O(n) space), but accesses are a lot faster. And with the cache
in the compiler, that space will be reused quickly.
This is part of my planning to add lots more constant limits in the
prove pass.
Change-Id: Ie36819fad5631a8b79c3630fe0e819521796551a
Reviewed-on: https://go-review.googlesource.com/c/go/+/599255
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>
The syntax parser complains about invalid identifiers.
Don't report a typechecker error when such an identifier
cannot be found in the current scope.
For now add a local test for types2 only because the
go/parser behaves differently than the syntax parser
which leads to slightly different error positions.
Fixes#68183.
Change-Id: Idbfe62fafcd704886069182744ec5e6b37ffc4e1
Reviewed-on: https://go-review.googlesource.com/c/go/+/602476
Auto-Submit: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Tim King <taking@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
When producing an ImportPathError from ImportErrorf, we check to see
whether the error string contains the path for the error. The issue is
that we were checking for the exact path string when sometimes the
string is quoted when the error is constructed, and the escaping in the
quote may not match the path string. Check for both the path string, and
the quoted path string.
Fixes#68737
Change-Id: I01bf4e495056e929570bc11bc1f2000ce6d2802b
Reviewed-on: https://go-review.googlesource.com/c/go/+/603475
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
This CL does some minor refactoring of the code handling
wasmimport.
- Put the WasmImport aux reading and writing code together for
symmetry.
- Define WasmFuncType, embedded in WasmImport. WasmFuncType could
also be used (later) for wasmexport.
- Move code generation code to a separate function. The containing
function is already pretty large.
- Simplify linker code a little bit. The loader convention is to
return the 0 Sym for nonexistent symbol, instead of a separate
boolean.
No change in generated code. Passes toolstash -cmp
(GOARCH=wasm GOOS=wasip1 go build -toolexec "toolstash -cmp" -a std cmd).
Change-Id: Idc2514f84a08621333841ae4034b81130e0ce411
Reviewed-on: https://go-review.googlesource.com/c/go/+/603135
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>
Fixes#68548
Add GOENV=off, GOFLAGS= to the build of the stdlib, so that it matches
what runcmd does. This ensures that the runtime and the test are built
with the same flags. As opposed to before this CL, where flags were used
in the stdlib build but not the runcmd build.
(Part of the problem here is that cmd/internal/testdir/testdir_test.go
plays fast and loose with the build cache to make the tests run faster.
Maybe some of that fast-and-loose mechanism can be removed now that we
have a better build cache? I'm not sure.)
Change-Id: I449d4ff517c69311d0aa4411e7fb96c0cca49269
Reviewed-on: https://go-review.googlesource.com/c/go/+/600276
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
During the GC mark phase, one of the first behaviors of findRunnable is
to check if it should execute a GC mark worker. Mark workers often run
for many milliseconds in a row, so programs that invoke the scheduler
more frequently will see that condition trigger only a tiny fraction of
the time.
Obtaining a mark worker from the gcBgMarkWorkerPool involves a CAS on a
single memory location that's shared across the process. When GOMAXPROCS
is large, the resulting contention can waste a significant amount of CPU
time. But a sufficiently large GOMAXPROCS also means there's no need for
fractional mark workers, making it easier to check ahead of time if we
need to run a worker.
Check, without committing to a particular worker, whether we would even
want to run one.
For #68399
Change-Id: I5d8578c2101ee20a8a4156a029584356095ea118
Reviewed-on: https://go-review.googlesource.com/c/go/+/602477
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Rhys Hiltner <rhys.hiltner@gmail.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
notes are used in sensitive locations in the runtime, such as those with
write barriers forbidden. Maps aren't designed for this sort of internal
use.
Notably, newm -> notewakeup doesn't allow write barriers, but mapaccess1
-> panic contains write barriers. The js runtime only builds right now
because the map access is optimized to mapaccess1_fast64, which happens
to not have a panic call.
The initial swisstable map implementation doesn't have a fast64 variant.
While we could add one, it is a bad idea in general to use a map in such
a fragile location. Simplify the implementation by storing the metadata
directly in the note, and using a linked list for checkTimeouts.
For #54766.
Cq-Include-Trybots: luci.golang.try:gotip-js-wasm
Change-Id: Ib9d39f064ae4ad32dcc873f799428717eb6c2d5a
Reviewed-on: https://go-review.googlesource.com/c/go/+/595558
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
These are delay primitives for lock2. If a mutex isn't immediately
available, we can use procyield to tell the processor to wait for a
moment, or osyield to allow the OS to run a different process or thread
if one is waiting. We expect a processor-level yield to be faster than
an os-level yield, and for both of them to be fast relative to entering
a full sleep (via futexsleep or semasleep).
Each architecture has its own way of hinting to the processor that it's
in a spin-wait loop, so procyield presents an architecture-independent
interface for use in lock_futex.go and lock_sema.go.
Measure the (single-threaded) speed of these to confirm.
For #68578
Change-Id: I90cd46ea553f2990395aceb048206285558c877e
Reviewed-on: https://go-review.googlesource.com/c/go/+/601396
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
This change replaces the usage of the "sort" package with the "slices"
package for sorting IP addresses and DNS records. The new approach
simplifies the code and improves readability by leveraging the
slices.SortFunc and slices.SortStableFunc functions.
- Updated addrselect.go to use slices.SortStableFunc for sorting IP
addresses based on RFC 6724.
- Refactored dnsclient.go to use slices.SortFunc for sorting SRV and MX
records by priority and weight.
This change also reduces the dependency tree for the package by
removing the dependency on "sort" and its transitive dependencies,
resulting in a leaner build.
Change-Id: I436dacc8dd1e8f2f7eeac44d6719ce248394d8a9
GitHub-Last-Rev: 3720a49081
GitHub-Pull-Request: golang/go#67503
Reviewed-on: https://go-review.googlesource.com/c/go/+/586635
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
CL 594740 rewrote type checking of method receiver types. Because that
CL takes apart receivers "manually" rather than using the regular code
for type checking type expressions, type parameters in receiver type
expressions were only recorded as definitions (in Info.Defs).
Before that CL, such type parameters were simultaneously considered
definitions (they are declared by the receiver type expression) and
uses (they are used to instantiate the receiver type expression).
Adjust the receiver type checking code accordingly and record its
type parameters also in Info.Uses and Info.Types.
While at it, in go/types, replace declareTypeParams (plural) with
declareTypeParam (singular) to more closely match types2 code.
No functionality or semantic change.
Fixes#68670.
For #51343.
Change-Id: Ibbca1a9b92e31b0dc972052a2827deeab49da98b
Reviewed-on: https://go-review.googlesource.com/c/go/+/601935
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Tim King <taking@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Rather than reading the entire data segment into memory, read it in
smaller chunks to keep memory usage low.
For typically Go binaries, this doesn't matter much. For those, we read
the .go.buildinfo section, which should be quite small. But for non-Go
binaries (or Go binaries with section headers stripped), we search the
entire loadable data segment, which could be quite large.
This reduces the time for `go version` on a 2.5GB non-Go binary from
~1.2s and 1GB RSS (!!) to ~1s and ~25MB RSS.
Fixes#68592.
Change-Id: I9218854c5b6f2aa1331f561ab0850a9fd62ef23b
Reviewed-on: https://go-review.googlesource.com/c/go/+/601459
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Add in automatic README generation and README consistency checking for
the cmd/compile and cmd/link script tests. This code is adapted from
the similar facility in cmd/go (e.g. scriptreadme_test.go); the README
helps folks writing new tests understand the mechanics.
Updates #68606.
Change-Id: I8ff7ff8e814abd4385bd670440511b2c60a4cef6
Reviewed-on: https://go-review.googlesource.com/c/go/+/601756
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Introduce a new function AddToolChainScriptConditions that augments a
default "script.Cond" set with a collection of useful conditions,
including godebug/goexperiment, cgo, race support, buildmode, asan,
msan, and so on. Having these conditions available makes it easier to
write script tests that deal with specific build-flavor corner cases.
The functions backing the new conditions are helper functions migrated
over from the Go command's script test setup.
Updates #68606.
Change-Id: I14def1115b54dc47529c983abcd2c5ea9326b9de
Reviewed-on: https://go-review.googlesource.com/c/go/+/601715
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
CL 594740 rewrote type checking of method receiver types. Because that
CL takes apart receivers "manually" rather than using the regular code
for type checking type expressions, pointer and parenthesized receiver
type expressions were not recorded anymore.
Adjust the code that typechecks method receivers to a) use ordinary
type expression checking for non-generic receivers, and b) to record
a missing pointer and any intermediate parenthesized expressions in
case of a generic receiver.
Add many extra tests verifying that the correct types for parenthesized
and pointer type expressions are recorded in various source positions.
Note that the parser used by the compiler and types2 doesn't encode
unnecessary parentheses in type expressions in its syntax tree.
As a result, the tests that explicitly test parentheses don't work
in types2 and are commented out.
This CL adds code (disabled by default) to the parser to encode
parentheses in type expressions in the syntax tree. When enabled,
the commented out types2 tests pass like in go/types.
Fixes#68639.
For #51343.
Change-Id: Icf3d6c76f7540ee53e229660be8d78bb25380539
Reviewed-on: https://go-review.googlesource.com/c/go/+/601657
Reviewed-by: Tim King <taking@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
In clang 16 the option -fsanitize-memory-param-retval was turned on by
default. That option causes MSAN to issue a warning when calling a
function with an uninitialized value. The msan8 test relies on being
able to do this, in order to get uninitialized values into registers.
This CL fixes the test by adding maybe_undef attributes that tell
clang that it's OK to pass an uninitialized variable. The docs for
maybe_undef say: "Please note that this is an attribute that is used as
an internal implementation detail and not intended to be used by
external users." So this may break in the future, but it does work for now.
Fixes#64616
Change-Id: I0ac8c0520fce8c32e26d2a5efb7ae5e02461c1ce
Reviewed-on: https://go-review.googlesource.com/c/go/+/601779
Auto-Submit: 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>
The buildinfo used for a testmain is a copy from the buildinfo produced
for the package under test, and that in turn is only computed if the
package under test is package main. If there are //go:debug directives
in a test file for package main, the godebugs for the testmain (which
are computed using the regular package files as well as the test files'
//go:debug directives) will be different from those used to produce the
buildinfo of the package under test (computed using the //go:debug
directives only in the main package). In that case, recompute the
buildinfo for the testmain to incorporate the new godebug information.
Since we've only been generating buildinfo for tests on package main, in
this CL we'll only recompute the buildinfo if the test is for package
main. It's not clear to me though if we should be computing the
buildinfo for all test mains (or none of them?)
Fixes#68053
Change-Id: Ib6cdb118e2f233de483c33e171c0cd03df1fc7be
Reviewed-on: https://go-review.googlesource.com/c/go/+/595961
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
The current test often doesn't actually generate enough interleaving
to result in multiple log shards. This CL rewrites this test to
forcibly create at least 10 log shards with interleaved log messages.
It also tests dlog's robustness to being held across M and P switches.
Change-Id: Ia913b17c0392384ff679832047f359945669bb15
Reviewed-on: https://go-review.googlesource.com/c/go/+/600699
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Auto-Submit: Austin Clements <austin@google.com>
This CL adds a "deadlocals" pass, which runs after inlining and before
escape analysis, to prune any unneeded local variables and
assignments. In particular, this helps avoid unnecessary Addrtaken
markings from unreachable closures.
Deadlocals is sensitive to "_ = ..." as a signal of explicit
use for testing. This signal occurs only if the entire
left-hand-side is "_" targets; if it is
`_, ok := someInlinedFunc(args)`
then the first return value is eligible for dead code elimination.
Use this (`_ = x`) to fix tests broken by deadlocals elimination.
Includes a test, based on one of the tests that required modification.
Matthew Dempsky wrote this, changing ownership to allow rebases, commits, tweaks.
Fixes#65158.
Old-Change-Id: I723fb69ccd7baadaae04d415702ce6c8901eaf4e
Change-Id: I1f25f4293b19527f305c18c3680b214237a7714c
Reviewed-on: https://go-review.googlesource.com/c/go/+/600498
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>
Auto-Submit: David Chase <drchase@google.com>
Commit-Queue: David Chase <drchase@google.com>
When generating DW_TAG_subroutine_type DIEs during linker DWARF type
synthesis, ensure that in the list of children of the subroutine type
DIE (correspondings to input/output params) the output params are
marked with the DW_AT_variable_parameter attribute. In addition, fix
up the generated types of the output params: prior to this patch for a
given output parameter of type T, we would emit the DIE type as *T
(presumably due to how parameter passing/returning worked prior to the
register ABI); with this patch the emitted type will just be T, not *T.
Fixes#59977.
Change-Id: I5b5600be86473695663c75b85baeecad667b9245
Reviewed-on: https://go-review.googlesource.com/c/go/+/595715
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>
Currently, the debuglog tests only run when the debuglog build tag is
set because, until the last few CLs, all of debuglog was compiled away
without that build tag. This causes two annoying problems:
1. The tests basically never run, because we don't regularly test this
configuration.
2. If you do turn on the debuglog build tag, it's probably because
you're adding debuglogs into the runtime, which are very likely to
mess up these tests, so you wind up disabling the tests and they,
again, don't get coverage.
Now we've set things up so the debuglog implementation is always
accessible, if you ask nicely enough. So we can switch these tests to
run when the tag is *not* set, and turn off when the tag *is* set (and
you're probably adding actual log statements).
Change-Id: Ib68d7a5022d4f5db96e9c7c8010cbef21d11fe11
Reviewed-on: https://go-review.googlesource.com/c/go/+/600697
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Currently, the debuglog build tag controls the dlogEnabled const, and
all methods of dlogger first check this const and immediately return
if dlog is not enabled. With constant folding and inlining, this makes
the whole dlog implementation compile away if it's not enabled.
However, we want to be able to test debuglog even when the build tag
isn't set. For that to work, we need a different mechanism.
This CL changes this mechanism so the debuglog build tag instead
controls the type alias for dlogger to be either dloggerImpl or
dloggerFake. These two types have the same method set, but one is just
stubs. This way, the methods of dloggerImpl don't need to be
conditional dlogEnabled, which sets us up to use the now
fully-functional dloggerImpl type in the test.
I confirmed that this change has no effect on the final size of the
cmd/go binary. It does increase the size of the runtime.a file by 0.9%
and make the runtime take ever so slightly longer to compile because
the compiler can no longer simply eliminate the bodies of the all of
dlogger during early deadcode. However, this all gets eliminated by
the linker. I consider this worth it to always get build and test
coverage of debuglog.
Change-Id: I81759e9e1411b7d369a23383a18b022ab7451421
Reviewed-on: https://go-review.googlesource.com/c/go/+/600696
Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Add support for running script tests as part of the compiler's suite
of tests, hooking in the script test engine packages recently moved
from cmd/go to cmd/internal. These script tests will use the test
binary itself as the compile tool for Go builds, and can also run the
C compiler if needed. New script test cases (*.txt files) should be
added to the directory cmd/compile/testdata/script.
Updates #68606.
Change-Id: I9b056a07024b0a72320a89ad734e4b4a51f1c10c
Reviewed-on: https://go-review.googlesource.com/c/go/+/601361
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>
Add support for running script tests as part of the linker's suite of
tests, hooking in the script test engine packages recently moved from
cmd/go to cmd/internal. Linker script tests will use the test binary
itself as the linker for Go builds, and can also run the C compiler if
needed. New script test cases (*.txt files) should be added to the
directory cmd/link/testdata/script.
For demo purposes, this patch also adds a new "randlayout_option.txt"
script test that replicates the existing linker's TestRandLayout
testpoint in script form.
Updates #68606.
Change-Id: Icf26bf657850e39548d6ea819f2542fc68a3899b
Reviewed-on: https://go-review.googlesource.com/c/go/+/601360
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>
Relocate cmd/go's internal/robustio package up a level into
cmd/internal/robustio, so that it can be used by other cmd/internal
packages. No change in functionality. This change is intended to be in
support of making the cmd/go script test framework available to other
commands in addition to just the Go command.
Updates #68606.
Change-Id: Ic8421ef59d9b7d79a50c3679d180cfa2546c4cd3
Reviewed-on: https://go-review.googlesource.com/c/go/+/601356
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Relocate cmd/go's internal/par package up a level into
cmd/internal/par, so that it can be used by other cmd/internal
packages. No change in functionality. This change is intended to be in
support of making the cmd/go script test framework available to other
commands in addition to just the Go command.
Updates #68606.
Change-Id: I920a5d5c9b362584fabdbb2305414325b42856a3
Reviewed-on: https://go-review.googlesource.com/c/go/+/601355
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
The trace parser was using an otherwise-unused event argument to hold an
extra goroutine state argument for the GoStatus & GoStatusStack events.
This is needed because the execution tracer just records the "after" for
state transitions, but we want to have both the "before" and "after"
states available in the StateTransition info for the parsed event. When
GoStatusStack was added, the size of the argument array was increased to
still have room for the extra status. However, statuses are currently
only 1 byte, and the status argument is 8 bytes, so there is plenty of
room to pack the "before" and "after" statuses in a single argument. Do
that instead to avoid the need for an extra argument.
Change-Id: I6886eeb14fb8e5e046b6afcc5b19e04218bcacd4
Reviewed-on: https://go-review.googlesource.com/c/go/+/601455
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
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>
On Loong64, the two input operands and one output operand of the ADDF
instruction are both floating-point registers; and the floating-point
comparison instruction CMPEQ{F,D}, CMPGE{F,D}, CMPGT{F,D} both input
operands are floating-point registers, and the output operation is a
floating-point condition register, currently, only FCC0 is used as the
floating-point condition register.
Example:
ADDF F0, F1, F0
CMPEQF F0, F1, FCC0
Change-Id: I4c1c453e522d43f294a8dcab7b6b5247f41c9c68
Reviewed-on: https://go-review.googlesource.com/c/go/+/580281
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
Auto-Submit: abner chenc <chenguoqi@loongson.cn>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
1) Factor out handling of receiver from Checker.funcType into
Checker.collectRecv. Analyze the receiver parameter "manually"
without resorting to calling Checker.collectParams.
The code is more straight-forward and error handling is simpler
because constructing the receiver type and variable is all handled
in one function.
2) Change Checker.collectParams to collect parameter names and
corresponding parameter variables, but do not declare them.
Instead return two equal-length slices of parameter names
and variables for later declaration.
3) Streamline Checker.funcType into a sequence of simple steps.
By declaring the receiver and parameters after type parameters,
there is no need for a temporary scope and scope squashing anymore.
4) Simplify Checker.unpackRecv some more: don't strip multiple
*'s from receiver type expression because we don't typecheck
that expression as a whole later (we don't use collectParams
for receiver types anymore). If we have a **T receiver, we
need to use *T (one * stripped) as receiver base type expression
so that we can report an error later.
5) Remove Checker.recvTParamMap and associated machinery as it is
not needed anymore.
6) Remove Scope.Squash/squash as it is not needed anymore.
7) Remove the explicit scope parameter from Checker.collectParams
as it is not needed anymore.
8) Minor adjustments to tests: in some cases, error positions have
shifted slightly (because we don't use Checker.collectParams to
typecheck receivers anymore), and in some cases duplicate errors
don't appear anymore (resolves TODOs).
Fixes#51343.
Change-Id: Ia77e939bb68e2912ef2e4ed68d2a7a0ad605c5ba
Reviewed-on: https://go-review.googlesource.com/c/go/+/594740
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Instead of returning the receiver type name (rname), return the
receiver type base expression (base), with pointer indirections
stripped. The type base may or may not not be a type name. This
is needed for further rewrites of the signature type-checking code.
Adjust call sites accordingly to preserve existing behavior.
For #51343.
Change-Id: Ib472ca25d43ec340762d0a8dd1ad038568c2b2bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/595335
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Tim King <taking@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Previously, the end position for a select statement clause body was
computed explicitly as the start of the next clause or the closing "}"
of the select statement, respectively.
Since syntax.EndPos computes the end position of a node, there's no
need to compute these positions "manually", we can simply use the
syntax.ExdPos for each clause. The positions are not exactly the
same as before but for the purpose of identifier visibility in
scopes there is no semantic change.
Simplifies the code and brings it more in line with go/types.
Change-Id: I24bca85a131a0ea31a2adaafc08ab713450258fb
Reviewed-on: https://go-review.googlesource.com/c/go/+/593016
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>
Move logic for type-specific variable type into typeCases function
which already does all the relevant work.
Add more detailed documentation to typeCases function.
Uncomment alernative typeCases function so that it is being type-
checked and kept up-to-date. Since it's not (yet) used, the code
will not appear in the binary.
Follow-up on CL 592555.
Change-Id: I6e746503827d512a1dbf7b99b48345c480e61200
Reviewed-on: https://go-review.googlesource.com/c/go/+/592616
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>
Currently, we can only cache regular trace event buffers on each M. As
a result, calling unsafeTraceExpWriter will, in effect, always return
a new trace batch, with all of the overhead that entails.
This extends that cache to support buffers for experimental trace
data. This way, unsafeTraceExpWriter can return a partially used
buffer, which the caller can continue to extend. This gives the caller
control over when these buffers get flushed and reuses all of the
existing trace buffering mechanism.
This also has the consequence of simplifying the experimental batch
infrastructure a bit. Now, traceWriter needs to know the experiment ID
anyway, which means there's no need for a separate traceExpWriter
type.
Change-Id: Idc2100176c5d02e0fbb229dc8aa4aea2b1cf5231
Reviewed-on: https://go-review.googlesource.com/c/go/+/594595
Auto-Submit: Austin Clements <austin@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The abi.NoEscape function is introduced to replace all usages of
noescape wrapper in the standard library. However, the last usage in
reflect package is still present, because the inlining test failed if
abi.NoEscape were used. The reason is that reflect.noescape is treated
as a cheap call, while abi.NoEscape is not.
By treating abi.NoEscape a cheap call, the last usage of noescape in
reflect package can now be removed.
Change-Id: I798079780129221a5a26cbcb18c95ee30855b784
Reviewed-on: https://go-review.googlesource.com/c/go/+/601275
Reviewed-by: Dmitri Shuralyov <dmitshur@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: Cherry Mui <cherryyz@google.com>
This change allows the tracer to be reentrant by restructuring the
internals such that writing an event is atomic with respect to stack
growth. Essentially, a core set of functions that are involved in
acquiring a trace buffer and writing to it are all marked nosplit.
Stack growth is currently the only hidden place where the tracer may be
accidentally reentrant, preventing the tracer from being used
everywhere. It already lacks write barriers, lacks allocations, and is
non-preemptible. This change thus makes the tracer fully reentrant,
since the only reentry case it needs to handle is stack growth.
Since the invariants needed to attain this are subtle, this change also
extends the debugTraceReentrancy debug mode to check these invariants as
well. Specifically, the invariants are checked by setting the throwsplit
flag.
A side benefit of this change is it simplifies the trace event writing
API a good bit: there's no need to actually thread the event writer
through things, and most callsites look a bit simpler.
Change-Id: I7c329fb7a6cb936bd363c44cf882ea0a925132f3
Reviewed-on: https://go-review.googlesource.com/c/go/+/587599
Reviewed-by: Austin Clements <austin@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The Go release notes are served on multiple domains (go.dev,
golang.google.cn, tip.golang.org, localhost:8080 and so on), so links
pointing to the Go website itself need to be relative to work in all
those contexts.
Caught by a test in x/website. The next CL adds the same test to this
repository so these kinds of problems are caught sooner and with less
friction.
For #68545.
Fixes#68575.
Change-Id: I08056b98968c77a1d0ed93b63fccfbe41274ec8f
Reviewed-on: https://go-review.googlesource.com/c/go/+/600656
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
For atomic AND and OR operations on memory, we currently have two
views of the op. One just does the operation on the memory and returns
just a memory. The other does the operation on the memory and returns
the old value (before having the logical operation done to it) and
memory.
Update #61395
These two type differently, and there's currently some confusion in
our rules about which is which. Use different names for the two
different flavors so we don't get them confused.
Change-Id: I07b4542db672b2cee98169ac42b67db73c482093
Reviewed-on: https://go-review.googlesource.com/c/go/+/594976
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Nicolas Hillegeer <aktau@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Mauri de Souza Meneguzzo <mauri870@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
When there are multiple declarations of a function, ensure that
those declarations at least agree on the size/alignment of arguments
and return values.
It's hard to be stricter given existing code and situations where
arguments differ only by typedefs. For instance:
int usleep(unsigned);
int usleep(useconds_t);
Fixes#67699.
Change-Id: I3b4b17afee92b55f9e712b4590ec608ab1f7ac91
Reviewed-on: https://go-review.googlesource.com/c/go/+/588977
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: Ian Lance Taylor <iant@google.com>
An InlMark "read" can't make an otherwise dead store live. Without this
CL, we sometimes zero an object twice in succession because we think
there is a reader in between.
Kind of challenging to make a test for this. The second zeroing has the
same instruction on the same line number, so codegen tests can't see it.
Fixes#67957
Change-Id: I7fb97ebff50d8eb6246fc4802d1136b7cc76c45f
Reviewed-on: https://go-review.googlesource.com/c/go/+/592615
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>
The Go 1.24 development tree has opened. This is a time to update
all golang.org/x/... module versions that contribute packages to the
std and cmd modules in the standard library to latest master versions.
For #36905.
[git-generate]
go install golang.org/x/build/cmd/updatestd@latest
go install golang.org/x/tools/cmd/bundle@latest
updatestd -goroot=$(pwd) -branch=master
Change-Id: I5a012af9f041f79ab4d5b30569a154e0c2d1617e
Reviewed-on: https://go-review.googlesource.com/c/go/+/600535
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>
Currently internal/trace/testdata contains three debugging tools which
were written early in the trace rewrite for debugging. Two of these are
completely redundant with go tool trace -d=1 and go tool trace -d=2. The
only remaining one landed in the last cycle and could easily also be
another debug mode.
This change thus merges gotraceeventstats into go tool trace as a new
debug mode, and updates the debug mode flag (-d) to accept a string,
giving each mode a more descriptive name.
Change-Id: I170f30440691b81de846b4e247deb3d0982fc205
Reviewed-on: https://go-review.googlesource.com/c/go/+/593975
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>
The current memmove implementation uses REP MOVSB to copy data larger than
2KB when the useAVXmemmove global variable is false and the CPU supports
the ERMS feature.
This feature is currently only enabled on CPUs in the Sandy Bridge (Client)
, Sandy Bridge (Server), Ivy Bridge (Client), and Ivy Bridge (Server)
microarchitectures.
For modern Intel CPU microarchitectures that support the ERMS feature, such
as Ice Lake (Server), Sapphire Rapids , REP MOVSB achieves better
performance than the AVX-based copy currently implemented in memmove.
Benchstat result:
goos: linux
goarch: amd64
pkg: runtime
cpu: Intel(R) Xeon(R) Gold 6348 CPU @ 2.60GHz
│ ./old.txt │ ./new.txt │
│ sec/op │ sec/op vs base │
Memmove/2048-2 25.24n ± 0% 24.27n ± 0% -3.84% (p=0.000 n=10)
Memmove/4096-2 44.87n ± 0% 33.16n ± 1% -26.11% (p=0.000 n=10)
geomean 33.65n 28.37n -15.71%
│ ./old.txt │ ./new.txt │
│ B/s │ B/s vs base │
Memmove/2048-2 75.56Gi ± 0% 78.59Gi ± 0% +4.02% (p=0.000 n=10)
Memmove/4096-2 85.01Gi ± 0% 115.05Gi ± 1% +35.34% (p=0.000 n=10)
geomean 80.14Gi 95.09Gi +18.65%
Fixes#66958
Change-Id: I1fafd1b51a16752f83ac15047cf3b29422a79d5d
GitHub-Last-Rev: 89cf5af32b
GitHub-Pull-Request: golang/go#66959
Reviewed-on: https://go-review.googlesource.com/c/go/+/580735
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>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
// We've walked the function bodies, so we've seen everywhere a
// variable might be reassigned or have it's address taken. Now we
// variable might be reassigned or have its address taken. Now we
// can decide whether closures should capture their free variables
// by value or reference.
for_,closure:=rangeb.closures{
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.
