The old code picks a random number n and then tests n, n+2, n+4, up to
n+(1<<20) for primality before giving up and picking a new n.
(The chance of finishing the loop and picking a new n is infinitesimally
small.) This approach, called “incremental search” in the Handbook of
Applied Cryptography, section 4.51, demands fewer bits from the random
source and amortizes some of the cost of the small-prime division
checks across the incremented values.
This commit deletes the n+2, n+4, ... checks, instead picking a series
of random n and stopping at the first one that is probably prime.
This approach is called “rejection sampling.”
Reasons to make this change, in decreasing order of importance:
1. Rejection sampling is simpler, and simpler is more clearly correct.
2. The main benefit of incremental search was performance, and that is
less important than before. Incremental search required fewer random
bits and was able to amortize the checks for small primes across the
entire sequence. However, both random bit generation and primality
checks have gotten faster much quicker than typical primes have
gotten longer, so the benefits are not as important today.
Also, random prime generation is not typically on the critical path.
Negating any lingering concerns about performance, rejection sampling
no slower in practice than the incremental search, perhaps because
the incremental search was using a somewhat inefficient test to
eliminate multiples of small primes; ProbablyPrime does it better.
name old time/op new time/op delta
Prime/MathRand 69.3ms ±23% 68.0ms ±37% ~ (p=0.531 n=20+19)
Prime/CryptoRand 69.2ms ±27% 63.8ms ±36% ~ (p=0.076 n=20+20)
(Here, Prime/MathRand is the current Prime benchmark,
and Prime/CryptoRand is an adaptation to use crypto/rand.Reader
instead of math/rand's non-cryptographic randomness source,
just in case the quality of the bits affects the outcome.
If anything, rejection sampling is even better with cryptographically
random bits, but really the two are statistically indistinguishable
over 20 runs.)
3. Incremental search has a clear bias when generating small primes:
a prime is more likely to be returned the larger the gap between
it and the next smaller prime. Although the bias is negligible in
practice for cryptographically large primes, people can measure the
bias for smaller prime sizes, and we have received such reports
extrapolating the bias to larger sizes and claiming a security bug
(which, to be clear, does not exist).
However, given that rejection sampling is simpler, more clearly
correct and at least no slower than incremental search, the bias
is indefensible.
4. Incremental search has a timing leak. If you can tell the incremental
search ran 10 times, then you know that p is such that there are no
primes in the range [p-20, p). To be clear, there are other timing
leaks in our current primality testing, so there's no definitive
benefit to eliminating this one, but there's also no reason to keep
it around.
(See https://bugs.chromium.org/p/boringssl/issues/detail?id=238 for
all the work that would be needed to make RSA key generation
constant-time, which is definitely not something we have planned for
Go crypto.)
5. Rejection sampling moves from matching OpenSSL to matching BoringSSL.
As a general rule BoringSSL is the better role model.
(Everyone started out using incremental search; BoringSSL switched
to rejection sampling in 2019, as part of the constant-time work
linked above.)
Change-Id: Ie67e572a967c12d8728c752045c7e38f21804f8e
Reviewed-on: https://go-review.googlesource.com/c/go/+/387554
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Peter Weinberger <pjw@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
Type inference for types was always a "nice to have" feature.
Given the under-appreciated complexity of making it work in all
cases, and the fact that we don't have a good understanding of
how it might affect readability of generic code, require explicit
type arguments for generic types.
This matches the current implementation.
Change-Id: Ie7ff6293d3fbea92ddc54c46285a4cabece7fe01
Reviewed-on: https://go-review.googlesource.com/c/go/+/390577
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
When framesize <= objabi.StackSmall, 128B, the stacksplit prologue is:
MOVD 16(g), R16
MOVD SP, R17
CMP R16, R17
BLS morestack_label
The second instruction is not necessary, we can compare R16 with SP
directly, so the sequence becomes:
MOVD 16(g), R16
CMP R16, SP
BLS morestack_label
This CL removes this instruction.
Change-Id: I0567ac52e9be124880957271951e1186da203612
Reviewed-on: https://go-review.googlesource.com/c/go/+/379076
Trust: Eric Fang <eric.fang@arm.com>
Run-TryBot: Eric Fang <eric.fang@arm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Eric Fang <eric.fang@arm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Replace 24 spaces added in CL 389434 with 3 tabs,
so the new line is indented like other lines around it.
Updates #51419.
Change-Id: Ic3e50023a01f233c52dda53c36de2c461222d95c
Reviewed-on: https://go-review.googlesource.com/c/go/+/390674
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Adam Shannon <adamkshannon@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This should always be true, but use the HWCAP2 bit anyways.
Change-Id: Ib164cf05b4c9f0c509f41b7eb339ef32fb63e384
Reviewed-on: https://go-review.googlesource.com/c/go/+/389894
Trust: Paul Murphy <murp@ibm.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This patch allows to zerocopy using MultiReader.
This is done by MultiReader implementing WriterTo.
Each sub reader is copied using usual io copy helper and thus use
WriterTo or ReadFrom with reflection.
There is a special case for when a subreader is a MultiReader.
Instead of using copyBuffer which would call multiReader.WriteTo,
multiReader.writeToWithBuffer is used instead, the difference
is that the temporary copy buffer is passed along, saving
allocations for nested MultiReaders.
The workflow looks like this:
- multiReader.WriteTo (allocates 32k buffer)
- multiReader.writeToWithBuffer
- for each subReader:
- is instance of multiReader ?
- yes, call multiReader.writeToWithBuffer
- no, call copyBuffer(writer, currentReader, buffer)
- does currentReader implements WriterTo ?
- yes, use use currentReader.WriteTo
- no, does writer implement ReadFrom ?
- yes, use writer.ReadFrom
- no, copy using Read / Write with buffer
This can be improved by lazy allocating the 32k buffer.
For example a MultiReader of such types:
MultiReader(
bytes.Reader, // WriterTo-able
bytes.Reader, // WriterTo-able
bytes.Reader, // WriterTo-able
)
Doesn't need any allocation, all copy can be done using bytes.Reader's
internal data slice. However currently we still allocate a 32k buffer
for nothing.
This optimisation has been omitted for a future patch because of high
complexity costs for a non obvious performance cost (it needs a benchmark).
This patch at least is on par with the previous MultiReader.Read
workflow allocation wise.
Fixes#50842
Change-Id: Ib070c8f36337d9dd86090df8a703c5df97a773ae
GitHub-Last-Rev: 8ebe60ceac
GitHub-Pull-Request: golang/go#51502
Reviewed-on: https://go-review.googlesource.com/c/go/+/390215
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Trust: Daniel Martí <mvdan@mvdan.cc>
This change includes several smaller changes based on feedback
received so far.
These changes were reviewed at CL 385536. The only additional
change here is to the current date in the subtitle.
Change-Id: I653eb4a143e3b86c5357a2fd3b19168419c9f432
Reviewed-on: https://go-review.googlesource.com/c/go/+/390634
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
go/build is one of the packages that contributes the most towards
cmd/go's init cost, which adds up to any call to the tool.
One piece of low-hanging fruit is knownOS and knownArch,
maps which are filled via an init func from a space-separated list.
Using GODEBUG=inittrace=1, we can get three samples:
init go/build @0.36 ms, 0.024 ms clock, 6568 bytes, 74 allocs
init go/build @0.33 ms, 0.025 ms clock, 6888 bytes, 76 allocs
init go/build @0.36 ms, 0.025 ms clock, 6728 bytes, 75 allocs
After using a static map instead, we see an improvement:
init go/build @0.33 ms, 0.018 ms clock, 5096 bytes, 69 allocs
init go/build @0.36 ms, 0.021 ms clock, 5096 bytes, 69 allocs
init go/build @0.33 ms, 0.019 ms clock, 5096 bytes, 69 allocs
The speedup isn't huge, but it helps, and also reduces allocs.
One can also imagine that the compiler may get better with static,
read-only maps in the future, whereas the init func will likely always
have a linear cost and extra allocations.
Change-Id: I430212bad03d25358d2cc7b1eab4536ad88d05a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/390274
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Trust: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Inference for type instances has dependencies on type-checking order
that can lead to subtle bugs. As explained in #51527, disable it for
1.18.
Fixes#51527
Change-Id: I42795bad30ce53abecfc5a4914599ae5a2041a9e
Reviewed-on: https://go-review.googlesource.com/c/go/+/387934
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Due to instance de-duplication, we were failing to record some type
instances in types.Info.Instances. Fix this by moving the instance
recording out of the resolver.
Fixes#51494
Change-Id: Iddd8989307d95886eedb321efa4ab98cd2b3573a
Reviewed-on: https://go-review.googlesource.com/c/go/+/390041
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
In Checker.typInternal, the SelectorExpr case was the only case that
didn't either set or pass along the incoming def *Named type.
Handle this by passing it along to Checker.selector and report a
cycle if one is detected.
Fixes#51509.
Change-Id: I6c2d46835f225aeb4cb25fe0ae55f6180cef038b
Reviewed-on: https://go-review.googlesource.com/c/go/+/390314
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The comparable bit was handled incorrectly. This CL establishes
a clear invariant for a type set's terms and its comparable bit
and correctly uses the bit when computing term intersections.
Relevant changes:
- Introduce a new function intersectTermLists that does the
correct intersection computation.
Minor:
- Moved the comparable bit after terms in _TypeSet to make it
clearer that they belong together.
- Simplify and clarify _TypeSet.IsAll predicate.
- Remove the IsTypeSet predicate which was only used for error
reporting in union.go, and use the existing predicates instead.
- Rename/introduce local variables in computeInterfaceTypeSet
for consistency and to avoid confusion.
- Update some tests whose output has changed because the comparable
bit is now only set if we have have the set of all types.
For instance, for interface{comparable; int} the type set doesn't
set the comparable bit because the intersection of comparable and
int is just int; etc.
- Add many more comments to make the code clearer.
Fixes#51472.
Change-Id: I8a5661eb1693a41a17ce5f70d7e10774301f38ab
Reviewed-on: https://go-review.googlesource.com/c/go/+/390025
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Now that we always use types2 to validate user source code, we can
remove the constSet logic from typecheck for detecting duplicate
expression switch cases and duplicate map literal keys. This logic is
redundant with types2, and currently causes unified IR to report
inappropriate duplicate constant errors that only appear after type
substitution.
Updates #42758.
Change-Id: I51ee2c5106eec9abf40eba2480dc52603c68ba21
Reviewed-on: https://go-review.googlesource.com/c/go/+/390474
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This makes it easier to figure out where the crash is occurring.
Change-Id: Ie1f78a360367090dcd61c61b2a55c34f3e2ff2eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/390034
Trust: David Chase <drchase@google.com>
Reviewed-by: David Chase <drchase@google.com>
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Previous value used in the float32 roundtrip used float32(math.NaN())-1
which caused the quiet/signal bit to flip, which seemed to break the
test on MIPS platforms. Instead switch to using float32(math.NaN())+1,
which preserves the bit and makes the test happy.
Possibly related to #37455Fixes#51258
Change-Id: Ia85c649e89a5d02027c0ec197f0ff318aa819c19
Reviewed-on: https://go-review.googlesource.com/c/go/+/390214
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Trust: Roland Shoemaker <roland@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
The test case is already working with unified IR, so add it to make
sure we don't regress while finishing unified IR's support for
dictionaries.
Updates #51521.
Change-Id: Ib7c8bf9612d30cd552e8e631fd0d487dcb177f14
Reviewed-on: https://go-review.googlesource.com/c/go/+/390356
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
This CL changes unified IR to include itabs in its serialized
dictionary format.
Change-Id: I334c972dc1bc19293f955bb23cfb66844da7adec
Reviewed-on: https://go-review.googlesource.com/c/go/+/390355
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
None of the current generic type switch test cases exercise type
switches where the instantiated case is an interface type.
Change-Id: I9272fa61b8dde1fe1a3702d524d4f40253ef19b2
Reviewed-on: https://go-review.googlesource.com/c/go/+/390354
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
This CL switches unified IR to using ir.DynamicType for derived
types. This has an immediate effect of fixing compilation of generic
code that when fully stenciled results in statically invalid type
assertions. This does require updating typecheck to expect
ODYNAMICTYPE in type switches, but this is straightforward to
implement.
For now, we still statically resolve the runtime type (or itab)
pointer. However, a subsequent CL will allow reading these pointers
from the runtime dictionary.
Change-Id: I1666678fcc588bc9cb8b97871bd02b9059848e6d
Reviewed-on: https://go-review.googlesource.com/c/go/+/390336
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
A few of the tests were printing garbage to stderr,
since FlagSet's default Output is os.Stderr:
$ go test
flag provided but not defined: -x
invalid value "1" for flag -v: test error
Usage of test:
flag needs an argument: -b
Usage of test:
-b usage
PASS
ok flag 0.008s
Add the remaining SetOutput(io.Discard) method calls.
Note that TestUserDefinedFunc was a tricky one.
Even with the added SetOutput calls,
the last part of the test would still print usage text to stderr.
It took me a while to figure out the problem was copying FlagSet.
I've filed go.dev/issue/51507 to record this particular sharp edge,
and the test code now avoids making FlagSet copies to avoid the bug.
Change-Id: I323f24091b98386312aa72df3eb890af6625628d
Reviewed-on: https://go-review.googlesource.com/c/go/+/390234
Trust: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Before #46477, the Go generics proposal allowed `type T = U` where `U`
was an uninstantiated generic type. However, we decided not to allow
that, and go/types and types2 have already been updated to disallow
it. This CL just removes the analogous code from unified IR.
Change-Id: I0fe6d1754c96790b498c1d5185b948333646d7de
Reviewed-on: https://go-review.googlesource.com/c/go/+/390315
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
We shouldn't need to read in function bodies for new functions found
during inlining, but something is expecting them to still be read
in. We should fix that code to not depend on them being read in, but
in the mean time reading them in anyway is at least correct, albeit
less efficient in time and space.
Fixes#49536.
Updates #50552.
Change-Id: I949ef45e7be09406e5a8149e251d78e015aca5fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/390335
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Change-Id: I7dfae0fc91c2d70873ec7ec920be7c0a4888153a
Reviewed-on: https://go-review.googlesource.com/c/go/+/390175
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Trust: Daniel Martí <mvdan@mvdan.cc>
Use dup3(oldfd, newfd, O_CLOEXEC) to atomically duplicate the file
descriptor and mark is as close-on-exec instead of dup2 & fcntl.
The dup3 system call first appeared in OpenBSD 5.7.
Change-Id: Ic06c2c7089dcdbd931ee24e5e8c316879d81474e
Reviewed-on: https://go-review.googlesource.com/c/go/+/389974
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Improve the test coverage of encoding/xml package by adding
the test cases for the execution paths that were not covered before.
Since it reveals a couple of issues, fix them as well while we're at it.
As I used an `strings.EqualFold` instead of adding one more `strings.ToLower`,
our fix to `autoClose()` tends to run faster as well as a result.
name old time/op new time/op delta
HTMLAutoClose-8 5.93µs ± 2% 5.75µs ± 3% -3.16% (p=0.000 n=10+10)
name old alloc/op new alloc/op delta
HTMLAutoClose-8 2.60kB ± 0% 2.58kB ± 0% -0.46% (p=0.000 n=10+10)
name old allocs/op new allocs/op delta
HTMLAutoClose-8 72.0 ± 0% 67.0 ± 0% -6.94% (p=0.000 n=10+10)
The overall `encoding/xml` test coverage increase is `88.1% -> 89.9%`;
although it may look insignificant, this CL covers some important corner cases,
like `autoClose()` functionality (that was not tested at all).
Fixes#49635Fixes#49636
Change-Id: I50b2769896c197eb285672313b7148f4fe8bdb38
Reviewed-on: https://go-review.googlesource.com/c/go/+/364734
Trust: Bryan Mills <bcmills@google.com>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Trust: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gopher Robot <gobot@golang.org>
In a recent change CL 388654 a function was updated so it
no longer needed stack space, but the TEXT statement was
not updated to reflect that change. This corrects that problem.
Change-Id: I9e60cebddae620788b1097ab7b39c47b323d1f62
Reviewed-on: https://go-review.googlesource.com/c/go/+/389674
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Paul Murphy <murp@ibm.com>
For #51153
Change-Id: I4374c63498b62ba7a08f146eebd034cbd50623f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/389634
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
It's more trouble than it's worth. New code should be using x/sys/unix
anyhow.
Fixes#40564Fixes#51479
Change-Id: I1c0e13f494380c1565e98359f088af9f52790b79
Reviewed-on: https://go-review.googlesource.com/c/go/+/390020
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
An extra "go build" was happening, for the sake of -tags=testgo,
which would insert some extra behavior into ./internal/work.
Instead, reuse the test binary as cmd/go directly,
by calling the main func when a special env var is set.
We still duplicate the test binary into testBin,
because we need a "go" executable in that directory for $PATH.
Finally, the special behavior is instead inserted via TestMain.
The numbers below represent how long it takes to run zero tests,
measured via:
benchcmd GoTestNothing go test -run=-
That is, the time it takes to run the first test is reduced by half.
Note that these numbers are on a warm build cache,
so if the -tags=testgo build were to be done from scratch,
the speed-up would be significantly more noticeable.
name old time/op new time/op delta
GoTestNothing 830ms ± 2% 380ms ± 7% -54.23% (p=0.008 n=5+5)
name old user-time/op new user-time/op delta
GoTestNothing 1.64s ± 1% 0.82s ± 3% -50.24% (p=0.008 n=5+5)
name old sys-time/op new sys-time/op delta
GoTestNothing 306ms ± 7% 159ms ±28% -48.15% (p=0.008 n=5+5)
name old peak-RSS-bytes new peak-RSS-bytes delta
GoTestNothing 173MB ± 1% 147MB ± 1% -14.96% (p=0.008 n=5+5)
Change-Id: I1f8fc71269a7b45bc5b82b7228e13f56589d44c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/378294
Trust: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
This should be a bit faster and slicker than the very old ANSI X9.31,
which relied on the system time. Uses AES instead of ChaCha because it's
in the standard library.
Reference: https://blog.cr.yp.to/20170723-random.html
Reference: https://github.com/jedisct1/supercop/blob/master/crypto_rng/aes256/ref/rng.c
Change-Id: Ib7b37a83cca29f5d346355b7cb8cfe5250086b95
Reviewed-on: https://go-review.googlesource.com/c/go/+/375215
Trust: Jason Donenfeld <Jason@zx2c4.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
The X9.31 expander is now only used for plan9. Perhaps once upon a time
there was a use for abstraction, but the code is now covered in hacky
"fileName == urandomDevice" and "GOOS == plan9" checks, to the point
where the abstraction is much too leaky. Since plan9 is the only
platform that has a /dev/random without a /dev/urandom, we can simplify
both the generic urandom code and the plan9 X9.31 code by separating
them into different files, each focusing on doing one thing well.
Change-Id: I0ca43b748a0fbbd60f2ec7819688a540506d34df
Reviewed-on: https://go-review.googlesource.com/c/go/+/370580
Trust: Jason Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Otherwise, the behavior of 'go work use -r' (without arguments)
may be surprising.
Change-Id: I50cf1339591720ec5bd333146b89c9944ce420d5
Reviewed-on: https://go-review.googlesource.com/c/go/+/389855
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
On Linux, the minimum required kernel version for Go 1.18 was be changed
to 2.6.32, see #45964. The pipe2 syscall was added in 2.6.27.
All other platforms already provide the pipe2 syscall in the minimum
supported version:
- DragonFly BSD added it in version 4.2, see
https://www.dragonflybsd.org/release42/
- FreeBSD added it in version 10.0, see
https://www.freebsd.org/cgi/man.cgi?pipe(2)#end
- NetBSD added it in version 6.0, see
https://man.netbsd.org/pipe2.2#HISTORY
- OpenBSD added it in version 5.7, see
https://man.openbsd.org/pipe.2#HISTORY
- Illumos supports it since 2013, see
https://www.illumos.org/issues/3714
- Solaris supports it since 11.4
This also allows to remove setNonblock which was only used in the pipe
fallback path on these platforms.
Change-Id: I1f40d32fd3065d74e22af77b9ff2292b9cf66706
Reviewed-on: https://go-review.googlesource.com/c/go/+/389354
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The finalizer is called using reflectcall. When register ABI is
used, the finalizer's argument is passed in register(s). But the
frame size calculation does not include the spill slot. When the
argument actually spills, it may clobber the caller's stack frame.
This CL fixes it.
Change-Id: Ibcc7507c518ba65c1c5a7759e5cab0ae3fc7efce
Reviewed-on: https://go-review.googlesource.com/c/go/+/389574
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Both endians perform syscalls similarly. Only CR0S0 and R3 hold
the resultant status of a syscall. A random value may be stored into
the second return value (r2) result in some cases. Always set it to
zero.
Fixes#51192
Change-Id: Ida6a5692578d2cdadf3099af28478b3bc364f623
Reviewed-on: https://go-review.googlesource.com/c/go/+/385796
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Trust: Paul Murphy <murp@ibm.com>
CL 386017 added new API for encoding/binary package.
This file was accidentally not updated in the same CL.
Updates #50601
Change-Id: Iefeb596ba04b8c6576cf0fe42030f658a5848832
Reviewed-on: https://go-review.googlesource.com/c/go/+/389636
Trust: Joseph Tsai <joetsai@digital-static.net>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Also correct scope position for such variables.
Adjusted some comments.
Fixes#51437.
Change-Id: Ic49a1459469c8b2c7bc24fe546795f7d56c67cb4
Reviewed-on: https://go-review.googlesource.com/c/go/+/389594
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Robert Findley <rfindley@google.com>
The preferred form of nop is ori 0,0,0. What was being generated was
or 0,0,0.
Fix a quirk in the assembler which effectively treats OR $0,Rx,Ry as
OR R0,Rx,Ry, and update the compiler to generate the preferred form.
Change-Id: I5ac4bf0258cff05b9eba516a767daebfc9e31bc7
Reviewed-on: https://go-review.googlesource.com/c/go/+/388974
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Paul Murphy <murp@ibm.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Workaround the minor endian differences, and avoid needing to
stack a frame as extra VSRs can be used in a similar capacity.
The microbenchmarks show no significant differences on ppc64le/p9.
ppc64/linux performance difference on a POWER9:
name old time/op new time/op delta
Hash8Bytes 686ns ± 0% 372ns ± 0% -45.78%
Hash1K 9.17µs ± 0% 4.24µs ± 0% -53.74%
Hash8K 67.9µs ± 0% 31.7µs ± 0% -53.35%
Fixes#50785
Change-Id: I43d87670127df9767d54d10b5165b84e5b88f5d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/380776
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Trust: Paul Murphy <murp@ibm.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The existing codegen strategy in sort.go relied on parsing the sort.go source
with go/ast and a combination of an AST rewrite + code text rewrite with regexes
to generate zfuncversion -- the same sort functionality with a different variant
of data.
In preparation for implementing #47619, we need a more robust codegen
strategy. To generate variants required for the generic sort functions
in the slices package, we'd need significanly more complicated AST
rewrites, which would make genzfunc.go much heavier.
Instead, redo the codegen strategy to use text/template instead of AST rewrites.
gen_sort_variants.go now contains the code for the underlying sort functions,
and generates multiple versions of them based on Variant configuration structs.
With this approach, adding new variants to generate generic sort functions for
the slices package becomes trivial.
See the discussion in #47619 for more details on the design decisions.
Change-Id: I8af784c41b1dc8ef92aaf6321359e8faa5fe106c
Reviewed-on: https://go-review.googlesource.com/c/go/+/353069
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Trust: Than McIntosh <thanm@google.com>
