Change-Id: Ib936539946f43556a7dd501f8127054f6a27861f
Reviewed-on: https://go-review.googlesource.com/33553Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: Ia27ca728bafcf20d001b477787b21d16ae12960d
Reviewed-on: https://go-review.googlesource.com/33552Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

When transitioning from C code to Go code we must respect the C
calling convention. On s390x this means that r6-r13, r15 and f8-f15
must be saved and restored by functions that use them.

On s390x we were saving the wrong set of floating point registers
(f0, f2, f4 and f6) rather than f8-f15 which means that Go code
could clobber registers that C code expects to be restored. This
CL modifies the crosscall functions on s390x to save/restore the
correct floating point registers.

Fixes #18035.

Change-Id: I5cc6f552c893a4e677669c8891521bf735492e97
Reviewed-on: https://go-review.googlesource.com/33571Reviewed-by: Ian Lance Taylor <iant@golang.org>

It was supposed to be testing SSA, not amd64.

For #18024

Change-Id: Ibe65d7eb6bed9bc4b3eda68e1eaec5fa39fe8f76
Reviewed-on: https://go-review.googlesource.com/33491Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>

There is some code value too: types intending to implement
Source64 can write a conversion confirming that.

For #4254 and the Go 1.8 release notes.

Change-Id: I7fc350a84f3a963e4dab317ad228fa340dda5c66
Reviewed-on: https://go-review.googlesource.com/33456
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

TBR=See https://golang.org/cl/33244 and review there.

Updates #17929

Change-Id: I752ec7a6d086f370feaf3cf282708620e891079b
Reviewed-on: https://go-review.googlesource.com/33478Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Fixes #18026

Change-Id: Id510f427ceffb2441c3d6f5bb5c93244e46c6497
Reviewed-on: https://go-review.googlesource.com/33477
TryBot-Result: Gobot Gobot <gobot@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>

CL 32796 changes the SIGPIPE behaviour for c-archive and c-shared
programs. Add it to go1.8.txt.

Change-Id: I31200187033349c642965a4bb077bcc77d5329a3
Reviewed-on: https://go-review.googlesource.com/33397Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Sigh, forgot to run `git mail`.

Change-Id: Idc49be2bb20d6f0e392cb472a63267ffee2ca22c
Reviewed-on: https://go-review.googlesource.com/33476Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>

Update #9401.
Fixes #18016.

Change-Id: Icc24dd10dab1ad8e5cf295e0727d437afa5025c0
Reviewed-on: https://go-review.googlesource.com/33475
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

TestPendingConnsAfterErr showed a failure on slower systems.
Wait and check for the database to close all connections
before pronouncing failure.

A more careful method was attempted but the connection pool
behavior is too dependent on the scheduler behavior to be
predictable.

Fixes #15684

Change-Id: Iafdbc90ba51170c76a079db04c3d5452047433a4
Reviewed-on: https://go-review.googlesource.com/33418Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Change-Id: I51180e1c685e488f7ea4c51a63fd035148671b05
Reviewed-on: https://go-review.googlesource.com/33470Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

TBR=See https://golang.org/cl/33244 and review there.

Updates #17929

Change-Id: I7cb0b666469dba35426d1f0ae1b185e0bdfeac05
Reviewed-on: https://go-review.googlesource.com/33474Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

This changes makes the output of `go env` the same
as on other operating systems.

Fixes #18013.

Change-Id: I3079e14dcf7b30c75ec3fde6c78cb95721111320
Reviewed-on: https://go-review.googlesource.com/33396Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Applies the fix from CL 32920 to the new test TestSampledHeapAllocProfile
introduced in CL 33422. The test should be skipped rather than fail if
there is only one executable region of memory.

Updates #17852.

Change-Id: Id8c47b1f17ead14f02a58a024c9a04ebb8ec0429
Reviewed-on: https://go-review.googlesource.com/33453
Run-TryBot: Michael Munday <munday@ca.ibm.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

The expected default behavior (no explicit GOTRACEBACK setting)
is for the stack trace to start in user code, eliding unnecessary runtime
frames that led up to the actual trace printing code. The idea was that
the first line number printed was the one that crashed.

For #5832 we added code to show 'panic' frames so that if code panics
and then starts running defers and then we trace from there, the panic
frame can help explain why the code seems to have made a call not
present in the code. But that's only needed for panics between two different
call frames, not the panic at the very top of the stack trace.
Fix the fix to again elide the runtime code at the very top of the stack trace.

Simple panic:

	package main

	func main() {
		var x []int
		println(x[1])
	}

Before this CL:

	panic: runtime error: index out of range

	goroutine 1 [running]:
	panic(0x1056980, 0x1091bf0)
		/Users/rsc/go/src/runtime/panic.go:531 +0x1cf
	main.main()
		/tmp/x.go:5 +0x5

After this CL:

	panic: runtime error: index out of range

	goroutine 1 [running]:
	main.main()
		/tmp/x.go:5 +0x5

Panic inside defer triggered by panic:

	package main

	func main() {
		var x []int
		defer func() {
			println(x[1])
		}()
		println(x[2])
	}

Before this CL:

	panic: runtime error: index out of range
		panic: runtime error: index out of range

	goroutine 1 [running]:
	panic(0x1056aa0, 0x1091bf0)
		/Users/rsc/go/src/runtime/panic.go:531 +0x1cf
	main.main.func1(0x0, 0x0, 0x0)
		/tmp/y.go:6 +0x62
	panic(0x1056aa0, 0x1091bf0)
		/Users/rsc/go/src/runtime/panic.go:489 +0x2cf
	main.main()
		/tmp/y.go:8 +0x59

The middle panic is important: it explains why main.main ended up calling main.main.func1 on a line that looks like a call to println. The top panic is noise.

