[release-branch.go1.5] cmd/compile: fix Val vs Opt collision

Fixes #12686.

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

[release-branch.go1.5] runtime: prevent sigprof during all stack barrier ops

A sigprof during stack barrier insertion or removal can crash if it
detects an inconsistency between the stkbar array and the stack
itself. Currently we protect against this when scanning another G's
stack using stackLock, but we don't protect against it when unwinding
stack barriers for a recover or a memmove to the stack.

This commit cleans up and improves the stack locking code. It
abstracts out the lock and unlock operations. It uses the lock
consistently everywhere we perform stack operations, and pushes the
lock/unlock down closer to where the stack barrier operations happen
to make it more obvious what it's protecting. Finally, it modifies
sigprof so that instead of spinning until it acquires the lock, it
simply doesn't perform a traceback if it can't acquire it. This is
necessary to prevent self-deadlock.

Updates #11863, which introduced stackLock to fix some of these
issues, but didn't go far enough.

Updates #12528.

Change-Id: I9d1fa88ae3744d31ba91500c96c6988ce1a3a349
Reviewed-on: https://go-review.googlesource.com/17036
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-on: https://go-review.googlesource.com/17057

[release-branch.go1.5] runtime: fix new stack barrier check

During a crash showing goroutine stacks of all threads
(with GOTRACEBACK=crash), it can be that f == nil.

Only happens on Solaris; not sure why.

Change-Id: Iee2c394a0cf19fa0a24f6befbc70776b9e42d25a
Reviewed-on: https://go-review.googlesource.com/17110
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-on: https://go-review.googlesource.com/17122
Reviewed-by: Russ Cox <rsc@golang.org>

[release-branch.go1.5] runtime: handle sigprof in stackBarrier

Currently, if a profiling signal happens in the middle of
stackBarrier, gentraceback may see inconsistencies between stkbar and
the barriers on the stack and it will certainly get the wrong return
PC for stackBarrier. In most cases, the return PC won't be a PC at all
and this will immediately abort the traceback (which is considered
okay for a sigprof), but if it happens to be a valid PC this may sent
gentraceback down a rabbit hole.

Fix this by detecting when the gentraceback starts in stackBarrier and
simulating the completion of the barrier to get the correct initial
frame.

Change-Id: Ib11f705ac9194925f63fe5dfbfc84013a38333e6
Reviewed-on: https://go-review.googlesource.com/17035
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-on: https://go-review.googlesource.com/17056

[release-branch.go1.5] runtime: handle sysReserve returning a pointer below the arena

In mheap.sysAlloc, if an allocation at arena_used would exceed
arena_end (but wouldn't yet push us past arena_start+_MaxArean32), it
trie to extend the arena reservation by another 256 MB. It extends the
arena by calling sysReserve, which, on 32-bit, calls mmap without
MAP_FIXED, which means the address is just a hint and the kernel can
put the mapping wherever it wants. In particular, mmap may choose an
address below arena_start (the kernel also chose arena_start, so there
could be lots of space below it). Currently, we don't detect this case
and, if it happens, mheap.sysAlloc will corrupt arena_end and
arena_used then return the low pointer to mheap.grow, which will crash
when it attempts to index in to h_spans with an underflowed index.

Fix this by checking not only that that p+p_size isn't too high, but
that p isn't too low.

Fixes #13143.

Change-Id: I8d0f42bd1484460282a83c6f1a6f8f0df7fb2048
Reviewed-on: https://go-review.googlesource.com/16927
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-on: https://go-review.googlesource.com/16988
Reviewed-by: Russ Cox <rsc@golang.org>

[release-branch.go1.5] runtime: avoid stat underflow crash

If the area returned by sysReserve in mheap.sysAlloc is outside the
usable arena, we sysFree it. We pass a fake stat pointer to sysFree
because we haven't added the allocation to any stat at that point.
However, we pass a 0 stat, so sysFree panics when it decrements the
stat because the fake stat underflows.

Fix this by setting the fake stat to the allocation size.

Updates #13143 (this is a prerequisite to fixing that bug).

Change-Id: I61a6c9be19ac1c95863cf6a8435e19790c8bfc9a
Reviewed-on: https://go-review.googlesource.com/16926
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-on: https://go-review.googlesource.com/16987
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>

[release-branch.go1.5] runtime: ignore rt_sigaction error if it is for SIGRTMAX

A forward port of https://codereview.appspot.com/124900043/ which somehow
got lost somewhere.

Fixes #13024

Change-Id: Iab128899e65c51d90f6704e3e1b2fc9326e3a1c2
Reviewed-on: https://go-review.googlesource.com/16853
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-on: https://go-review.googlesource.com/16986
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

[release-branch.go1.5] runtime: make SIGPROF skip stacks that are being copied

sigprof tracebacks the stack across systemstack switches to make
profile tracebacks more complete. However, it does this even if the
user stack is currently being copied, which means it may be in an
inconsistent state that will cause the traceback to panic.

One specific way this can happen is during stack shrinking. Some
goroutine blocks for STW, then enters gchelper, which then assists
with root marking. If that root marking happens to pick the original
goroutine and its stack needs to be shrunk, it will begin to copy that
stack. During this copy, the stack is generally inconsistent and, in
particular, the actual locations of the stack barriers and their
recorded locations are temporarily out of sync. If a SIGPROF happens
during this inconsistency, it will walk the stack all the way back to
the blocked goroutine and panic when it fails to unwind the stack
barriers.

Fix this by disallowing jumping to the user stack during SIGPROF if
that user stack is in the process of being copied.

Fixes #12932.

Change-Id: I9ef694c2c01e3653e292ce22612418dd3daff1b4
Reviewed-on: https://go-review.googlesource.com/16819
Reviewed-by: Daniel Morsing <daniel.morsing@gmail.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-on: https://go-review.googlesource.com/16985
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

[release-branch.go1.5] net: fix off by one error while counting interfaces on windows

Fixes #12301

Change-Id: I8d01ec9551c6cff7e6129e06a7deb36a3be9de41
Reviewed-on: https://go-review.googlesource.com/16751
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-on: https://go-review.googlesource.com/16984
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Russ Cox <rsc@golang.org>

[release-branch.go1.5] cmd/internal/obj/ppc64: fix assembly of SRADCC with immediate

sradi and sradi. hide the top bit of their immediate argument apart from the
rest of it, but the code only handled the sradi case.

I'm pretty sure this is the only instruction missing (a couple of the rotate
instructions encode their immediate the same way but their handling looks OK).

