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

Use of the alternate signal stack on darwin/{arm,arm64} is reportedly
buggy, and the runtime function sigaltstack does nothing.  So don't
check the sigaltstack result to decide how to handle the signal stack.

Fixes #14070.

Change-Id: Ie97ede8895fad721e3acc79225f2cafcbe1f3a81
Reviewed-on: https://go-review.googlesource.com/18940
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>

Fixes #14084

Change-Id: Icbef5678ab3c4fd7eed2693006c47aca6d831d90
Reviewed-on: https://go-review.googlesource.com/18873Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Also don't nil out the Request or Response Body on error. Just leave
it in its previous broken state. The docs now say it's undefined, but
it always was.

Fixes #14036

Change-Id: I7fe175a36cbc01b4158f4dffacd8733b2ffa9999
Reviewed-on: https://go-review.googlesource.com/18726Reviewed-by: Rob Pike <r@golang.org>

Updates x/net/http2 to git rev 2e9cee70 for https://golang.org/cl/18801

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

When using c-archive/c-shared, the signal handler for SIGPROF will not
be installed, which means that runtime/pprof.StartCPUProfile won't work.
There is no really good solution here, as the main program may want to
do its own profiling.  For now, just document that runtime/pprof doesn't
work as expected, but that it will work if you use Notify to install the
Go signal handler.

Fixes #14043.

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

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

Thanks to Régis Leroy for noticing.

Change-Id: I5ca2402efddab4e63d884a9d315fc1394e514cb7
Reviewed-on: https://go-review.googlesource.com/18871Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

On NetBSD and DragonFly a newly created thread inherits the signal stack
of the creating thread.  That means that in a cgo program a C thread
created using pthread_create will get the signal stack of the creating
thread, most likely a Go thread.  This will then lead to chaos if two
signals occur simultaneously.

We can't fix the general case.  But we can fix the case of a C thread
that calls a Go function, by installing a new signal stack and then
dropping it when we return to C.  That will break the case of a C thread
that calls sigaltstack and then calls Go, because we will drop the C
thread's alternate signal stack as we return from Go.  Still, this is
the 1.5 behavior.  And what else can we do?

Fixes #14051.
Fixes #14052.
Fixes #14067.

Change-Id: Iee286ca50b50ec712a4d929c7121c35e2383a7b9
Reviewed-on: https://go-review.googlesource.com/18835Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
Reviewed-by: Russ Cox <rsc@golang.org>

Pass -c to generate an object.  Pass GOPKGPATH as a symbol, not a
string.  Pass -xassembler-with-cpp so that the preprocessor is run.

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

Add test for assembly errors, to verify fix.
Make sure invalid instruction errors are printed just once
(was printing them once per span iteration, so typically twice).

Fixes #13282.

Change-Id: Id5f66f80a80b3bc4832e00084b0a91f1afec7f8f
Reviewed-on: https://go-review.googlesource.com/18858Reviewed-by: Rob Pike <r@golang.org>

Apparently the darwin/386 builder does not enable cgo.
This failure turned up running

	GOARCH=386 GOHOSTARCH=386 ./all.bash

on my Mac.

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

Fixes #13757.

Change-Id: I1b52593df8df0e98ce7342767eb34eccecc11761
Reviewed-on: https://go-review.googlesource.com/18854
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Requested off-list.
Trivial to add and more importantly trivial to test.

ANDNL
ANDNQ
BEXTRL
BEXTRQ
BZHIL
BZHIQ
MULXL
MULXQ
PDEPL
PDEPQ
PEXTL
PEXTQ
SARXL
SARXQ
SHRXL
SHRXQ

Change-Id: I3d46a0f653b81dd003ff6d2a394d8ce96a573b63
Reviewed-on: https://go-review.googlesource.com/18857Reviewed-by: Rob Pike <r@golang.org>

Add amd64 instructions I promised to add for Go 1.6
at the beginning of January.