After this CL:

	panic: runtime error: index out of range
		panic: runtime error: index out of range

	goroutine 1 [running]:
	main.main.func1(0x0, 0x0, 0x0)
		/tmp/y.go:6 +0x62
	panic(0x1056ac0, 0x1091bf0)
		/Users/rsc/go/src/runtime/panic.go:489 +0x2cf
	main.main()
		/tmp/y.go:8 +0x59

Fixes #17901.

Change-Id: Id6d7c76373f7a658a537a39ca32b7dc23e1e76aa
Reviewed-on: https://go-review.googlesource.com/33165
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

TBR=See https://golang.org/cl/33244 and review there.

Updates #17929

Change-Id: I37b49318a9203b16c0c788926039288b99a36ce5
Reviewed-on: https://go-review.googlesource.com/33450Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

When debug is 0, emit the compressed proto format.
The debug>0 format stays the same.

Updates #16093

Change-Id: I45aa1874a22d34cf44dd4aa78bbff9302381cb34
Reviewed-on: https://go-review.googlesource.com/33422
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Updates #17929

Change-Id: Ibc711d39d9ff83458d213778117493796b678aa7
Reviewed-on: https://go-review.googlesource.com/33437Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Updates #17929

Change-Id: Ie90736cfce3fc5f23cbe0a0f1971476705aac5f9
Reviewed-on: https://go-review.googlesource.com/33436Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Day 0 is as invalid as day 32.

Fixes #17874

Change-Id: I52109d12bafd6d957d00c44d540cb88389fff0a7
Reviewed-on: https://go-review.googlesource.com/33429
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

When I added t.Parallel to some tests earlier, I overlooked some using
the global "Get" func, which uses DefaultTransport.

The DefaultTransport can have its CloseIdleConnections called by other
parallel tests. Use a private Transport instead.

Fixes #18006

Change-Id: Ia4faca5bac235cfa95dcf2703c25f3627112a5e9
Reviewed-on: https://go-review.googlesource.com/33432
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

When we raise a signal that was delivered to C code, it's possible that
the kernel will not deliver it immediately. This is especially possible
on Darwin where we use send the signal to the entire process rather than
just the current thread. Sleep for a millisecond after sending the
signal to give it a chance to be delivered before we restore the Go
signal handler. In most real cases the program is going to crash at this
point, so sleeping is kind of irrelevant anyhow.

Fixes #14809.

Change-Id: Ib2c0d2c4e240977fb4535dc1dd2bdc50d430eb85
Reviewed-on: https://go-review.googlesource.com/33300
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

When CC is set in the environment, the mkEnv function sets its version
of CC to the first word $CC and sets GOGCCFLAGS to the remainder. That
worked since Go 1 but was broken accidentally by
https://golang.org/cl/6409, which changed the code such that `go env`
calls mkEnv twice. The second call to mkEnv would clobber GOGCCFLAGS
based on the value of CC set by the first call. Go back to the old
handling by only calling mkEnv once.

Fixes #15457.

Change-Id: I000a1ebcc48684667e48f2b9b24605867b9e06cd
Reviewed-on: https://go-review.googlesource.com/33293Reviewed-by: Russ Cox <rsc@golang.org>

Introduce R_WEAKADDROFF, a "weak" variation of the R_ADDROFF relocation
that will only reference the type described if it is in some other way
reachable.

Use this for the ptrToThis field in reflect type information where it
is safe to do so (that is, types that don't need to be included for
interface satisfaction, and types that won't cause the compiler to
recursively generate an endless series of ptr-to-ptr-to-ptr-to...
types).

Also fix a small bug in reflect, where StructOf was not clearing the
ptrToThis field of new types.

Fixes #17931

Change-Id: I4d3b53cb9c916c97b3b16e367794eee142247281
Reviewed-on: https://go-review.googlesource.com/33427
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

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/33430Reviewed-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>

This check was originally implemented by Vladimir in
https://go-review.googlesource.com/c/31489/1/src/runtime/internal/atomic/atomic_mipsx.go#30
but removed due to my comment (Sorry!). This CL adds it back.

Fixes #17786.

Change-Id: I7ff4c2539fc9e2afd8199964b587a8ccf093b896
Reviewed-on: https://go-review.googlesource.com/33431
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Updates #17937

Change-Id: Ic822da1786a983b3b7bca21b68c3d5fc4bdfaee2
Reviewed-on: https://go-review.googlesource.com/33428
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@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>

Fixes #17743.

Change-Id: Ib5afb6248bb060f2ad8dd3d5f78e95271af62a57
Reviewed-on: https://go-review.googlesource.com/33135
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Quentin Smith <quentin@golang.org>
Reviewed-by: Caleb Spare <cespare@gmail.com>

Change-Id: If754de6c44cf0ec4192101432e4065cc7a28e862
Reviewed-on: https://go-review.googlesource.com/33425Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>

Updates #18008

Change-Id: I8fde0d71d15b416db4d262f6db8ef32a209a192f
Reviewed-on: https://go-review.googlesource.com/33426Reviewed-by: 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>

Should fix flakes like:

https://build.golang.org/log/c8da331317064227f38d5ef57ed7dba563ba1b38

--- FAIL: TestClientTimeout_h1 (0.35s)
    client_test.go:1263: timeout after 200ms waiting for timeout of 100ms
FAIL

Change-Id: I0a4dba607524e8d7a00f498e27d9598acde5d222
Reviewed-on: https://go-review.googlesource.com/33420
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>

Make atomic access on 32-bit architectures happy.

Updates #17786.

Change-Id: I42de63ff1381af42124dc51befc887160f71797d
Reviewed-on: https://go-review.googlesource.com/33235
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Austin Clements <austin@google.com>

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>