This fixes the failure of "GOARCH=amd64 ~/go/bin/go install -v runtime" as
reported in the bug.

Fixes #11987

Change-Id: I0cdefcd7a04e0e8fce45827e7054ffde9a83f589
Reviewed-on: https://go-review.googlesource.com/16710
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-on: https://go-review.googlesource.com/16983
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

[release-branch.go1.5] cmd/link: support new 386/amd64 relocations

The GNU binutils recently picked up support for new 386/amd64
relocations.  Add support for them in the Go linker when doing an
internal link.

The 386 relocation R_386_GOT32X was proposed in
https://groups.google.com/forum/#!topic/ia32-abi/GbJJskkid4I .  It can
be treated as identical to the R_386_GOT32 relocation.

The amd64 relocations R_X86_64_GOTPCRELX and R_X86_64_REX_GOTPCRELX were
proposed in
https://groups.google.com/forum/#!topic/x86-64-abi/n9AWHogmVY0 .  They
can both be treated as identical to the R_X86_64_GOTPCREL relocation.

The purpose of the new relocations is to permit additional linker
relaxations in some cases.  We do not attempt to support those cases.

While we're at it, remove the unused and in some cases out of date
_COUNT names from ld/elf.go.

Fixes #13114.

Change-Id: I34ef07f6fcd00cdd2996038ecf46bb77a49e968b
Reviewed-on: https://go-review.googlesource.com/16529
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-on: https://go-review.googlesource.com/16982
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

[release-branch.go1.5] cmd/compile: do not let regopt use REGTMP on ppc64

ppc64 codegen assumes that it is OK to stomp on r31 at any time, but it is not
excluded from the set of registers that regopt is allowed to use.

Fixes #12597

Change-Id: I29c7655e32abd22f3c21d88427b73e4fca055233
Reviewed-on: https://go-review.googlesource.com/15245
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-on: https://go-review.googlesource.com/16981
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

[release-branch.go1.5] runtime: adjust huge page flags only on huge page granularity

This fixes an issue where the runtime panics with "out of memory" or
"cannot allocate memory" even though there's ample memory by reducing
the number of memory mappings created by the memory allocator.

Commit 7e1b61c worked around issue #8832 where Linux's transparent
huge page support could dramatically increase the RSS of a Go process
by setting the MADV_NOHUGEPAGE flag on any regions of pages released
to the OS with MADV_DONTNEED. This had the side effect of also
increasing the number of VMAs (memory mappings) in a Go address space
because a separate VMA is needed for every region of the virtual
address space with different flags. Unfortunately, by default, Linux
limits the number of VMAs in an address space to 65530, and a large
heap can quickly reach this limit when the runtime starts scavenging
memory.

This commit dramatically reduces the number of VMAs. It does this
primarily by only adjusting the huge page flag at huge page
granularity. With this change, on amd64, even a pessimal heap that
alternates between MADV_NOHUGEPAGE and MADV_HUGEPAGE must reach 128GB
to reach the VMA limit. Because of this rounding to huge page
granularity, this change is also careful to leave large used and
unused regions huge page-enabled.

This change reduces the maximum number of VMAs during the runtime
benchmarks with GODEBUG=scavenge=1 from 692 to 49.

Fixes #12233.

Change-Id: Ic397776d042f20d53783a1cacf122e2e2db00584
Reviewed-on: https://go-review.googlesource.com/15191
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-on: https://go-review.googlesource.com/16980
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

[release-branch.go1.5] multipart: fixes problem parsing mime/multipart of certain lengths

When parsing the multipart data, if the delimiter appears but doesn't
finish with -- or \n or \r\n, it assumes the data can be consumed. This
is incorrect when the peeking buffer finishes with --delimiter-

Fixes #12662

Change-Id: I329556a9a206407c0958289bf7a9009229120bb9
Reviewed-on: https://go-review.googlesource.com/14652
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-on: https://go-review.googlesource.com/16969
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>

[release-branch.go1.5] runtime: preserve R11 in darwin/arm entrypoint

The _rt0_arm_darwin_lib entrypoint has to conform to the darwin ARMv7
calling convention, which requires functions to preserve the value of
R11. Go uses R11 as the liblink REGTMP register, so save it manually.

Also avoid using R4, which is also callee-save.

Fixes #12590

Change-Id: I9c3b374e330f81ff8fc9c01fa20505a33ddcf39a
Reviewed-on: https://go-review.googlesource.com/14603
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-on: https://go-review.googlesource.com/16968
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>

