cmd/go: make "go test" recognize -exec flag again.

Fixes #12144.

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

cmd/compile: remove stale register use array

The reg[] array in .../gc is where truth lies.  The copy in .../ARCH
is incorrect as it is mostly not updated to reflect regalloc decisions.

This bug was introduced in the rewrite
https://go-review.googlesource.com/#/c/7853/.  The new reg[] array was
introduced in .../gc but not all of the uses were removed in the
.../ARCH directories.

Fixes #12133

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

cmd/compile/internal/ppc64: disable DUFFZERO

Update #12108

If DUFFZERO is used within a tail call method it will overwrite the
link register.

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

cmd/go: run test binaries in original environment

Fixes #12096.
Followup to CL 12483, which fixed #11709 and #11449.

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

cmd/go: fix addition of "math" dependency for arm binaries

p.ImportPath is the directory-derived path (like cmd/go).
p.Name is the actual package name.

Fixes #12089.

Change-Id: Ief76d42a85f811b0dfe2218affb48551527a7d44
Reviewed-on: https://go-review.googlesource.com/13530
Reviewed-by: David Crawshaw <crawshaw@golang.org>

cmd/link: make -a output not crash

Fixes #12107.

Change-Id: I62f1b6ac9fb6f2cfa3472253dc1c6f7b7d2a6faf
Reviewed-on: https://go-review.googlesource.com/13448
Reviewed-by: David Crawshaw <crawshaw@golang.org>

net/mail: fix build.

Change-Id: I8f5c72c6c0db015c06d564523bab35d97d934578
Reviewed-on: https://go-review.googlesource.com/13510
Reviewed-by: Michael McGreevy <mcgreevy@golang.org>
Reviewed-by: David Symonds <dsymonds@golang.org>

net/mail: avoid panic in (*Address).String for malformed addresses.

Fixes #12098.

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

cmd/yacc: use %q to print strings in Toknames

Fixes #12086

Belongs in 1.5

There remains a question of why the Statenames table's elements
are not printed. What purpose does that serve?

Change-Id: I83fd57b81d5e5065c3397a66ed457fc0d1c041bd
Reviewed-on: https://go-review.googlesource.com/13462
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

doc: link to Go 1.5 release notes from "project" page

Update issue #12102.

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

fmt: don't unread eof scanning %x

When scanning a hex byte at EOF, the code was ungetting the eof,
which backed up the input and caused double-scanning of a byte.

Delete the call to UnreadRune.

This line appeared in 1.5 for some reason; it was not in 1.4 and
should be removed again for 1.5

Fixes #12090.

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

doc: NaCl requires pepper 41

Fixes #12062
Updates #11961

The sRPC nameservice was removed in pepper 42. For Go 1.5 stipulate
that NaCl requires pepper 41 only.

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

runtime: make sure heapBitsBulkBarrier cannot be preempted

Changes the torture test in #12068 from failing about 1/10 times
to not failing in almost 2,000 runs.

This was only happening in -race mode because functions are
bigger in -race mode, so a few of the helpers for heapBitsBulkBarrier
were not being inlined, and they were not marked nosplit,
so (only in -race mode) the write barrier was being preempted by GC,
causing missed pointer updates.

Filed issue #12069 for diagnosis of any other similar errors.

Fixes #12068.

Change-Id: Ic174d9b050ba278b18b08ab0d85a73c33bd5b175
Reviewed-on: https://go-review.googlesource.com/13364
Reviewed-by: Austin Clements <austin@google.com>

runtime: run on GOARM=5 and GOARM=6 uniprocessor freebsd/arm systems

Also, crash early on non-Linux SMP ARM systems when GOARM < 7;
without the proper synchronization, SMP cannot work.

Linux is okay because we call kernel-provided routines for
synchronization and barriers, and the kernel takes care of
providing the right routines for the current system.
On non-Linux systems we are left to fend for ourselves.

It is possible to use different synchronization on GOARM=6,
but it's too late to do that in the Go 1.5 cycle.
We don't believe there are any non-Linux SMP GOARM=6 systems anyway.

Fixes #12067.

Change-Id: I771a556e47893ed540ec2cd33d23c06720157ea3
Reviewed-on: https://go-review.googlesource.com/13363
Reviewed-by: Austin Clements <austin@google.com>

cmd/go: replace code.google.com examples in docs with relevant repos

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

doc: tweak phrasing in Go 1.5 release notes

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

doc: do not call WaitGroup a function

Fixes #12060.

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

runtime: call goexit1 instead of goexit

Currently, runtime.Goexit() calls goexit()—the goroutine exit stub—to
terminate the goroutine. This *mostly* works, but can cause a
"leftover stack barriers" panic if the following happens:

1. Goroutine A has a reasonably large stack.

2. The garbage collector scan phase runs and installs stack barriers
   in A's stack. The top-most stack barrier happens to fall at address X.

3. Goroutine A unwinds the stack far enough to be a candidate for
   stack shrinking, but not past X.

