We can find a few issues finally turned out to be a race condition,
such as #47513. I believe such a tip can eliminate the need for developers
to file this kind of issue in the first place.
Change-Id: I1597fa09fde641882e8e87453470941747705272
GitHub-Last-Rev: 9f136f5b3b
GitHub-Pull-Request: golang/go#70331
Reviewed-on: https://go-review.googlesource.com/c/go/+/627816
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>
Reviewed-by: Jorropo <jorropo.pgm@gmail.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Sized addMulVVW (addMulVVW1024 etc.) have architecture-specific
implementations on a number of architectures. Add a test checking
that they match the generic implementation.
Change-Id: I574f00ad7cd27d4e1bf008561023f713876244f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/628256
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Fixes#16241
I made 64 bits op on 32 bits arches still leak since it was kinda promised.
The promised leaks were wider than this but I don't belive it's effect can
be observed in an breaking maner without using unsafe the way it's currently
setup.
Change-Id: I66d8df47bfe49bce3efa64ac668a2a55f70733a3
Reviewed-on: https://go-review.googlesource.com/c/go/+/462298
Reviewed-by: Mauri de Souza Meneguzzo <mauri870@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
This CL adds support for a custom authenticator as a valid GOAUTH command.
This follows the specification in
https://go.dev/issue/26232#issuecomment-461525141
For #26232
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Change-Id: Id1d4b309f11eb9c7ce14793021a9d8caf3b192ff
Reviewed-on: https://go-review.googlesource.com/c/go/+/605298
Auto-Submit: Sam Thanawalla <samthanawalla@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This CL adds support for tagging binaries in a bzr vcs environment.
For: #50603
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Change-Id: I81eb72d9e0e15dbec8778dd06613ca212820a726
Reviewed-on: https://go-review.googlesource.com/c/go/+/627295
Auto-Submit: Sam Thanawalla <samthanawalla@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Go 1.24 is the last release that will run on macOS 11 Big Sur.
Go 1.25 will require macOS 12 Monterey or later.
For #69839.
For #23011.
Change-Id: Ic58beff0f7eb69f600add5c17cf6edd960d09980
Reviewed-on: https://go-review.googlesource.com/c/go/+/627616
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Built-in service user accounts should be treated as special cases
of well-known groups and allowed in user.Lookup and user.LookupId.
Namely, these accounts are:
- NT AUTHORITY\SYSTEM (S-1-5-18)
- NT AUTHORITY\LOCAL SERVICE (S-1-5-19)
- NT AUTHORITY\NETWORK SERVICE (S-1-5-20)
See https://learn.microsoft.com/en-us/windows/win32/services/service-user-accounts.
Note that #49509 also mentions S-1-5-17 (NT AUTHORITY\IUSR) as
another well-known group that should be treated as a user. I haven't
found any documentation supporting this claim, and it is not an account
that is used usually, so I'm not adding it for now.
This CL is heavily based on CL 452497.
Fixes#49509
Change-Id: I6e204ddfb4ed0c01b4503001cf284602531e4a88
Reviewed-on: https://go-review.googlesource.com/c/go/+/626255
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.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>
When using a FIPS140 snapshot, the import paths will have
FIPS version numbers in them, so use explicit import paths
for coordination with package runtime, which expects
crypto/internal/fips, not (say) crypto/internal/fips/v1.1.
Change-Id: I3ac48c84810493152e039eaa5f44d7cfe13d35f9
Reviewed-on: https://go-review.googlesource.com/c/go/+/627915
Reviewed-by: Cherry Mui <cherryyz@google.com>
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>
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>
It's actually a TOC relative relocation, but those are also accepted
as pcrel relocations here too. This fixes compilation on GOPPC64 <= power9.
Change-Id: I235125a76f59ab26c6c753540cfaeb398f9c105d
Reviewed-on: https://go-review.googlesource.com/c/go/+/628157
Auto-Submit: Paul Murphy <murp@ibm.com>
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>
This adds a package-level variable, slog.DiscardHandler, which is a
slog.Handler which performs no output. This serves a similar purpose
to io.Discard.
Fixes#62005
Change-Id: Ia8babc55f860dec9b663a5c400090a7669608fd5
GitHub-Last-Rev: 0a611174ee
GitHub-Pull-Request: golang/go#70296
Reviewed-on: https://go-review.googlesource.com/c/go/+/626486
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Deduplicates FindPkg and FindExportData which were shared by
go/internal/gcimporter and cmd/compile/internal/importer into
a new package internal/exportdata.
This change only moves code.
Change-Id: I1daf24dd79fafbe9014b2b15671dcde46b54711e
Reviewed-on: https://go-review.googlesource.com/c/go/+/626700
Commit-Queue: Tim King <taking@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
When multiple threads all need to acquire the same runtime.mutex, make
sure that none of them has to wait for too long. Measure how long a
single thread can capture the mutex, and how long individual other
threads must go between having a turn with the mutex.
For #68578
Change-Id: I56ecc551232f9c2730c128a9f8eeb7bd45c2d3b5
Reviewed-on: https://go-review.googlesource.com/c/go/+/622995
Auto-Submit: Rhys Hiltner <rhys.hiltner@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Minimizes the differences with go/internal/gcimporter.Import.
Note that the copy in cmd/compile/internal/importer is currently
only used in tests.
The delta between the two Import functions is now just types vs types2.
Change-Id: I5e94d3aa5bbdb78252e47310c95807f63e27ef3d
Reviewed-on: https://go-review.googlesource.com/c/go/+/626698
Commit-Queue: Tim King <taking@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Change-Id: I8ffb198d64ec1b89e6d13bfa299bf699f1ca3830
Reviewed-on: https://go-review.googlesource.com/c/go/+/628156
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Tim King <taking@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reuse (or copy) cmd/internal/archive.ReadHeader in importers.
Change-Id: I3caa19b1b366c2bbffcdeb0ef4db337ee457b47e
Reviewed-on: https://go-review.googlesource.com/c/go/+/626776
Commit-Queue: 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>
Since CL 599096 the compiler knows bits.TrailingZeros's maximum value
based on the input type size.
Since CL 603996 it knows it based on input's maximum value.
Change-Id: Ib0d6b15a3ba6894d3e7e12b79b387ddbffabe370
Reviewed-on: https://go-review.googlesource.com/c/go/+/618715
Auto-Submit: Robert Griesemer <gri@google.com>
Commit-Queue: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
The 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>
Change-Id: Ida74e8127c29d3e6f0a4322f86c7963fa2ef8244
GitHub-Last-Rev: ae479155d6
GitHub-Pull-Request: golang/go#70330
Reviewed-on: https://go-review.googlesource.com/c/go/+/627815
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Fixes#60998
Change-Id: I7e899708c7e0406bd9927eb411b57fc3240b7f18
GitHub-Last-Rev: c1a20aee0e
GitHub-Pull-Request: golang/go#60999
Reviewed-on: https://go-review.googlesource.com/c/go/+/506175
Reviewed-by: Ian Lance Taylor <iant@google.com>
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>
I believe now this code can work in both test and standalone situations.
Fixes#70057
Change-Id: Ieb5163e6b917fd03d050f65589df6c31ad2515fe
GitHub-Last-Rev: db4863c05e
GitHub-Pull-Request: golang/go#70270
Reviewed-on: https://go-review.googlesource.com/c/go/+/625904
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Bypass: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
It's not clear why strings here would have a *prefix* \n. This trim
was introduced back in March 2012 without explanation in omnibus
commit b03a5f66e8 (as a HasPrefix, since
we didn't have TrimPrefix at the time).
Change-Id: Ib0a7af36900e437fdc52ec5c1c921f92833f6cef
Reviewed-on: https://go-review.googlesource.com/c/go/+/558638
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Austin Clements <austin@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Sort the table of variables in the envcmd source code,
because all tables in all source code should be sorted
unless there's a reason they can't be.
Sort the go env output as well.
Sort the flag registrations, same reason.
Remove redundant range variable.
Change-Id: I5f1af3e22a09621706eb57c369bd2675b754b063
Reviewed-on: https://go-review.googlesource.com/c/go/+/627476
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>
Previous CLs committed changes to cmd/compile, cmd/link,
and crypto/internal/fips/check behind boolean flags.
Turn those flags on, to enable the CLs.
This is a separate, trivial CL for easier rollback.
For #69536.
Change-Id: I68206bae0b7d7ad5c8758267d1a2e68853b63644
Reviewed-on: https://go-review.googlesource.com/c/go/+/626000
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Prefix keywords (type, default, case, etc.) with "keyword" in error
messages to make them less ambiguous.
Fixes#68589.
Change-Id: I1eb92d1382f621b934167b3a4c335045da26be9f
Reviewed-on: https://go-review.googlesource.com/c/go/+/623819
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>
Reviewed-by: Tim King <taking@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>
Check the various pie combinations with the new FIPS code.
For #69536.
Change-Id: I8fc771eab465c4af46a0ec8154d550c1bf95f7d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/625999
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Don't report a (follow-on) error if a method is not found in a type
due to a prior error that made the type invalid, or which caused an
embedded field of a struct to have an invalid type (and thus one
cannot with certainty claim that a method is missing).
Fixes#53535.
Change-Id: Ib2879c6b3b9d927c93bbbf1d355397dd19f336f7
Reviewed-on: https://go-review.googlesource.com/c/go/+/626997
Auto-Submit: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Tim King <taking@google.com>
Reviewed-by: Robert Griesemer <gri@google.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>
Fixes#51269
Change-Id: I06747db18ca078c1f1bda9b7bc60006f53191f4d
Reviewed-on: https://go-review.googlesource.com/c/go/+/627035
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Ian Lance Taylor <iant@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>
Change-Id: I3a3b7da6245a18bf1db0c595008f0eea853ce544
Reviewed-on: https://go-review.googlesource.com/c/go/+/627155
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 Pratt <mpratt@google.com>
This matches the behavior of types2.
For #49005.
Change-Id: I45661c96124f1c75c4fb6f69cbba7c73984a8231
Reviewed-on: https://go-review.googlesource.com/c/go/+/626039
Auto-Submit: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@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>
Add cmd/internal/obj/mkcnames.go to do the generation and update
the architecture packages to use it to maintain the Cnames tables.
Currently works correctly on arm64,loong64,mips,ppc64 and s390x.
Change-Id: I5220b0ba6d8a8a5fcc4d9774731eb2af69a671af
Reviewed-on: https://go-review.googlesource.com/c/go/+/622256
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Meidan Li <limeidan@loongson.cn>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Qiqi Huang <huangqiqi@loongson.cn>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: sophie zhao <zhaoxiaolin@loongson.cn>
Commit-Queue: Ian Lance Taylor <iant@golang.org>
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>