[release-branch.go1.5] runtime: unblock special glibc signals on each thread

Glibc uses some special signals for special thread operations.  These
signals will be used in programs that use cgo and invoke certain glibc
functions, such as setgid.  In order for this to work, these signals
need to not be masked by any thread.  Before this change, they were
being masked by programs that used os/signal.Notify, because it
carefully masks all non-thread-specific signals in all threads so that a
dedicated thread will collect and report those signals (see ensureSigM
in signal1_unix.go).

This change adds the two glibc special signals to the set of signals
that are unmasked in each thread.

Fixes #12498.

Change-Id: I797d71a099a2169c186f024185d44a2e1972d4ad
Reviewed-on: https://go-review.googlesource.com/14297
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-on: https://go-review.googlesource.com/16967
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

[release-branch.go1.5] runtime/cgo: explicitly link msvcrt on windows

It's because runtime links to ntdll, and ntdll exports a couple
incompatible libc functions. We must link to msvcrt first and
then try ntdll.

Fixes #12030.

Change-Id: I0105417bada108da55f5ae4482c2423ac7a92957
Reviewed-on: https://go-review.googlesource.com/14472
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-on: https://go-review.googlesource.com/16966
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

[release-branch.go1.5] cmd/compile/internal/gc: handle weird map literals in key dedup

We compute whether two keys k1 and k2 in a map literal are duplicates by
constructing the expression OEQ(k1, k2) and calling the constant
expression evaluator on that expression, then extracting the boolean
result.

Unfortunately, the constant expression evaluator can fail for various
reasons.  I'm not really sure why it is dying in the case of 12536, but
to be safe we should use the result only if we get a constant back (if
we get a constant back, it must be boolean).  This probably isn't a
permanent fix, but it should be good enough for 1.5.2.

A permanent fix would be to ensure that the constant expression
evaluator can always work for map literal keys, and if not the compiler
should generate an error saying that the key isn't a constant (or isn't
comparable to some specific other key).

This patch has the effect of allowing the map literal to compile when
constant eval of the OEQ fails.  If the keys are really equal (which the
map impl will notice at runtime), one will overwrite the other in the
resulting map.  Not great, but better than a compiler crash.

Fixes #12536

Change-Id: Ic151a5e3f131c2e8efa0c25c9218b431c55c1b30
Reviewed-on: https://go-review.googlesource.com/14400
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-on: https://go-review.googlesource.com/16965
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>

[release-branch.go1.5] runtime: memmove/memclr pointers atomically

Make sure that we're moving or zeroing pointers atomically.
Anything that is a multiple of pointer size and at least
pointer aligned might have pointers in it.  All the code looks
ok except for the 1-pointer-sized moves.

Fixes #13160
Update #12552

Change-Id: Ib97d9b918fa9f4cc5c56c67ed90255b7fdfb7b45
Reviewed-on: https://go-review.googlesource.com/16668
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-on: https://go-review.googlesource.com/16910
Reviewed-by: Russ Cox <rsc@golang.org>

[release-branch.go1.5] runtime: adjust the arm64 memmove and memclr to operate by word as much as they can

Not only is this an obvious optimization:

benchmark                           old MB/s     new MB/s     speedup
BenchmarkMemmove1-4                 35.35        29.65        0.84x
BenchmarkMemmove2-4                 63.78        52.53        0.82x
BenchmarkMemmove3-4                 89.72        73.96        0.82x
BenchmarkMemmove4-4                 109.94       95.73        0.87x
BenchmarkMemmove5-4                 127.60       112.80       0.88x
BenchmarkMemmove6-4                 143.59       126.67       0.88x
BenchmarkMemmove7-4                 157.90       138.92       0.88x
BenchmarkMemmove8-4                 167.18       231.81       1.39x
BenchmarkMemmove9-4                 175.23       252.07       1.44x
BenchmarkMemmove10-4                165.68       261.10       1.58x
BenchmarkMemmove11-4                174.43       263.31       1.51x
BenchmarkMemmove12-4                180.76       267.56       1.48x
BenchmarkMemmove13-4                189.06       284.93       1.51x
BenchmarkMemmove14-4                186.31       284.72       1.53x
BenchmarkMemmove15-4                195.75       281.62       1.44x
BenchmarkMemmove16-4                202.96       439.23       2.16x
BenchmarkMemmove32-4                264.77       775.77       2.93x
BenchmarkMemmove64-4                306.81       1209.64      3.94x
BenchmarkMemmove128-4               357.03       1515.41      4.24x
BenchmarkMemmove256-4               380.77       2066.01      5.43x
BenchmarkMemmove512-4               385.05       2556.45      6.64x
BenchmarkMemmove1024-4              381.23       2804.10      7.36x
BenchmarkMemmove2048-4              379.06       2814.83      7.43x
BenchmarkMemmove4096-4              387.43       3064.96      7.91x
BenchmarkMemmoveUnaligned1-4        28.91        25.40        0.88x
BenchmarkMemmoveUnaligned2-4        56.13        47.56        0.85x
BenchmarkMemmoveUnaligned3-4        74.32        69.31        0.93x
BenchmarkMemmoveUnaligned4-4        97.02        83.58        0.86x
BenchmarkMemmoveUnaligned5-4        110.17       103.62       0.94x
BenchmarkMemmoveUnaligned6-4        124.95       113.26       0.91x
BenchmarkMemmoveUnaligned7-4        142.37       130.82       0.92x
BenchmarkMemmoveUnaligned8-4        151.20       205.64       1.36x
BenchmarkMemmoveUnaligned9-4        166.97       215.42       1.29x
BenchmarkMemmoveUnaligned10-4       148.49       221.22       1.49x
BenchmarkMemmoveUnaligned11-4       159.47       239.57       1.50x
BenchmarkMemmoveUnaligned12-4       163.52       247.32       1.51x
BenchmarkMemmoveUnaligned13-4       167.55       256.54       1.53x
BenchmarkMemmoveUnaligned14-4       175.12       251.03       1.43x
BenchmarkMemmoveUnaligned15-4       192.10       267.13       1.39x
BenchmarkMemmoveUnaligned16-4       190.76       378.87       1.99x
BenchmarkMemmoveUnaligned32-4       259.02       562.98       2.17x
BenchmarkMemmoveUnaligned64-4       317.72       842.44       2.65x
BenchmarkMemmoveUnaligned128-4      355.43       1274.49      3.59x
BenchmarkMemmoveUnaligned256-4      378.17       1815.74      4.80x
BenchmarkMemmoveUnaligned512-4      362.15       2180.81      6.02x
BenchmarkMemmoveUnaligned1024-4     376.07       2453.58      6.52x
BenchmarkMemmoveUnaligned2048-4     381.66       2568.32      6.73x
BenchmarkMemmoveUnaligned4096-4     398.51       2669.36      6.70x
BenchmarkMemclr5-4                  113.83       107.93       0.95x
BenchmarkMemclr16-4                 223.84       389.63       1.74x
BenchmarkMemclr64-4                 421.99       1209.58      2.87x
BenchmarkMemclr256-4                525.94       2411.58      4.59x
BenchmarkMemclr4096-4               581.66       4372.20      7.52x
BenchmarkMemclr65536-4              565.84       4747.48      8.39x
BenchmarkGoMemclr5-4                194.63       160.31       0.82x
BenchmarkGoMemclr16-4               295.30       630.07       2.13x
BenchmarkGoMemclr64-4               480.24       1884.03      3.92x
BenchmarkGoMemclr256-4              540.23       2926.49      5.42x