4. Goroutine A calls runtime.Goexit(), which calls goexit(), which
   calls goexit1().

5. The garbage collector enters mark termination.

6. Goroutine A is preempted right at the prologue of goexit1() and
   performs a stack shrink, which calls gentraceback.

gentraceback stops as soon as it sees goexit on the stack, which is
only two frames up at this point, even though there may really be many
frames above it. More to the point, the stack barrier at X is above
the goexit frame, so gentraceback never sees that stack barrier. At
the end of gentraceback, it checks that it saw all of the stack
barriers and panics because it didn't see the one at X.

The fix is simple: call goexit1, which actually implements the process
of exiting a goroutine, rather than goexit, the exit stub.

To make sure this doesn't happen again in the future, we also add an
argument to the stub prototype of goexit so you really, really have to
want to call it in order to call it. We were able to reliably
reproduce the above sequence with a fair amount of awful code inserted
at the right places in the runtime, but chose to change the goexit
prototype to ensure this wouldn't happen again rather than pollute the
runtime with ugly testing code.

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

runtime: fix race that dropped GoSysExit events from trace

This makes TestTraceStressStartStop much less flaky.
Running under stress, it changes the failure rate from
above 1/100 to under 1/50000. That very unlikely
failure happens when an unexpected GoSysExit is
written. Not sure how that happens yet, but it is much
less important.

Fixes #11953.

Change-Id: I034671936334b4f3ab733614ef239aa121d20247
Reviewed-on: https://go-review.googlesource.com/13321
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

doc: remove duplicate -asmflags mention

Fixes #12053

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

net/url: allow all valid host chars in RawPath

The old code was only allowing the chars we choose not to escape.
We sometimes prefer to escape chars that do not strictly need it.
Allowing those to be used in RawPath lets people override that
preference, which is in fact the whole point of RawPath (new in Go 1.5).

While we are here, also allow [ ] in RawPath.
This is not strictly spec-compliant, but it is what modern browers
do and what at least some people expect, and the [ ] do not cause
any ambiguity (the usual reason they would be escaped, as they are
part of the RFC gen-delims class).
The argument for allowing them now instead of waiting until Go 1.6
is that this way RawPath has one fixed meaning at the time it is
introduced, that we should not need to change or expand.

Fixes #5684.

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

net/url: do not percent-encode valid host characters

The code in question was added as part of allowing zone identifiers
in IPv6 literals like http://[ipv6%zone]:port/foo, in golang.org/cl/2431.

The old condition makes no sense. It refers to §3.2.1, which is the wrong section
of the RFC, it excludes all the sub-delims, which §3.2.2 (the right section)
makes clear are valid, and it allows ':', which is not actually valid,
without an explanation as to why (because we keep :port in the Host field
of the URL struct).

The new condition allows all the sub-delims, as specified in RFC 3986,
plus the additional characters [ ] : seen in IP address literals and :port suffixes,
which we also keep in the Host field.

This allows mysql://a,b,c/path to continue to parse, as it did in Go 1.4 and earlier.

This CL does not break any existing tests, suggesting the over-conservative
behavior was not intended and perhaps not realized.

It is especially important not to over-escape the host field, because
Go does not unescape the host field during parsing: it rejects any
host field containing % characters.

Fixes #12036.

Change-Id: Iccbe4985957b3dc58b6dfb5dcb5b63a51a6feefb
Reviewed-on: https://go-review.googlesource.com/13254
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>

doc/go1.5.html: fix typo

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

net/url: restrict :port checking to [ipv6]:port form

Go 1.4 and earlier accepted mysql://x@y(z:123)/foo
and I don't see any compelling reason to break that.

The CL during Go 1.5 that broke this syntax was
trying to fix #11208 and was probably too aggressive.
I added a test case for #11208 to make sure that stays
fixed.

Relaxing the check did not re-break #11208 nor did
it cause any existing test to fail. I added a test for the
mysql://x@y(z:123)/foo syntax being preserved.

Fixes #12023.

Change-Id: I659d39f18c85111697732ad24b757169d69284fc
Reviewed-on: https://go-review.googlesource.com/13253
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>

A+C: add Andy Maloney

Fixes #10639

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

cmd/go: fix handling of vendored imports in foo_test.go files

Fixes #11977.
Fixes #11988.

Change-Id: I9f80006946d3752ee6d644ee51f2decfeaca1ff6
Reviewed-on: https://go-review.googlesource.com/13230
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

spec: clarify semantics of built-in functions 'complex', 'real', and 'imag'

For #11669, #11540, #11945, #11946, #11947.

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

crypto/tls: fix ConnectionState().VerifiedChains for resumed connection

Strengthening VerifyHostname exposed the fact that for resumed
connections, ConnectionState().VerifiedChains was not being saved
and restored during the ClientSessionCache operations.
Do that.

This change just saves the verified chains in the client's session
cache. It does not re-verify the certificates when resuming a
connection.

