See issues for details. We can expand this test during the Go 1.9
cycle.
Updates #18008
Change-Id: I78b6b7e8dede414769be97898e29f969bc2a9651
Reviewed-on: https://go-review.googlesource.com/33430
Reviewed-by: Cherry Zhang <cherryyz@google.com>
After x.ProbablyPrime(n) passes the n Miller-Rabin rounds,
add a Baillie-PSW test before declaring x probably prime.
Although the provable error bounds are unchanged, the empirical
error bounds drop dramatically: there are no known inputs
for which Baillie-PSW gives the wrong answer. For example,
before this CL, big.NewInt(443*1327).ProbablyPrime(1) == true.
Now it is (correctly) false.
The new Baillie-PSW test is two pieces: an added Miller-Rabin
round with base 2, and a so-called extra strong Lucas test.
(See the references listed in prime.go for more details.)
The Lucas test takes about 3.5x as long as the Miller-Rabin round,
which is close to theoretical expectations.
name time/op
ProbablyPrime/Lucas 2.91ms ± 2%
ProbablyPrime/MillerRabinBase2 850µs ± 1%
ProbablyPrime/n=0 3.75ms ± 3%
The speed of prime testing for a prime input does get slower:
name old time/op new time/op delta
ProbablyPrime/n=1 849µs ± 1% 4521µs ± 1% +432.31% (p=0.000 n=10+9)
ProbablyPrime/n=5 4.31ms ± 3% 7.87ms ± 1% +82.70% (p=0.000 n=10+10)
ProbablyPrime/n=10 8.52ms ± 3% 12.28ms ± 1% +44.11% (p=0.000 n=10+10)
ProbablyPrime/n=20 16.9ms ± 2% 21.4ms ± 2% +26.35% (p=0.000 n=9+10)
However, because the Baillie-PSW test is only added when the old
ProbablyPrime(n) would return true, testing composites runs at
the same speed as before, except in the case where the result
would have been incorrect and is now correct.
In particular, the most important use of this code is for
generating random primes in crypto/rand. That use spends
essentially all its time testing composites, so it is not
slowed down by the new Baillie-PSW check:
name old time/op new time/op delta
Prime 104ms ±22% 111ms ±16% ~ (p=0.165 n=10+10)
Thanks to Serhat Şevki Dinçer for CL 20170, which this CL builds on.
Fixes#13229.
Change-Id: Id26dde9b012c7637c85f2e96355d029b6382812a
Reviewed-on: https://go-review.googlesource.com/30770
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
In Plan 9's shell,
GOBIN= \
foo bar
is the same as
GOBIN=foo bar
Write what was meant, which is
GOBIN=() \
foo bar
Fixes#17737.
Change-Id: Ie5a1b51a7cec950b5e78bbbe99cbc3cfe102f980
Reviewed-on: https://go-review.googlesource.com/33144
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Quentin Smith <quentin@golang.org>
Reviewed-by: David du Colombier <0intro@gmail.com>
Change-Id: If754de6c44cf0ec4192101432e4065cc7a28e862
Reviewed-on: https://go-review.googlesource.com/33425
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
The gccgo compiler does not have the standard packages available, so it
can not check for violations of internal references.
Also, the gccgo compiler can not read runtime/internal/sys/zversion.go;
in fact, the file does not even exist for gccgo.
Change-Id: Ibadf16b371621ad1b87b6e858c5eb233913e179d
Reviewed-on: https://go-review.googlesource.com/33295
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
We recently added these large zip64 tests. They're slow-ish already,
but fast enough in non-race mode with t.Parallel. But in race mode,
the concurrency makes them much slower than the normal
non-race-to-race multiplier.
They're taking so long now that it's causing test failures when it
sometimes is over the test timeout threshold.
Change-Id: I02f4ceaa9d6cab826708eb3860f47a57b05bdfee
Reviewed-on: https://go-review.googlesource.com/33423
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Updates #17786. Will fix mips(32) when the port is fully landed.
Change-Id: I00d4ff666ec14a38cadbcd52569b347bb5bc8b75
Reviewed-on: https://go-review.googlesource.com/33236
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
count profiles with debug=1 retain their previous format.
Also add a test check for the proto profiles since all runtime/pprof
tests only look at the debug=1 profiles.
Change-Id: Ibe805585b597e5d3570807115940a1dc4535c03f
Reviewed-on: https://go-review.googlesource.com/33148
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
If the scheduler has no user work and there's no GC work visible, it
puts the P to sleep (or blocks on the network). However, if we later
enqueue more GC work, there's currently nothing that specifically
wakes up the scheduler to let it start an idle GC worker. As a result,
we can underutilize the CPU during GC if Ps have been put to sleep.
Fix this by making GC wake idle Ps when work buffers are put on the
full list. We already have a hook to do this, since we use this to
preempt a random P if we need more dedicated workers. We expand this
hook to instead wake an idle P if there is one. The logic we use for
this is identical to the logic used to wake an idle P when we ready a
goroutine.
To make this really sound, we also fix the scheduler to re-check the
idle GC worker condition after releasing its P. This closes a race
where 1) the scheduler checks for idle work and finds none, 2) new
work is enqueued but there are no idle Ps so none are woken, and 3)
the scheduler releases its P.
There is one subtlety here. Currently we call enlistWorker directly
from putfull, but the gcWork is in an inconsistent state in the places
that call putfull. This isn't a problem right now because nothing that
enlistWorker does touches the gcWork, but with the added call to
wakep, it's possible to get a recursive call into the gcWork
(specifically, while write barriers are disallowed, this can do an
allocation, which can dispose a gcWork, which can put a workbuf). To
handle this, we lift the enlistWorker calls up a layer and delay them
until the gcWork is in a consistent state.
Fixes#14179.
Change-Id: Ia2467a52e54c9688c3c1752e1fc00f5b37bbfeeb
Reviewed-on: https://go-review.googlesource.com/32434
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Idle GC workers trigger whenever there's a GC running and the
scheduler doesn't find any other work. However, they currently run for
a full scheduler quantum (~10ms) once started.
This is really bad for event-driven applications, where work may come
in on the network hundreds of times during that window. In the
go-gcbench rpc benchmark, this is bad enough to often cause effective
STWs where all Ps are in the idle worker. When this happens, we don't
even poll the network any more (except for the background 10ms poll in
sysmon), so we don't even know there's more work to do.
Fix this by making idle workers check with the scheduler roughly every
100 µs to see if there's any higher-priority work the P should be
doing. This check includes polling the network for incoming work.
Fixes#16528.
Change-Id: I6f62ebf6d36a92368da9891bafbbfd609b9bd003
Reviewed-on: https://go-review.googlesource.com/32433
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Use an explicit ./ to make sure we link against the libgo.so we just
built, not some other libgo.so that the compiler or linker may decide to
seek out.
Fixes#17986.
Change-Id: Id23f6c95aa2b52f4f42c1b6dac45482c22b4290d
Reviewed-on: https://go-review.googlesource.com/33413
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Also: handle version "v2" of export data format.
Fixes#17981.
Change-Id: I8042ce18c4a27c70cc1ede675daca019b047bcf3
Reviewed-on: https://go-review.googlesource.com/33412
Reviewed-by: Ian Lance Taylor <iant@golang.org>
So we can merge cover profiles from multiple runs.
Change-Id: I1bf921e2b02063a2a62b35d21a6823062d10e5d0
Reviewed-on: https://go-review.googlesource.com/23831
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
This matches what we already do for switch statements and makes
this large section more visibly organized. No other changes besides
introducing the titles.
Fixes#4486.
Change-Id: I73f274e4fdd27c6cfeaed79090b4553e57a9c479
Reviewed-on: https://go-review.googlesource.com/33410
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Currently, trace processing interleaves state/statistics updates and
emitting trace viewer objects. As a result, if events are being
filtered, either by time or by goroutines, we'll miss those
state/statistics updates. At best, this leads to bad statistics;
however, since we're now strictly checking G state transitions, it
usually leads to a failure to process the trace if there is any
filtering.
Fix this by separating state updates from emitting trace object. State
updates are done before filtering, so we always have correct state
information and statistics. Trace objects are only emitted if we pass
the filter. To determine when we need to emit trace counters, rather
than duplicating the knowledge of which events might modify
statistics, we keep track of the previously emitted counters and emit
a trace counter object whenever these have changed.
Fixes#17719.
Change-Id: Ic66e3ddaef60d1acaaf2ff4c62baa5352799cf99
Reviewed-on: https://go-review.googlesource.com/32810
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
- organize examples better
- add an example illustrating behavior if element type is a named pointer type
- both compilers and go/types (per https://go-review.googlesource.com/33358)
follow this now
See the issue for detailed discussion.
Fixes#17954.
Change-Id: I8d90507ff2347d9493813f75b73233819880d2b4
Reviewed-on: https://go-review.googlesource.com/33361
Reviewed-by: Rob Pike <r@golang.org>
The table of rewrites in ssa/cse is not sized appropriately for
ssa IDs that are created during copying of selects into new blocks.
Fixes#17918
Change-Id: I65fe86c6aab5efa679aa473aadc4ee6ea882cd41
Reviewed-on: https://go-review.googlesource.com/33240
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The existing implementation of text/template handles the option
"missingkey=error" in an inconsitent manner: If the provided data is
a nil-interface, no error is returned (despite the fact that no key
can be found in it).
This patch makes text/template return an error if "missingkey=error"
is set and the provided data is a not a valid reflect.Value.
Fixes#15356
Change-Id: Ia0a83da48652ecfaf31f18bdbd78cb21dbca1164
Reviewed-on: https://go-review.googlesource.com/31638
Reviewed-by: Rob Pike <r@golang.org>
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Before this CL, Go programs in c-archive or c-shared buildmodes
would not handle SIGPIPE. That leads to surprising behaviour where
writes on a closed pipe or socket would raise SIGPIPE and terminate
the program. This CL changes the Go runtime to handle
SIGPIPE regardless of buildmode. In addition, SIGPIPE from non-Go
code is forwarded.
Fixes#17393
Updates #16760
Change-Id: I155e82020a03a5cdc627a147c27da395662c3fe8
Reviewed-on: https://go-review.googlesource.com/32796
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Match behavior of gc and gccgo.
For #17954.
Change-Id: I3f065e56d0a623bd7642c1438d0cab94d23fa2ae
Reviewed-on: https://go-review.googlesource.com/33358
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The SignedCertificateTimestampList[1] specifies that both the list and
each element must not be empty. Checking that the list is not empty was
handled in [2] and this change checks that the SCTs themselves are not
zero-length.
[1] https://tools.ietf.org/html/rfc6962#section-3.3
[2] https://golang.org/cl/33265
Change-Id: Iabaae7a15f6d111eb079e5086e0bd2005fae9e48
Reviewed-on: https://go-review.googlesource.com/33355
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
When the CT extension is enabled but no SCTs are present, the existing
code calls "continue" which causes resizing the data byte slice to be
skipped. In fact, such extensions should be rejected.
Fixes#17958
Change-Id: Iad12da10d1ea72d04ae2e1012c28bb2636f06bcd
Reviewed-on: https://go-review.googlesource.com/33265
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Currently there are no diagnostics for mark root check during marking.
Fix this by printing out the same diagnostics we print during mark
termination.
Also, drop the allglock before throwing. Holding that across a throw
causes a self-deadlock with tracebackothers.
For #16083.
Change-Id: Ib605f3ae0c17e70704b31d8378274cfaa2307dc2
Reviewed-on: https://go-review.googlesource.com/33339
Reviewed-by: Rick Hudson <rlh@golang.org>
The top-level qualifiers are unimportant for our purposes. If a C
function is defined as `const int f(const int i)`, the `const`s are
meaningless to C, and we want to avoid using them in the struct we
create where the `const` has a completely different meaning.
This unwinds https://golang.org/cl/33097 with regard to top-level
qualifiers.
Change-Id: I3d66b0eb43b6d9a586d9cdedfae5a2306b46d96c
Reviewed-on: https://go-review.googlesource.com/33325
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Previously driver.Stmt could could be closed multiple times in
edge cases that drivers may not test for initially. Make their
job easier by ensuring the driver is only closed a single time.
Fixes#16019
Change-Id: I1e4777ef70697a849602e6ef9da73054a8feb4cd
Reviewed-on: https://go-review.googlesource.com/33352
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Not sure what I was thinking.
Change-Id: I143cdf7c5ef8e7b2394afeca6b30c46bb2c19a55
Reviewed-on: https://go-review.googlesource.com/33340
Reviewed-by: Ian Lance Taylor <iant@golang.org>
CL 33239 changed the polling loops from using sched_yield to a sleep
for 1/1000 of a second. The loop counters were not updated, so failing
tests now take 100 seconds to complete. Lower the loop counts to 5
seconds instead.
Change-Id: I7c9a343dacc8188603ecf7e58bd00b535cfc87f5
Reviewed-on: https://go-review.googlesource.com/33280
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
https://github.com/tpn/pdfs/raw/master/Microsoft Portable Executable and Common Object File Format Specification - 1999 (pecoff).doc
says this about PointerToSymbolTable:
File offset of the COFF symbol table or 0 if none is present.
Do as it says.
Fixes#17809.
Change-Id: Ib1ad83532f36a3e56c7e058dc9b2acfbf60c4e72
Reviewed-on: https://go-review.googlesource.com/33170
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
TestReadStdin always fill up buffer provided by ReadFile caller full.
But we do not know if real ReadFile does the same. Add tests where
buffer is only filled with limited data.
Change-Id: I0fc776325c2b1fe60511126c439f4b0560e9d653
Reviewed-on: https://go-review.googlesource.com/33030
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
CIDRMask just returns a mask which corresponds to an address
prefix in CIDR nonation. A subnet for an IPv6 mask sounds a bit
confusing.
Change-Id: Ic7859ce992bc2de4043d3b25caf9a1051d118b0e
Reviewed-on: https://go-review.googlesource.com/33262
Reviewed-by: Ian Lance Taylor <iant@golang.org>
If a program has had its text section split into multiple
sections then the ftab that is built is based on addresses
prior to splitting. That means all the function addresses
are there and correct because of relocation but the
but the computed idx won't always match up quite right and
in some cases go beyond the end of the table, causing a panic.
To resolve this, determine if the idx is too large and if it is,
set it to the last index in ftab. Then search backward to find the
matching function address.
Fixes#17854
Change-Id: I6940e76a5238727b0a9ac23dc80000996db2579a
Reviewed-on: https://go-review.googlesource.com/32972
Reviewed-by: David Chase <drchase@google.com>
It's possible for the pkgPath of a field to be different than that of
the struct type as a whole. In that case, store the field's pkgPath in
the name field. Use the field's pkgPath when setting PkgPath and when
checking for type identity.
Fixes#17952.
Change-Id: Iebaf92f0054b11427c8f6e4158c3bebcfff06f45
Reviewed-on: https://go-review.googlesource.com/33333
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Failing to create the output file would give confusing errors such as:
cover: invalid argument
Also do out.Close() even if Execute() errored.
Fixes#17951.
Change-Id: I897e1d31f7996871c54fde7cb09614cafbf6c3fc
Reviewed-on: https://go-review.googlesource.com/33278
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
The previous documentation purported to convert underlying strings to
[]byte, which it did not do. This adds support for underlying bool,
string, and []byte, which convert directly to their underlying type.
Fixes#15174.
Change-Id: I7fc4e2520577f097a48f39c9ff6c8160fdfb7be4
Reviewed-on: https://go-review.googlesource.com/27812
Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