but it turns out that it's necessary to avoid the GC seeing partially written
pointers.

It's of course possible to be more sophisticated (using ldp/stp to move 16
bytes at a time in the core loop and unrolling the tail copying loops being
the obvious ideas) but I wanted something simple and (reasonably) obviously
correct.

Fixes #12552

Change-Id: Iaeaf8a812cd06f4747ba2f792de1ded738890735
Reviewed-on: https://go-review.googlesource.com/14813
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-on: https://go-review.googlesource.com/16909
Reviewed-by: Russ Cox <rsc@golang.org>

[release-branch.go1.5] runtime: use 4 byte writes in amd64p32 memmove/memclr

Currently, amd64p32's memmove and memclr use 8 byte writes as much as
possible and 1 byte writes for the tail of the object. However, if an
object ends with a 4 byte pointer at an 8 byte aligned offset, this
may copy/zero the pointer field one byte at a time, allowing the
garbage collector to observe a partially copied pointer.

Fix this by using 4 byte writes instead of 8 byte writes.

Updates #12552.

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

[release-branch.go1.5] runtime: adjust the ppc64x memmove and memclr to copy by word as much as it can

Issue #12552 can happen on ppc64 too, although much less frequently in my
testing. I'm fairly sure this fixes it (2 out of 200 runs of oracle.test failed
without this change and 0 of 200 failed with it). It's also a lot faster for
large moves/clears:

name           old speed      new speed       delta
Memmove1-6      157MB/s ± 9%    144MB/s ± 0%    -8.20%         (p=0.004 n=10+9)
Memmove2-6      281MB/s ± 1%    249MB/s ± 1%   -11.53%        (p=0.000 n=10+10)
Memmove3-6      376MB/s ± 1%    328MB/s ± 1%   -12.64%        (p=0.000 n=10+10)
Memmove4-6      475MB/s ± 4%    345MB/s ± 1%   -27.28%         (p=0.000 n=10+8)
Memmove5-6      540MB/s ± 1%    393MB/s ± 0%   -27.21%        (p=0.000 n=10+10)
Memmove6-6      609MB/s ± 0%    423MB/s ± 0%   -30.56%         (p=0.000 n=9+10)
Memmove7-6      659MB/s ± 0%    468MB/s ± 0%   -28.99%         (p=0.000 n=8+10)
Memmove8-6      705MB/s ± 0%   1295MB/s ± 1%   +83.73%          (p=0.000 n=9+9)
Memmove9-6      740MB/s ± 1%   1241MB/s ± 1%   +67.61%         (p=0.000 n=10+8)
Memmove10-6     780MB/s ± 0%   1162MB/s ± 1%   +48.95%         (p=0.000 n=10+9)
Memmove11-6     811MB/s ± 0%   1180MB/s ± 0%   +45.58%          (p=0.000 n=8+9)
Memmove12-6     820MB/s ± 1%   1073MB/s ± 1%   +30.83%         (p=0.000 n=10+9)
Memmove13-6     849MB/s ± 0%   1068MB/s ± 1%   +25.87%        (p=0.000 n=10+10)
Memmove14-6     877MB/s ± 0%    911MB/s ± 0%    +3.83%        (p=0.000 n=10+10)
Memmove15-6     893MB/s ± 0%    922MB/s ± 0%    +3.25%         (p=0.000 n=10+9)
Memmove16-6     897MB/s ± 1%   2418MB/s ± 1%  +169.67%         (p=0.000 n=10+9)
Memmove32-6     908MB/s ± 0%   3927MB/s ± 2%  +332.64%         (p=0.000 n=10+8)
Memmove64-6    1.11GB/s ± 0%   5.59GB/s ± 0%  +404.64%          (p=0.000 n=9+9)
Memmove128-6   1.25GB/s ± 0%   6.71GB/s ± 2%  +437.49%         (p=0.000 n=9+10)
Memmove256-6   1.33GB/s ± 0%   7.25GB/s ± 1%  +445.06%        (p=0.000 n=10+10)
Memmove512-6   1.38GB/s ± 0%   8.87GB/s ± 0%  +544.43%        (p=0.000 n=10+10)
Memmove1024-6  1.40GB/s ± 0%  10.00GB/s ± 0%  +613.80%        (p=0.000 n=10+10)
Memmove2048-6  1.41GB/s ± 0%  10.65GB/s ± 0%  +652.95%         (p=0.000 n=9+10)
Memmove4096-6  1.42GB/s ± 0%  11.01GB/s ± 0%  +675.37%         (p=0.000 n=8+10)
Memclr5-6       269MB/s ± 1%    264MB/s ± 0%    -1.80%        (p=0.000 n=10+10)
Memclr16-6      600MB/s ± 0%    887MB/s ± 1%   +47.83%        (p=0.000 n=10+10)
Memclr64-6     1.06GB/s ± 0%   2.91GB/s ± 1%  +174.58%         (p=0.000 n=8+10)
Memclr256-6    1.32GB/s ± 0%   6.58GB/s ± 0%  +399.86%         (p=0.000 n=9+10)
Memclr4096-6   1.42GB/s ± 0%  10.90GB/s ± 0%  +668.03%         (p=0.000 n=8+10)
Memclr65536-6  1.43GB/s ± 0%  11.37GB/s ± 0%  +697.83%          (p=0.000 n=9+8)
GoMemclr5-6     359MB/s ± 0%    360MB/s ± 0%    +0.46%        (p=0.000 n=10+10)
GoMemclr16-6    750MB/s ± 0%   1264MB/s ± 1%   +68.45%        (p=0.000 n=10+10)
GoMemclr64-6   1.17GB/s ± 0%   3.78GB/s ± 1%  +223.58%         (p=0.000 n=10+9)
GoMemclr256-6  1.35GB/s ± 0%   7.47GB/s ± 0%  +452.44%        (p=0.000 n=10+10)

Update #12552

Change-Id: I7192e9deb9684a843aed37f58a16a4e29970e893
Reviewed-on: https://go-review.googlesource.com/14840
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-on: https://go-review.googlesource.com/16907
Reviewed-by: Russ Cox <rsc@golang.org>

[release-branch.go1.5] runtime: fix recursive GC assist better

Commit c257dfb attempted to fix recursive allocation in gcAssistAlloc;
however, it only reduced it: setting gp.gcalloc to 0 isn't sufficient
to disable assists at the beginning of the GC cycle when gp.gcscanwork
is also small or zero.

Fix this recursion more completely by setting gcalloc to a sentinel
value that directly disables assists.

Fixes #12894 (again).

Change-Id: I9599566222d8f540d0b39806846bfc702e6666e5
Reviewed-on: https://go-review.googlesource.com/15891
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

[release-branch.go1.5] runtime: fix recursive GC assist

If gcAssistAlloc is unable to steal or perform enough scan work, it
calls timeSleep, which allocates. If this allocation requires
obtaining a new span, it will in turn attempt to assist GC. Since
there's likely still no way to satisfy the assist, it will sleep
again, and so on, leading to potentially deep (not infinite, but also
not bounded) recursion.

Fix this by disallowing assists during the timeSleep.

This same problem was fixed on master by 65aa2da. That commit built on
several other changes and hence can't be directly cherry-picked. This
commit implements the same idea.

Fixes #12894.

Change-Id: I152977eb1d0a3005c42ff3985d58778f054a86d4
Reviewed-on: https://go-review.googlesource.com/15720
Reviewed-by: Rick Hudson <rlh@golang.org>

doc: update release tag in source directions to go1.5.1

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

[release-branch.go1.5] doc: document go1.4.3

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

[release-branch.go1.5] go1.5.1

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

[release-branch.go1.5] doc: document go1.5.1

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

[release-branch.go1.5] cmd/asm: handle CMPF and CMPD on ARM

These instructions are special cases that were missed in the translation.
The second argument must go into the Reg field not the To field.

Fixes #12458

For Go 1.5.1

Change-Id: Iad57c60c7e38e3bcfafda483ed5037ce670e8816
Reviewed-on: https://go-review.googlesource.com/14183
Reviewed-by: Dave Cheney <dave@cheney.net>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-on: https://go-review.googlesource.com/14358
Reviewed-by: Chris Broadfoot <cbro@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

[release-branch.go1.5] fmt: in Scanf, %c can scan a space, so don't skip spaces at %c

In short, %c should just give you the next rune, period.
Apparently this is the design. I use the term loosely.

Fixes #12275

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

[release-branch.go1.5] doc: mention that go install removes binaries built by go build

Fixes #12288.

For inclusion in the 1.5.1 release.

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

[release-branch.go1.5] AUTHORS: add Oracle as corporate copyright holder