There are arguments both ways about this: we want fast, light-weight
resumption connections (thus suggesting that we shouldn't verify) but
it could also be a little surprising that, if the verification config
is changed, that would be ignored if the same session cache is used.

On the server side we do re-verify client-auth certificates, but the
situation is a little different there. The client session cache is an
object in memory that's reset each time the process restarts. But the
server's session cache is a conceptual object, held by the clients, so
can persist across server restarts. Thus the chance of a change in
verification config being surprisingly ignored is much higher in the
server case.

Fixes #12024.

Change-Id: I3081029623322ce3d9f4f3819659fdd9a381db16
Reviewed-on: https://go-review.googlesource.com/13164
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>

build: clean current tree in clean.bash

Otherwise clean.bash cleans $GOROOT, which might be something else entirely.

Fixes #12003.

Change-Id: I2ad5369017dde6db25f0c0514bc27c33d0a8bf54
Reviewed-on: https://go-review.googlesource.com/13251
Reviewed-by: David Crawshaw <crawshaw@golang.org>

net/http: close server conn after broken trailers

Prior to this change, broken trailers would be handled by body.Read, and
an error would be returned to its caller (likely a Handler), but that
error would go completely unnoticed by the rest of the server flow
allowing a broken connection to be reused.  This is a possible request
smuggling vector.

Fixes #12027.

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

crypto/tls: update testing certificates.

This change alters the certificate used in many tests so that it's no
longer self-signed. This allows some tests to exercise the standard
certificate verification paths in the future.

Change-Id: I9c3fcd6847eed8269ff3b86d9b6966406bf0642d
Reviewed-on: https://go-review.googlesource.com/13244
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>

go/build: fix internal/testenv dependency

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

runtime: don't recheck heap trigger for periodic GC

88e945f introduced a non-speculative double check of the heap trigger
before actually starting a concurrent GC. This was necessary to fix a
race for heap-triggered GC, but broke sysmon-triggered periodic GC,
since the heap check will of course fail for periodically triggered
GC.

Fix this by telling startGC whether or not this GC was triggered by
heap size or a timer and only doing the heap size double check for GCs
triggered by heap size.

Fixes #12026.

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

spec: better organization of arithmetic operator section

First step towards cleaning up the operator section - no language
changes. Specifically:

- Grouped arithmetic operations by types (integer, floating-point,
  string), with corresponding h4 headings.

- Changed Operator precedence title from h3 to h4.

- Moved Integer Overflow section after integer operations and changed
  its title from h3 to h4.

This puts things that belong together closer. No heading id's were
lost (in case of references from outside the spec).

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

spec: fix inconsistency of visibility rules for method names

Inconsistency identified by Anmol Sethi (anmol@aubble.com).

Fixes #10341.

Change-Id: I1a1f5b22aad29b56280f81026feaa37a61b3e0a9
Reviewed-on: https://go-review.googlesource.com/13132
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

spec: clarify that short variable declarations can redeclare parameters

Fixes #9837.

Change-Id: Ia513c7e5db221eee8e3ab0affa6d3688d2099fd9
Reviewed-on: https://go-review.googlesource.com/13130
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

spec: clarify sentence about non-constant shifts

Fixes #10514.

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

doc/go1.5: fix hyperlink for runtime/trace

Missed in CL 13074.

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

go/build: enable cgo on freebsd/arm

Now that it works we need to turn it back on.

Fixes #10119.

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

cmd/go: skip external tests on freebsd-arm builder

It is just far too slow.
I have a CL for Go 1.6 that makes many of these into internal tests.
That will improve the coverage.

It does not matter much, because basically none of the go command
tests are architecture dependent, so the other builders will catch
any problems.

Fixes freebsd-arm builder.

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

internal/testenv: add Builder, to report builder name

This works after golang.org/cl/13120 is running on the
coordinator (maybe it already is).

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

doc: mention new DWARF line table decoder in go1.5.html

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

doc/go1.5.html: update references to runtime/trace package

Tracing functionality was moved from runtime/pprof to runtime/trace.

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

runtime: align stack pointer during initcgo call on arm

This is what is causing freebsd/arm to crash mysteriously when using cgo.
The bug was introduced in golang.org/cl/4030, which moved this code out
of rt0_go and into its own function. The ARM ABI says that calls must
be made with the stack pointer at an 8-byte boundary, but only FreeBSD
seems to crash when this is violated.

Fixes #10119.

Change-Id: Ibdbe76b2c7b80943ab66b8abbb38b47acb70b1e5
Reviewed-on: https://go-review.googlesource.com/13161
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dave Cheney <dave@cheney.net>

doc: adjust installation instructions dynamically for a given download

This change allows the download page to redirect the user to
/doc/install?download=filename so the user can see installation
instructions specific to the file they are downloading.

This change also expands the "Test your Go installation" section
to instruct the user to create a workspace, hopefully leading
to less confusion down the line.

It also changes the front page download link to go directly
to the downloads page, which will in turn take them to the
installation instructions (the original destination).

This is related to this change to the tools repo:
https://golang.org/cl/13180

Change-Id: I658327bdb93ad228fb1846e389b281b15da91b1d
Reviewed-on: https://go-review.googlesource.com/13151
Reviewed-by: Chris Broadfoot <cbro@golang.org>

doc: bump minimum requirement to OS X 10.7

Fixes #11995

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

reflect: fix doc string

Fixes #12017.

Change-Id: I3dfcf9d0b62cae02eca1973383f0aad286a6ef4d
Reviewed-on: https://go-review.googlesource.com/13136
Reviewed-by: Keith Randall <khr@golang.org>

runtime: fix typos in comments

Change-Id: I66f7937b22bb6e05c3f2f0f2a057151020ad9699
Reviewed-on: https://go-review.googlesource.com/13049
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

runtime: fix assist utilization computation

When commit 510fd13 enabled assists during the scan phase, it failed
to also update the code in the GC controller that computed the assist
CPU utilization and adjusted the trigger based on it. Fix that code so
it uses the start of the scan phase as the wall-clock time when
assists were enabled rather than the start of the mark phase.

Change-Id: I05013734b4448c3e2c730dc7b0b5ee28c86ed8cf
Reviewed-on: https://go-review.googlesource.com/13048
Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

runtime: revise assist ratio aggressively

At the start of a GC cycle, the garbage collector computes the assist
ratio based on the total scannable heap size. This was intended to be
conservative; after all, this assumes the entire heap may be reachable
and hence needs to be scanned. But it only assumes that the *current*
entire heap may be reachable. It fails to account for heap allocated
during the GC cycle. If the trigger ratio is very low (near zero), and
most of the heap is reachable when GC starts (which is likely if the
trigger ratio is near zero), then it's possible for the mutator to
create new, reachable heap fast enough that the assists won't keep up
based on the assist ratio computed at the beginning of the cycle. As a
result, the heap can grow beyond the heap goal (by hundreds of megs in
stress tests like in issue #11911).

We already have some vestigial logic for dealing with situations like
this; it just doesn't run often enough. Currently, every 10 ms during
the GC cycle, the GC revises the assist ratio. This was put in before
we switched to a conservative assist ratio (when we really were using
estimates of scannable heap), and it turns out to be exactly what we
need now. However, every 10 ms is far too infrequent for a rapidly
allocating mutator.

This commit reuses this logic, but replaces the 10 ms timer with
revising the assist ratio every time the heap is locked, which
coincides precisely with when the statistics used to compute the
assist ratio are updated.

Fixes #11911.

Change-Id: I377b231ab064946228378fa10422a46d1b50f4c5
Reviewed-on: https://go-review.googlesource.com/13047
Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

runtime: when gcpacertrace > 0, print information about assist ratio

This was useful in debugging the mutator assist behavior for #11911,
and it fits with the other gcpacertrace output.

Change-Id: I1e25590bb4098223a160de796578bd11086309c7
Reviewed-on: https://go-review.googlesource.com/13046
Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

runtime: make sweep proportional to spans bytes allocated

Proportional concurrent sweep is currently based on a ratio of spans
to be swept per bytes of object allocation. However, proportional
sweeping is performed during span allocation, not object allocation,
in order to minimize contention and overhead. Since objects are
allocated from spans after those spans are allocated, the system tends
to operate in debt, which means when the next GC cycle starts, there
is often sweep debt remaining, so GC has to finish the sweep, which
delays the start of the cycle and delays enabling mutator assists.

For example, it's quite likely that many Ps will simultaneously refill
their span caches immediately after a GC cycle (because GC flushes the
span caches), but at this point, there has been very little object
allocation since the end of GC, so very little sweeping is done. The
Ps then allocate objects from these cached spans, which drives up the
bytes of object allocation, but since these allocations are coming
from cached spans, nothing considers whether more sweeping has to
happen. If the sweep ratio is high enough (which can happen if the
next GC trigger is very close to the retained heap size), this can
easily represent a sweep debt of thousands of pages.

Fix this by making proportional sweep proportional to the number of
bytes of spans allocated, rather than the number of bytes of objects
allocated. Prior to allocating a span, both the small object path and
the large object path ensure credit for allocating that span, so the
system operates in the black, rather than in the red.

Combined with the previous commit, this should eliminate all sweeping
from GC start up. On the stress test in issue #11911, this reduces the
time spent sweeping during GC (and delaying start up) by several
orders of magnitude:

                mean    99%ile     max
    pre fix      1 ms    11 ms   144 ms
    post fix   270 ns   735 ns   916 ns

Updates #11911.

Change-Id: I89223712883954c9d6ec2a7a51ecb97172097df3
Reviewed-on: https://go-review.googlesource.com/13044
Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

runtime: always give concurrent sweep some heap distance

Currently it's possible for the next_gc heap size trigger computed for
the next GC cycle to be less than the current allocated heap size.
This means the next cycle will start immediately, which means there's
no time to perform the concurrent sweep between GC cycles. This places
responsibility for finishing the sweep on GC itself, which delays GC
start-up and hence delays mutator assist.

Fix this by ensuring that next_gc is always at least a little higher
than the allocated heap size, so we won't trigger the next cycle
instantly.

Updates #11911.

Change-Id: I74f0b887bf187518d5fedffc7989817cbcf30592
Reviewed-on: https://go-review.googlesource.com/13043
Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

runtime: assist the GC during GC startup and shutdown

Currently there are two sensitive periods during which a mutator can
allocate past the heap goal but mutator assists can't be enabled: 1)
at the beginning of GC between when the heap first passes the heap
trigger and sweep termination and 2) at the end of GC between mark
termination and when the background GC goroutine parks. During these
periods there's no back-pressure or safety net, so a rapidly
allocating mutator can allocate past the heap goal. This is
exacerbated if there are many goroutines because the GC coordinator is
scheduled as any other goroutine, so if it gets preempted during one
of these periods, it may stay preempted for a long period (10s or 100s
of milliseconds).

Normally the mutator does scan work to create back-pressure against
allocation, but there is no scan work during these periods. Hence, as
a fall back, if a mutator would assist but can't yet, simply yield the
CPU. This delays the mutator somewhat, but more importantly gives more
CPU time to the GC coordinator for it to complete the transition.

This is obviously a workaround. Issue #11970 suggests a far better but
far more invasive way to fix this.

Updates #11911. (This very nearly fixes the issue, but about once
every 15 minutes I get a GC cycle where the assists are enabled but
don't do enough work.)

Change-Id: I9768b79e3778abd3e06d306596c3bd77f65bf3f1
Reviewed-on: https://go-review.googlesource.com/13026
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

runtime: recheck GC trigger before actually starting GC

Currently allocation checks the GC trigger speculatively during
allocation and then triggers the GC without rechecking. As a result,
it's possible for G 1 and G 2 to detect the trigger simultaneously,
both enter startGC, G 1 actually starts GC while G 2 gets preempted
until after the whole GC cycle, then G 2 immediately starts another GC
cycle even though the heap is now well under the trigger.

Fix this by re-checking the GC trigger non-speculatively just before
actually kicking off a new GC cycle.

This contributes to #11911 because when this happens, we definitely
don't finish the background sweep before starting the next GC cycle,
which can significantly delay the start of concurrent scan.

Change-Id: I560ab79ba5684ba435084410a9765d28f5745976
Reviewed-on: https://go-review.googlesource.com/13025
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

doc: link to design doc for GOMAXPROCS change in go1.5.html

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

cmd/go: fix documentation for exported functions

I accidentally submitted https://golang.org/cl/13080 too early.

Update #11955.

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

archive/tar: don't treat multiple file system links as a tar hardlink

Do not assume that if stat shows multiple links that we should mark the
file as a hardlink in the tar format.  If the hardlink link was not
referenced, this caused a link to "/".  On an overlay file system, all
files have multiple links.

The caller must keep the inode references and set TypeLink, Size = 0,
and LinkName themselves.

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

cmd/go: document that functions are exported by cgo

The buildmode docs mention exported functions, but don't say anything
about how to export them.  Mention the cgo tool to make this somewhat
clearer.

Fixes #11955.

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

go/types: remove the renaming import of go/constant

For niceness, when go/exact was moved from x/tools, it
was renamed go/constant.

For simplicity, when go/types was moved from x/tools, its
imports of (now) go/constant were done with a rename:

    import exact "go/constant"

This kept the code just as it was before and avoided the issue
of what to call the internal constant called, um, constant.

But not all was hidden, as the text of some fields of structs and
the like leaked the old name, so things like "exact.Value" appeared
in type definitions and function signatures in the documentation.
This is unacceptable.

Fix the documentation issue by fixing the code. Rename the constant
constant constant_, and remove the renaming import.

This should go into 1.5. It's mostly a mechanical change, is
internal to the package, and fixes the documentation. It contains
no semantic changes except to fix a benchmark that was broken
in the original transition.

Fixes #11949.

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

doc: link to the release cycle from contribute.html

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

cmd/go: re-run mkalldocs.sh after testflag change

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

doc: Mention contributor agreement immediately after Gerrit

I walked through the steps for a contribution but ended up
with an error when doing "git mail" because I didn't have a
signed agreement.

Added a section to check for or create one through Gerrit right
after the user has created the account and logged in.

Moved some info from copyright section to the new section.

Change-Id: I79bbd3e18fc3a742fa59a242085da14be9e19ba0
Reviewed-on: https://go-review.googlesource.com/13062
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>

cmd/go: documented default value of the -timeout testflag

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

cmd/go: clean up installHeader action

This was confusing when I was trying to fix go build -o.
Perhaps due to that fix, this can now be simplified from
three functions to one.

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

cmd/go: document and fix 'go build -o' semantics

Quoting the new docs:

«
If the arguments to build are a list of .go files, build treats
them as a list of source files specifying a single package.

When compiling a single main package, build writes
the resulting executable to an output file named after
the first source file ('go build ed.go rx.go' writes 'ed' or 'ed.exe')
or the source code directory ('go build unix/sam' writes 'sam' or 'sam.exe').
The '.exe' suffix is added when writing a Windows executable.

When compiling multiple packages or a single non-main package,
build compiles the packages but discards the resulting object,
serving only as a check that the packages can be built.

The -o flag, only allowed when compiling a single package,
forces build to write the resulting executable or object
to the named output file, instead of the default behavior described
in the last two paragraphs.
»

There is a change in behavior here, namely that 'go build -o x.a x.go'
where x.go is not a command (not package main) did not write any
output files (back to at least Go 1.2) but now writes x.a.
This seems more reasonable than trying to explain that -o is
sometimes silently ignored.

Otherwise the behavior is unchanged.

The lines being deleted in goFilesPackage look like they are
setting up 'go build x.o' to write 'x.a', but they were overridden
by the p.target = "" in runBuild. Again back to at least Go 1.2,
'go build x.go' for a non-main package has never produced
output. It seems better to keep it that way than to change it,
both for historical consistency and for consistency with
'go build strings' and 'go build std'.

All of this behavior is now tested.

Fixes #10865.

Change-Id: Iccdf21f366fbc8b5ae600a1e50dfe7fc3bff8b1c
Reviewed-on: https://go-review.googlesource.com/13024
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dave Day <djd@golang.org>

net/http: deflake TestZeroLengthPostAndResponse

It was failing with multiple goroutines a few out of every thousand
runs (with errRequestCanceled) because it was using the same
*http.Request for all 5 RoundTrips, but the RoundTrips' goroutines
(notably the readLoop method) were all still running, sharing that
same pointer. Because the response has no body (which is what
TestZeroLengthPostAndResponse tests), the readLoop was marking the
connection as reusable early (before the caller read until the body's
EOF), but the Transport code was clearing the Request's cancelation
func *AFTER* the caller had already received it from RoundTrip. This
let the test continue looping and do the next request with the same
pointer, fetch a connection, and then between getConn and roundTrip
have an invariant violated: the Request's cancelation func was nil,
tripping this check:

        if !pc.t.replaceReqCanceler(req.Request, pc.cancelRequest) {
                pc.t.putIdleConn(pc)
                return nil, errRequestCanceled
        }

The solution is to clear the request cancelation func in the readLoop
goroutine in the no-body case before it's returned to the caller.

This now passes reliably:

$ go test -race -run=TestZeroLengthPostAndResponse -count=3000

I think we've only seen this recently because we now randomize scheduling
of goroutines in race mode (https://golang.org/cl/11795). This race
has existed for a long time but the window was hard to hit.

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

net/http: fix server/transport data race when sharing the request body

Introduced in https://go-review.googlesource.com/12865 (git rev c2db5f4c).

This fix doesn't add any new lock acquistions: it just moves the
existing one taken by the unreadDataSize method and moves it out
wider.

It became flaky at rev c2db5f4c, but now reliably passes again:
$ go test -v -race -run=TestTransportAndServerSharedBodyRace -count=100 net/http

Fixes #11985

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

runtime: skip TestCgoCallbackGC on dragonfly

Updates #11990.

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

doc: document new linker -X syntax in go1.5.html

Fixes #11973.

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

doc: link to proposal process from contribution guidelines

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

doc: update install from source instructions for go1.5

Fixes #11983

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

net/http: close server conn after request body error

HTTP servers attempt to entirely consume a request body before sending a
response.  However, when doing so, it previously would ignore any errors
encountered.

Unfortunately, the errors triggered at this stage are indicative of at
least a couple problems: read timeouts and chunked encoding errors.
This means properly crafted and/or timed requests could lead to a
"smuggled" request.

The fix is to inspect the errors created by the response body Reader,
and treat anything other than io.EOF or ErrBodyReadAfterClose as
fatal to the connection.

Fixes #11930

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

net/http: fix SetKeepAlivesEnabled receiver name

This makes the receiver name consistent with the rest of the methods on
type Server.

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

spec: fixed various example code snippets

Per suggestions by Peter Olsen (https://github.com/pto).

Fixes #11964.

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

cmd/objdump: don't run TestDisasmExtld if cgo is not enabled

The test uses external linking mode, which is probably not available
if cgo does not work.

Fixes #11969.

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

os: add explicit tests for fchown(2) and lchown(2) on unix platforms

Fixes #11919

Issue #11918 suggested that os.File.Chown and os.Lchown were under tested.

Change-Id: Ib41f7cb2d2fe0066d2ccb4d1bdabe1795efe80fc
Reviewed-on: https://go-review.googlesource.com/12834
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

cmd/go: fix go get x/... matching internal directories

Fixes #11960.

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

cmd/go: fix disallow of p/vendor/x during vendor experiment

The percolation of errors upward in the load process could
drop errors, meaning that a build tree could, depending on the
processing order, import the same directory as both "p/vendor/x"
and as "x". That's not supposed to be allowed. But then, worse,
the build would generate two jobs for building that directory,
which would use the same work space and overwrite each other's files,
leading to very strange failures.

Two fixes:

1. Fix the propagation of errors upward (prefer errors over success).
2. Check explicitly for duplicated packages before starting a build.

New test for #1.
Since #2 can't happen, tested #2 by hand after reverting fix for #1.

Fixes #11913.

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

cmd/compile, runtime: fix placement of map bucket overflow pointer on nacl

On most systems, a pointer is the worst case alignment, so adding
a pointer field at the end of a struct guarantees there will be no
padding added after that field (to satisfy overall struct alignment
due to some more-aligned field also present).

In the runtime, the map implementation needs a quick way to
get to the overflow pointer, which is last in the bucket struct,
so it uses size - sizeof(pointer) as the offset.

NaCl/amd64p32 is the exception, as always.
The worst case alignment is 64 bits but pointers are 32 bits.
There's a long history that is not worth going into, but when
we moved the overflow pointer to the end of the struct,
we didn't get the padding computation right.
The compiler computed the regular struct size and then
on amd64p32 added another 32-bit field.
And the runtime assumed it could step back two 32-bit fields
(one 64-bit register size) to get to the overflow pointer.
But in fact if the struct needed 64-bit alignment, the computation
of the regular struct size would have added a 32-bit pad already,
and then the code unconditionally added a second 32-bit pad.
This placed the overflow pointer three words from the end, not two.
The last two were padding, and since the runtime was consistent
about using the second-to-last word as the overflow pointer,
no harm done in the sense of overwriting useful memory.
But writing the overflow pointer to a non-pointer word of memory
means that the GC can't see the overflow blocks, so it will
collect them prematurely. Then bad things happen.

Correct all this in a few steps:

1. Add an explicit check at the end of the bucket layout in the
compiler that the overflow field is last in the struct, never
followed by padding.

2. When padding is needed on nacl (not always, just when needed),
insert it before the overflow pointer, to preserve the "last in the struct"
property.

3. Let the compiler have the final word on the width of the struct,
by inserting an explicit padding field instead of overwriting the
results of the width computation it does.

4. For the same reason (tell the truth to the compiler), set the type
of the overflow field when we're trying to pretend its not a pointer
(in this case the runtime maintains a list of the overflow blocks
elsewhere).

5. Make the runtime use "last in the struct" as its location algorithm.

This fixes TestTraceStress on nacl/amd64p32.
The 'bad map state' and 'invalid free list' failures no longer occur.

Fixes #11838.

Change-Id: If918887f8f252d988db0a35159944d2b36512f92
Reviewed-on: https://go-review.googlesource.com/12971
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Austin Clements <austin@google.com>

test/bench/shootout: fix build

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

net/mail: fixed quoted-local

Fixes some minor issues regarding quoted-string when parsing
the local-part.

Those strings should return an error:
- quoted-string without any content: `""@test.com`
- quoted-string containing tab: "\"\t\"@test.com"

Fixes #11293

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

cmd/internal/obj/arm: fix large stack offsets on nacl/arm

The code already fixed large non-stack offsets
but explicitly excluded stack references.
Perhaps you could get away with that before,
but current versions of nacl reject such stack
references. Rewrite them the same as the others.

For #11956 but probably not the last problem.

Change-Id: I0db4e3a1ed4f88ccddf0d30228982960091d9fb7
Reviewed-on: https://go-review.googlesource.com/13010
Reviewed-by: Dave Cheney <dave@cheney.net>

runtime: fix systemstack tracebacks on nacl/arm

For #11956.

Change-Id: Ic9b57cafa197953cc7f435941e44d42b60b3ddf0
Reviewed-on: https://go-review.googlesource.com/13011
Reviewed-by: Dave Cheney <dave@cheney.net>

test/bench/shootout: clean up binaries after run

Update #11943

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

runtime: avoid reference to stale stack after GC shrinkstack

Dangling pointer error. Unlikely to trigger in practice, but still.
Found by running GODEBUG=efence=1 GOGC=1 trace.test.

Change-Id: Ice474dedcf62dd33ab77526287a023ba3b166db9
Reviewed-on: https://go-review.googlesource.com/12991
Reviewed-by: Austin Clements <austin@google.com>

cmd/link: increase ELFRESERVE to a full page

Etcd and kubernetes have hit this.
See  https://bugzilla.redhat.com/show_bug.cgi?id=1248071

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

cmd/go: permit installing into a subdirectory of $GOPATH/bin

In https://golang.org/cl/12080 we forbade installing cross-compiled
binaries into a subdirectory of $GOBIN, in order to fix
https://golang.org/issue/9769.  However, that fix was too aggressive,
in that it also forbade installing into a subdirectory of $GOPATH/bin.

This patch permits installing cross-compiled binaries into a
subdirectory $GOPATH/bin while continuing to forbid installing into a
subdirectory of $GOBIN.

Fixes #11778.

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

doc: solaris info added to go1.5.html

Fixes #11952.

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

spec: document existing expression switch restrictions

The spec didn't specify several aspects of expression switches:

- The switch expression is evaluated exactly once.

- Switch expressions evaluating to an untyped value are converted
  to the respective default type before use.

- An (untyped) nil value is not permitted as expression switch
  value. (We could permit it relatively easily, but gc doesn't,
  and disallowing it is in symmetry with the rules for var decls
  without explicit type and untyped initializer expressions.)

- The comparison x == t between each case expression x and
  switch expression value t must be valid.

- (Some) duplicate constant case expressions are not permitted.

This change also clarifies the following issues:

 4524: mult. equal int const switch case values should be illegal
                                         -> spec issue fixed
 6398: switch w/ no value uses bool rather than untyped bool
                                         -> spec issue fixed
11578: allows duplicate switch cases     -> go/types bug
11667: int overflow in switch expression -> go/types bug
11668: use of untyped nil in switch      -> not a gc bug

Fixes #4524.
Fixes #6398.
Fixes #11668.

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

doc: in go1.5.html fix claim about linking for ppc64(le)?

Change-Id: If61c2063a8b63f0e3e498a5e86803b5ddba9fa3c
Reviewed-on: https://go-review.googlesource.com/12886
Reviewed-by: Austin Clements <austin@google.com>

A+C: automated update

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

api: update go1.5.txt

Fixes #11935

Change-Id: Ife00c246345f7d3f96aa95349a35e76671ca7160
Reviewed-on: https://go-review.googlesource.com/12769
Reviewed-by: Dave Cheney <dave@cheney.net>
Reviewed-by: Russ Cox <rsc@golang.org>

runtime/trace: report negative frequency as a time-ordering problem

This should fix the solaris/amd64 builder.

Change-Id: Idd6460cc9e842f7b874c9757379986aa723c974c
Reviewed-on: https://go-review.googlesource.com/12922
Reviewed-by: Austin Clements <austin@google.com>

syscall: use fchownat(2) in place of lchown(2) for linux/arm64

Fixes #11918

Replace calls to lchown(2) with fchownat(2) for linux/arm64 as the former is not suppored.

This change has also landed on the x/sys repo as CL 12837.

Change-Id: I58d4b144e051e36dd650ec9b7f3a02610ea943e5
Reviewed-on: https://go-review.googlesource.com/12833
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dave Cheney <dave@cheney.net>
Run-TryBot: Dave Cheney <dave@cheney.net>
Reviewed-by: Russ Cox <rsc@golang.org>

doc: add go1.5 note about change to zero-sized fields in cgo

This documents the change made in https://golang.org/cl/12864 for
https://golang.org/issue/11925.

Update #11925.

Change-Id: Id09f2a489ea947a725ed12c9cf793e5daef07a06
Reviewed-on: https://go-review.googlesource.com/12866
Reviewed-by: David Crawshaw <crawshaw@golang.org>

runtime, sync/atomic: add memory barriers in arm cas routines

This only triggers on ARMv7+.
If there are important SMP ARMv6 machines we can reconsider.

Makes TestLFStress tests pass and sync/atomic tests not time out
on Apple iPad Mini 3.

Fixes #7977.
Fixes #10189.

Change-Id: Ie424dea3765176a377d39746be9aa8265d11bec4
Reviewed-on: https://go-review.googlesource.com/12950
Reviewed-by: David Crawshaw <crawshaw@golang.org>

go/types: update comment to refer to package go/constant

For #11949.

Change-Id: I4329604a24efc7f40cf5bf52fb3c9e30916b3cc2
Reviewed-on: https://go-review.googlesource.com/12931
Reviewed-by: Alan Donovan <adonovan@google.com>

encoding/json: revert "fix decoding of JSON null values"

Fixes #11912.
Fixes #11937.

This reverts commit 1a99ba55df902a2657d1ccfc52a60024c22dba98.

Change-Id: I32b76053fdabc59f28ca5bedf1b15c0baa8afae1
Reviewed-on: https://go-review.googlesource.com/12893
Reviewed-by: Didier Spezia <didier.06@gmail.com>
Reviewed-by: David Crawshaw <crawshaw@golang.org>

runtime/cgo: fix darwin/amd64 signal handling setup

Was not allocating space for the frame above sigpanic,
nor was it pushing the LR into the right place.
Because traceback past sigpanic only needs the
LR for faulting leaves, this was not noticed too much.
But it did break the sync/atomic nil deref tests.

Change-Id: Icba53fffa193423aab744c37f21ee893ce2ee3ac
Reviewed-on: https://go-review.googlesource.com/12926
Reviewed-by: David Crawshaw <crawshaw@golang.org>