These may be the last instructions added by hand.
I intend to generate the whole set mechanically for Go 1.7.

Fixes #13822.

Change-Id: I8c6bae2efd25f717f9ec750402e50f408a911d2b
Reviewed-on: https://go-review.googlesource.com/18853Reviewed-by: Rob Pike <r@golang.org>

Use the standard names, for discoverability.
Use the standard register arguments, for correctness.
Implement all possible arguments, for completeness.
Enable the corresponding tests now that everything is standard.
Update the uses in package runtime.

Fixes #14068.

Change-Id: I8e1af9a41e7d02d98c2a82af3d4cdb3e9204824f
Reviewed-on: https://go-review.googlesource.com/18852
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

Fixes #4816.

Change-Id: Ibeaa69f57b7519d56df4ea357edf8d9dc2102ffe
Reviewed-on: https://go-review.googlesource.com/18851Reviewed-by: Rob Pike <r@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Generated by x86test, from https://golang.org/cl/18842
(still in progress).

The commented out lines are either missing or misspelled
or incorrectly handled instructions.

For #4816, #8037, #13822, #14068, #14069.

Change-Id: If309310c97d9d2a3c71fc64c51d4a957e9076ab7
Reviewed-on: https://go-review.googlesource.com/18850Reviewed-by: Rob Pike <r@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Not much testing yet, but the test now exists.

Another step toward #13822.

Change-Id: Idb2b06bf53a6113c83008150b4c0b631bb195279
Reviewed-on: https://go-review.googlesource.com/18844Reviewed-by: Rob Pike <r@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>

Tests for this and many other instructions are in a separate followup CL.

For #14068.

Change-Id: I6955315996a34d7fb79369b9d9a0119d11745e85
Reviewed-on: https://go-review.googlesource.com/18849Reviewed-by: Rob Pike <r@golang.org>

Ilya added POPCNT in a CL earlier this month but it's really only POPCNTQ.
The other forms still need to be added.

For #4816.

Change-Id: I1186850d32ad6d5777475c7808e6fc9d9133e118
Reviewed-on: https://go-review.googlesource.com/18848Reviewed-by: Rob Pike <r@golang.org>

Change-Id: I5b749c575e0ec78fb3c50d056899bd1fe5d91853
Reviewed-on: https://go-review.googlesource.com/18847Reviewed-by: Rob Pike <r@golang.org>

Not recognized in any instructions yet, but this lets the
assembler parse them at least.

For #14068.

Change-Id: Id4f7329a969b747a867ce261b20165fab2cdcab8
Reviewed-on: https://go-review.googlesource.com/18846Reviewed-by: Rob Pike <r@golang.org>

Also, remove output file if there are encoding errors.
The extra reports are convenient.
Removing the output file is very important.
Noticed while testing.

Change-Id: I0fab17d4078f93c5a0d6d1217d8d9a63ac789696
Reviewed-on: https://go-review.googlesource.com/18845Reviewed-by: Rob Pike <r@golang.org>

Instead of two parallel files that look almost identical,
mark the expected differences in the original file.

The annotations being added here keep the tests passing,
but they also make clear a number of printing or parsing
errors that were not as easily seen when the data was
split across two files.

Fix a few diagnostic problems in cmd/internal/obj as well.

A step toward #13822.

Change-Id: I997172681ea6fa7da915ff0f0ab93d2b76f8dce2
Reviewed-on: https://go-review.googlesource.com/18823
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

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

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

Fixes #14050.

Change-Id: I2d9c32213b0da35703edf28f92ed3efb23325921
Reviewed-on: https://go-review.googlesource.com/18792
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Add docs for valid uses of Pointer.
Then document change made for #13372 in CL 18584.

Fixes #8994.

Change-Id: Ifba71e5aeafd11f684aed0b7ddacf3c8ec07c580
Reviewed-on: https://go-review.googlesource.com/18640Reviewed-by: Alan Donovan <adonovan@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Rick Hudson <rlh@golang.org>

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