Some commits made by Aram from his personal email address are
actually copyright Oracle:

a77fcb3 net: fix comment in sendFile
b0e71f4 net: link with networking libraries when net package is in use
92e959a syscall, net: use sendfile on Solaris
db8d5b7 net: try to fix setKeepAlivePeriod on Solaris
fe5ef5c runtime, syscall: link Solaris binaries directly instead of using dlopen/dlsym
2b90c3e go/build: enable cgo by default on solaris/amd64
2d18ab7 doc/progs: disable cgo tests that use C.Stdout on Solaris
2230e9d misc/cgo: add various solaris build lines
649c7b6 net: add cgo support for Solaris
24396da os/user: small fixes for Solaris
121489c runtime/cgo: add cgo support for solaris/amd64
83b25d9 cmd/ld: make .rela and .rela.plt sections contiguous
c94f1f7 runtime: always load address of libcFunc on Solaris
e481aac cmd/6l: use .plt instead of .got on Solaris

See bug for clarification.

Fixes #12452

Change-Id: I0aeb1b46c0c7d09c5c736e383ecf40240d2cf85f
Reviewed-on: https://go-review.googlesource.com/14380
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-on: https://go-review.googlesource.com/14393
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Revert "[release-branch.go1.5] runtime: check that stack barrier unwind is in sync"

This reverts commit f265044a489c9e572ffc141ed2d0e95f05d451c9.

Change-Id: I454f9da3a40d6724ab106aae904b8e77756aae99
Reviewed-on: https://go-review.googlesource.com/14383
Run-TryBot: Chris Broadfoot <cbro@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

[release-branch.go1.5] runtime: check that stack barrier unwind is in sync

Currently the stack barrier stub blindly unwinds the next stack
barrier from the G's stack barrier array without checking that it's
the right stack barrier. If through some bug the stack barrier array
position gets out of sync with where we actually are on the stack,
this could return to the wrong PC, which would lead to difficult to
debug crashes. To address this, this commit adds a check to the amd64
stack barrier stub that it's unwinding the correct stack barrier.

Updates #12238.

Change-Id: If824d95191d07e2512dc5dba0d9978cfd9f54e02
Reviewed-on: https://go-review.googlesource.com/13948
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-on: https://go-review.googlesource.com/14241
Reviewed-by: Austin Clements <austin@google.com>

[release-branch.go1.5] net/http/httputil: permit nil request body in ReverseProxy

Accepting a request with a nil body was never explicitly supported but
happened to work in the past.

This doesn't happen in most cases because usually people pass
a Server's incoming Request to the ReverseProxy's ServeHTTP method,
and incoming server requests are guaranteed to have non-nil bodies.

Still, it's a regression, so fix.

Fixes #12344

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

[release-branch.go1.5] net: restore LookupPort for integer strings

This worked in Go 1.4 but was lost in the "pure Go" lookup
routines substituted late in the Go 1.5 cycle.

Fixes #12263.

Change-Id: I77ec9d97cd8e67ace99d6ac965e5bc16c151ba83
Reviewed-on: https://go-review.googlesource.com/13915
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-on: https://go-review.googlesource.com/14243
Reviewed-by: Ian Lance Taylor <iant@golang.org>

[release-branch.go1.5] cmd/go: properly ignore import comments for vendored packages rooted at GOPATH

Fixes #12232.

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

[release-branch.go1.5] cmd/compile: fix register allocation for == operator

The issue 12226 has been caused by the allocation of the same register
for the equality check of two byte values. The code in cgen.go freed the
register for the second operand before the allocation of the register
for the first operand.

Fixes #12226

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

[release-branch.go1.5] runtime: don't install a stack barrier in cgocallback_gofunc's frame

Currently the runtime can install stack barriers in any frame.
However, the frame of cgocallback_gofunc is special: it's the one
function that switches from a regular G stack to the system stack on
return. Hence, the return PC slot in its frame on the G stack is
actually used to save getg().sched.pc (so tracebacks appear to unwind
to the last Go function running on that G), and not as an actual
return PC for cgocallback_gofunc.

Because of this, if we install a stack barrier in cgocallback_gofunc's
return PC slot, when cgocallback_gofunc does return, it will move the
stack barrier stub PC in to getg().sched.pc and switch back to the
system stack. The rest of the runtime doesn't know how to deal with a
stack barrier stub in sched.pc: nothing knows how to match it up with
the G's stack barrier array and, when the runtime removes stack
barriers, it doesn't know to undo the one in sched.pc. Hence, if the C
code later returns back in to Go code, it will attempt to return
through the stack barrier saved in sched.pc, which may no longer have
correct unwinding information.

Fix this by blacklisting cgocallback_gofunc's frame so the runtime
won't install a stack barrier in it's return PC slot.

Fixes #12238.

Change-Id: I46aa2155df2fd050dd50de3434b62987dc4947b8
Reviewed-on: https://go-review.googlesource.com/13944
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-on: https://go-review.googlesource.com/14229
Reviewed-by: Austin Clements <austin@google.com>

[release-branch.go1.5] runtime: add GODEBUG for stack barriers at every frame

Currently enabling the debugging mode where stack barriers are
installed at every frame requires recompiling the runtime. However,
this is potentially useful for field debugging and for runtime tests,
so make this mode a GODEBUG.

Updates #12238.

Change-Id: I6fb128f598b19568ae723a612e099c0ed96917f5
Reviewed-on: https://go-review.googlesource.com/13947
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-on: https://go-review.googlesource.com/14240
Reviewed-by: Austin Clements <austin@google.com>

[release-branch.go1.5] cmd/compile: fix uninitialized memory in compare of interface value

A comparison of the form l == r where l is an interface and r is
concrete performs a type assertion on l to convert it to r's type.
However, the compiler fails to zero the temporary where the result of
the type assertion is written, so if the type is a pointer type and a
stack scan occurs while in the type assertion, it may see an invalid
pointer on the stack.

Fix this by zeroing the temporary. This is equivalent to the fix for
type switches from c4092ac.

Fixes #12253.

Change-Id: Iaf205d456b856c056b317b4e888ce892f0c555b9
Reviewed-on: https://go-review.googlesource.com/13872
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-on: https://go-review.googlesource.com/14242
Reviewed-by: Austin Clements <austin@google.com>

[release-branch.go1.5] internal/syscall/windows/registry: remove debugging dreg

Change-Id: I1b9f6ad322a7f68fa160c4f09d7fb56815e505a7
Reviewed-on: https://go-review.googlesource.com/13828
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-on: https://go-review.googlesource.com/14244
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>

[release-branch.go1.5] cmd/asm: fix potential infinite loop in parser

For ARM machines, the assembler supports list of registers
operands such as [R1,R2].

A list missing a ']' results in the parser issuing many errors
and consuming all the tokens. At EOF (i.e. end of the line),
it still loops.

Normally, a counter is maintained to make sure the parser
stops after 10 errors. However, multiple errors occuring on the
same line are simply ignored. Only the first one is reported.
At most one error per line is accounted.

Missing ']' in a register list therefore results in an
infinite loop.

Fixed the parser by explicitly checking for ']' to interrupt
this loops

In the operand tests, also fixed a wrong entry which I think was
not set on purpose (but still led to a successful result).

Fixes #11764

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

[release-branch.go1.5] cmd/go: -a does apply to the standard library

This changed in https://golang.org/cl/10761.

Update #12203.

Change-Id: Ia37ebb7ecba689ad3cb2559213d675f21cf03a95
Reviewed-on: https://go-review.googlesource.com/13799
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-on: https://go-review.googlesource.com/14226
Reviewed-by: Minux Ma <minux@golang.org>

cmd/link/internal/ld: align PE .text section to 32-byte when external linking

Some symbols, for example, masks requires 16-byte alignment, and
they are placed in the text section. Before this change, the text
section is only aligned to 4-byte, and it's making masks unaligned.

Fixes #12415.

Change-Id: I7767778d1b4f7d3e74c2719a02848350782a4160
Reviewed-on: https://go-review.googlesource.com/14166
Run-TryBot: Minux Ma <minux@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit 821e124c24c2b2d753be22a04a3b20b7bf579627)
Reviewed-on: https://go-review.googlesource.com/14279

[release-branch.go1.5] build: Fix bootstrap.bash for official source tarballs

At the moment, bootstrap.bash assumes it is called from a git working
copy. Hence, it fails to complete when running in an unpacked official
source tarball where .git and .gitignore do not exist. This fix adds a
test for existence for .git and a -f switch for the removal of
.gitignore.

Fixes #12223

Change-Id: I7f305b83b38d5115504932bd38dadb7bdeb5d487
Reviewed-on: https://go-review.googlesource.com/13770
Reviewed-by: Dave Cheney <dave@cheney.net>
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-on: https://go-review.googlesource.com/14281

[release-branch.go1.5] net: add -lsendfile to cgo LDFLAGS for solaris

Fixes external linking of net/http tests (or anything that uses
sendfile).

Fixes #12390.

Change-Id: Iee08998cf66e7b0ce851db138a00ebae6dc2395e
Reviewed-on: https://go-review.googlesource.com/14072
Reviewed-by: Dave Cheney <dave@cheney.net>
Reviewed-by: Aram Hăvărneanu <aram@mgk.ro>
Reviewed-on: https://go-review.googlesource.com/14246
Run-TryBot: Chris Broadfoot <cbro@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>

[release-branch.go1.5] doc: add Go Security Policy document

Bring in the text from the proposal (with minor edits):
https://github.com/golang/proposal/blob/master/design/11502-securitypolicy.md

Fixes #11502

Change-Id: I92a987be66a0df60c1fad6c6c79f89bd8e9c12a8
Reviewed-on: https://go-review.googlesource.com/13955
Reviewed-by: Jason Buberel <jbuberel@google.com>
Reviewed-on: https://go-review.googlesource.com/14224
Reviewed-by: Andrew Gerrand <adg@golang.org>

[release-branch.go1.5] doc: only show Share button when enabled

Change-Id: I571965bc38a8b1060642a942b898797327f0c19c
Reviewed-on: https://go-review.googlesource.com/14195
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-on: https://go-review.googlesource.com/14199
Reviewed-by: Chris Broadfoot <cbro@golang.org>

[release-branch.go1.5] go1.5

This updates the VERSION file.
The release proper has not happened yet.

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

[release-branch.go1.5] release: merge master branch into release-branch.go1.5.

Using merge instead of cherry-picks to simplify initial release.
Minor releases like Go 1.5.1 will have to use cherry-picks.

Fixes #12093.

Change-Id: If00393c58ace0da6f359b387cea9b779b123b920

doc: document Go 1.5 on release page

This makes sure the release page in the release will mention the release.

Fixes #12102.

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