- obtained by running sh vendor.bash
- contains updated tests and some bug fixes for Montgomery mult.
  (not used by compiler)
- for consistency of math/big versions only

Change-Id: Ib47e48d5b7f6d0e05d7837b1bc74bdb03f2b094e
Reviewed-on: https://go-review.googlesource.com/18831
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: I4816a788e7b89b76dc70d05f4b176e99684d0680
Reviewed-on: https://go-review.googlesource.com/18830
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

It doesn't work and I don't know why.

Update #14063.

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

Change-Id: Id82209dc313fa6b54e623eb325412737e7a055fe
Reviewed-on: https://go-review.googlesource.com/18794Reviewed-by: Andrew Gerrand <adg@golang.org>

On NetBSD a signal handler returns to the kernel by calling the
setcontext system call with the context passed to the signal handler.
The implementation of runtime·sigreturn_tramp for amd64, copied from the
NetBSD libc, expects that context address to be in r15.  That works in
the NetBSD libc because r15 is preserved across the call to the signal
handler.  It fails in the Go library because r15 is not preserved.
There are various ways to fix this; this one uses the simple approach,
essentially identical to the one in the NetBSD libc, of preserving r15
across the signal handler proper.

Looking at the code for 386 and arm suggests that they are OK.  However,
I have not actually tested them.

Update #14052.

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

On NetBSD and DragonFly a newly created thread inherits the signal stack
of the creating thread.  This breaks horribly if both threads get a
signal at the same time.  Fix this by dropping the signal stack in the
newly created thread.  The right signal stack will then get installed
later.

Note that cgo code that calls pthread_create will have the wrong,
duplicated, signal stack in the newly created thread.  I don't see any
way to fix that in Go.  People using cgo to call pthread_create will
have to be aware of the problem.

Fixes #13945.
Fixes #13947.

Change-Id: I0c7bd2cdf9ada575d57182ca5e9523060de34931
Reviewed-on: https://go-review.googlesource.com/18814
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

The TestInterfaceAddrsWithNetsh Windows unit test parses and compares the
output of the "netsh" command against more low level Windows API calls. In
at least two cases, some quirks of netsh cause these comparisons to fail.

One example appears to be wi-fi adapters. After a reboot, before it has
been allowed to connect to a network, netsh for IPv4 will not show an
address, whereas netsh for IPv6 will. If the interface is allowed to
connect, and then disconnected, netsh for IPv4 now shows an address and
the test will pass.

The fix is to not compare netsh output if the interface is down.

A related issue is that the IPv6 version of "netsh" can return an
IPv4-embedded IPv6 address where the IPv4 component of the address
is in decimal form, whilst the test is expecting hexadecimal form.

For example, output might be:

  Address fe80::5efe:192.168.1.7%6 Parameters
    ...

Whilst this is valid notation, the fix is to recognise this format in the
"netsh" output and re-parse the address into the all-hexadecimal
representation that the test is expecting.

Fixes #13981

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

LoadX509KeyPair and X509KeyPair don't retain the parsed form of
certificates in their return value because it's generally not needed.
This change makes that clear in the comment.

See https://groups.google.com/d/msg/golang-dev/VResvFj2vF8/Wt6WkVT2AwAJ

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

The header was in the wrong place, so the definition of a pipeline
was not in the section labeled "Pipelines".

Fixes #13972

Change-Id: Ibca791a4511ca112047b57091c391f6e959fdd78
Reviewed-on: https://go-review.googlesource.com/18775Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>

On HTTP redirect, the HTTP client creates a new request and don't copy
over the Cancel channel. This prevents any redirected request from being
cancelled.

Fixes #14053

Change-Id: I467cdd4aadcae8351b6e9733fc582b7985b8b9d3
Reviewed-on: https://go-review.googlesource.com/18810Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>