net: respect go vs cgo resolver selection in all lookup routines

This is especially important for LookupAddr, which used to be pure Go
(lightweight, one goroutine per call) and without this CL is now
unconditionally cgo (heavy, one thread per call).

Fixes #12190.

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

net: force LookupAddr results to be rooted DNS paths when using cgo

Go 1.4 and before have always returned DNS names with a trailing dot
for reverse lookups, as they do for basically all other routines returning
DNS names. Go 1.4 and before always implemented LookupAddr using
pure Go (not C library calls).

Go 1.5 added the ability to make a C library call to implement LookupAddr.
Unfortunately the C library call returns a DNS name without a trailing dot
(an unrooted name), meaning that if turn off cgo during make.bash then
you still get the rooted name but with cgo on you get an unrooted name.
The unrooted name is inconsistent with the pure Go implementation
and with all previous Go releases, so change it to a rooted name.

Fixes #12189.

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

net: document GODEBUG=netdns=xxx settings

Fixes #12191.

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

doc: fix typos in go1.5.html

Thanks to Nathan Youngman for spotting them.

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

doc/go1.5.html: refer to ppc64 as 64-bit PowerPC, not Power 64

Saying "Power 64" was wrong for reasons I don't remember.
(Those reasons are why we stopped using GOARCH=power64.)

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

doc: adjust binary install page supported system list

Make clear that this list is the list of supported systems
for binary distributions, and that other systems may be
able to build the distribution from source, in addition
to using gccgo.

Drop freebsd/arm from the list on this page.
We have never issued a binary distribution for freebsd/arm,
and we're not going to start in Go 1.5, since we don't even
have a working builder for it.

Drop freebsd/386 from the list on the page,
because we are unable to build binary distributions, per adg.

I think the wording here should probably be revised further,
but not now.

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

cmd/vet: power64 is now ppc64

This was missed when we did the rename months ago
because cmd/vet did not live in the main tree.
Now vet's asmdecl checks will apply to ppc64 assembly too.

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

cmd/go: really skip TestNoteReading on linux/ppc64le

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

cmd/go: disable TestNoteReading on solaris, linux/ppc64le

Update #11184 (linux/ppc64).
Filed #12178 (solaris) for Go 1.6.

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

cmd/compile: fix interaction between GOEXPERIMENT=fieldtrack and race detector

Tested by hand.
Only lines of code changing are protected by Fieldtrack_enabled > 0,
which is never true in standard Go distributions.

Fixes #12171.

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

cmd/go: fix vendor-related index out of range panic on bad file tree

Fixes #12156.

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

cmd/go: fix spurious rebuild of binaries using cgo on OS X

The text segment starts farther into the binary when using
external linking on the mac. Test and fix.

Fixes #12173.

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

cmd/yacc: fix compile error in empty grammar

Fixes #12154.

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

net/http: fix races cloning TLS config

Found in a Google program running under the race detector.
No test, but verified that this fixes the race with go run -race of:

package main

import (
        "crypto/tls"
        "fmt"
        "net"
        "net/http"
        "net/http/httptest"
)

func main() {
        for {
                ts := httptest.NewTLSServer(http.HandlerFunc(func(rw http.ResponseWriter, r *http.Request) {}))
                conf := &tls.Config{} // non-nil
                a, b := net.Pipe()
                go func() {
                        sconn := tls.Server(a, conf)
                        sconn.Handshake()
                }()
                tr := &http.Transport{
                        TLSClientConfig: conf,
                }
                req, _ := http.NewRequest("GET", ts.URL, nil)
                _, err := tr.RoundTrip(req)
                println(fmt.Sprint(err))
                a.Close()
                b.Close()
                ts.Close()
        }
}

Also modified cmd/vet to report the copy-of-mutex bug statically
in CL 13646, and fixed two other instances in the code found by vet.
But vet could not have told us about cloneTLSConfig vs cloneTLSClientConfig.

Confirmed that original report is also fixed by this.

Fixes #12099.

Change-Id: Iba0171549e01852a5ec3438c25a1951c98524dec
Reviewed-on: https://go-review.googlesource.com/13453
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>

doc: only the Logger.SetOutput method is new in Go 1.5

The SetOutput function has been there since Go 1.

Fixes #12162.

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

sort: Fix typo in Stable() comment

Correct 'an' to 'on' in the comment above the Stable() function.

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

cmd/compile/internal/arm64: remove Reginuse check in clearfat

Fixes golang/go#12133

CL 13630 fixed the use of a stale reg[] array in the various arch
backends which was causing the check in clearfat to pass
unconditionally on arm64.

With this check fixed, arm64 now considers REGRT1 to always be in use
as it is part of the reserved register set, see arm64/gsubr.go.

However, ppc64 does not consider REGRT1 and REGRT2 to be part of its
reserved set, so its identical clearfat check passes.

This CL removes the Reginuse check inside clearfat as REGRT1 is
guarenteed always be free on arm64.

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

cmd/trace: fix static file reference

Use runtime.GOROOT instead of os.Getenv("GOROOT") to reference
trace-viewer html file. GOROOT env var is not necessary set,
runtime.GOROOT has a default value for such case.

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

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>

[release-branch.go1.5] cmd/newlink: remove from release branch

Change-Id: Iad86bde6f2e0482745a4000ec4e192ade352983b
Reviewed-on: https://go-review.googlesource.com/13292
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Andrew Gerrand <adg@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

[release-branch.go1.5] go1.5rc1

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