Fix the output of build -n when adding to an existing archive with the
gc toolchain by observing that we are, now, always doing that.  When
using the gc toolchain the archive is now always created by the Go
compiler, and never by the pack command.

No test because we have not historically tested build -n output.

Fixes #13118.

Change-Id: I3a5c43cf45169fa6c9581e4741309c77d2b6e58b
Reviewed-on: https://go-review.googlesource.com/16761Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: David Crawshaw <crawshaw@golang.org>

Add Alberto Bertogli (individual CLA)
Add Alexander Demakin (individual CLA)
Add Angelo Bulfone (individual CLA)
Add Anthony Canino (individual CLA)
Add Arnout Engelen (individual CLA)
Add Cedric Staub (corporate CLA for Square, Inc.)
Add Dan Caddigan (individual CLA)
Add Dan Jacques (corporate CLA for Google Inc.)
Add Daniel Skinner (individual CLA)
Add David Howden (individual CLA)
Add Dmitry Yakunin (individual CLA)
Add Emmanuel Odeke (individual CLA)
Add Eric Koleda (corporate CLA for Google Inc.)
Add Erik Dubbelboer (individual CLA)
Add Evan Broder (corporate CLA for Stripe, Inc.)
Add Ford Hurley (individual CLA)
Add Francisco Claude (individual CLA)
Add Gaurish Sharma (individual CLA)
Add Hsin-Ho Yeh (individual CLA)
Add Ian Gudger (individual CLA)
Add Ilya Tocar (corporate CLA for Intel Corporation)
Add John Jenkins (individual CLA)
Add Kenny Grant (individual CLA)
Add Kevin Malachowski (corporate CLA for Google Inc.)
Add Kim Shrier (corporate CLA for RackTop Systems Inc.)
Add Klaus Post (individual CLA)
Add Lewin Bormann (individual CLA)
Add Manu S Ajith (individual CLA)
Add Matt Drollette (individual CLA)
Add Meng Zhuo (individual CLA)
Add Mhd Sulhan (individual CLA)
Add Mohit Agarwal (individual CLA)
Add Nathan Otterness (individual CLA)
Add Nathan VanBenschoten (individual CLA)
Add Paul Hankin (corporate CLA for Google Inc.)
Add Paul Meyer (individual CLA)
Add Pavel Paulau (individual CLA)
Add Ralph Corderoy (individual CLA)
Add Rob Norman (individual CLA)
Add Seth Hoenig (individual CLA)
Add Spencer Nelson (individual CLA)
Add Steve Phillips (individual CLA)
Add Thorben Krueger (individual CLA)
Add Tormod Erevik Lea (individual CLA)
Add Will Chan (corporate CLA for Google Inc.)
Add Yao Zhang (individual CLA)
Add Yasuharu Goto (individual CLA)
Add Yuki Yugui Sonoda (corporate CLA for Google Inc.)

Updates #12042

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

Revert "cmd/internal/obj/arm64, cmd/link: use two instructions rather than three for loads from memory"

This reverts commit 3a9bc571.

Breaks darwin/arm64.

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

Fixes #12078

Change-Id: If09c927fae639ec4ed3894a2b393a87c1e677803
Reviewed-on: https://go-review.googlesource.com/16829
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>

Fixes #12078

Change-Id: Ia8738123b07ca29be4a0cf400ee143729c8b5b3c
Reviewed-on: https://go-review.googlesource.com/16860Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

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

Change-Id: I4903014f2883d3f52a75a3500dc9e01a5cad8611
Reviewed-on: https://go-review.googlesource.com/16904
Run-TryBot: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

The gzip package is asymmetrical in the way it handles headers.
In Writer, the Header is written on the first call to Write, Flush, or Close.
In Reader, the Header is read on calls to NewReader or Reset as opposed to
after the first Read. Thus, we document this difference.

Fixes #13211

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

Fixes #12540.

Change-Id: I7893fdc023145b0aca4b4c7df7e08e47edcf5bba
Reviewed-on: https://go-review.googlesource.com/16902
Run-TryBot: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

Allows removing fields that aren't relevant to a particular OS or
changing their types to match the underlying OS system calls they'll
be used for.

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

so that GO_TEST_TIMEOUT_SCALE can be applied too.
It's for the mips64 builder, which is so slow that the
go1 benchmark can't finish startup within 10 minutes.

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

Replaces PID in PaxHeaders with 0.  Sorts PAX header keys before writing
them to the archive.

Fixes #12358

Change-Id: If239f89c85f1c9d9895a253fb06a47ad44960124
Reviewed-on: https://go-review.googlesource.com/13975Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Joe Tsai <joetsai@digital-static.net>

We're allocating TLS storage for m0 anyway, so might as well use it.

Change-Id: I7dc20bbea5320c8ab8a367f18a9540706751e771
Reviewed-on: https://go-review.googlesource.com/16890
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Fixes #13198

The output of netsh is encoded with ANSI encoding. So doesn't match with UTF-8 strings.
Write output as UTF-8 using powershell.

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

It doesn't seem to help on modern processors and it makes Go impossible to run
on Pentium MMX (which is the documented minimum hardware requirement.)

Old is with prefetch, new is w/o. Both are compiled with GO386=sse2.
Benchmarking is done on Intel(R) Core(TM) i5-3570K CPU @ 3.40GHz.

name                     old time/op    new time/op    delta
BinaryTree17-4              2.89s ± 2%     2.87s ± 0%    ~     (p=0.061 n=11+10)
Fannkuch11-4                3.65s ± 0%     3.65s ± 0%    ~     (p=0.365 n=11+11)
FmtFprintfEmpty-4          52.1ns ± 0%    52.1ns ± 0%    ~      (p=0.065 n=10+9)
FmtFprintfString-4          168ns ± 0%     167ns ± 0%  -0.48%   (p=0.000 n=8+10)
FmtFprintfInt-4             167ns ± 0%     167ns ± 1%    ~      (p=0.591 n=9+10)
FmtFprintfIntInt-4          295ns ± 0%     292ns ± 0%  -0.99%   (p=0.000 n=9+10)
FmtFprintfPrefixedInt-4     327ns ± 0%     326ns ± 0%  -0.24%  (p=0.007 n=10+10)
FmtFprintfFloat-4           431ns ± 0%     431ns ± 0%  -0.07%  (p=0.000 n=10+11)
FmtManyArgs-4              1.13µs ± 0%    1.13µs ± 0%  -0.37%  (p=0.009 n=11+11)
GobDecode-4                9.36ms ± 1%    9.33ms ± 0%  -0.31%  (p=0.006 n=11+10)
GobEncode-4                7.38ms ± 1%    7.38ms ± 1%    ~     (p=0.797 n=11+11)
Gzip-4                      394ms ± 0%     395ms ± 1%    ~     (p=0.519 n=11+11)
Gunzip-4                   65.4ms ± 0%    65.4ms ± 0%    ~     (p=0.739 n=10+10)
HTTPClientServer-4         52.4µs ± 1%    52.5µs ± 1%    ~     (p=0.748 n=11+11)
JSONEncode-4               19.0ms ± 0%    19.0ms ± 0%    ~      (p=0.780 n=9+10)
JSONDecode-4               59.6ms ± 0%    59.6ms ± 0%    ~      (p=0.720 n=9+10)
Mandelbrot200-4            4.09ms ± 0%    4.09ms ± 0%    ~      (p=0.295 n=11+9)
GoParse-4                  3.45ms ± 1%    3.43ms ± 1%  -0.35%  (p=0.040 n=11+11)
RegexpMatchEasy0_32-4       101ns ± 1%     101ns ± 1%    ~     (p=1.000 n=11+11)
RegexpMatchEasy0_1K-4       796ns ± 0%     796ns ± 0%    ~      (p=0.954 n=10+8)
RegexpMatchEasy1_32-4       110ns ± 0%     110ns ± 1%    ~      (p=0.289 n=9+11)
RegexpMatchEasy1_1K-4       991ns ± 0%     991ns ± 0%    ~      (p=0.784 n=10+8)
RegexpMatchMedium_32-4      131ns ± 0%     130ns ± 0%  -0.42%   (p=0.004 n=11+9)
RegexpMatchMedium_1K-4     41.9µs ± 1%    41.6µs ± 0%    ~      (p=0.067 n=11+9)
RegexpMatchHard_32-4       2.34µs ± 0%    2.34µs ± 0%    ~     (p=0.208 n=11+11)
RegexpMatchHard_1K-4       70.9µs ± 0%    71.0µs ± 0%    ~      (p=0.968 n=9+10)
Revcomp-4                   819ms ± 0%     818ms ± 0%    ~     (p=0.251 n=10+11)
Template-4                 73.9ms ± 0%    73.8ms ± 0%  -0.25%  (p=0.013 n=10+11)
TimeParse-4                 414ns ± 0%     414ns ± 0%    ~     (p=0.809 n=11+10)
TimeFormat-4                485ns ± 0%     485ns ± 0%    ~      (p=0.404 n=11+7)

name                     old speed      new speed      delta
GobDecode-4              82.0MB/s ± 1%  82.3MB/s ± 0%  +0.31%  (p=0.007 n=11+10)
GobEncode-4               104MB/s ± 1%   104MB/s ± 1%    ~     (p=0.797 n=11+11)
Gzip-4                   49.2MB/s ± 0%  49.1MB/s ± 1%    ~     (p=0.507 n=11+11)
Gunzip-4                  297MB/s ± 0%   297MB/s ± 0%    ~     (p=0.670 n=10+10)
JSONEncode-4              102MB/s ± 0%   102MB/s ± 0%    ~      (p=0.794 n=9+10)
JSONDecode-4             32.6MB/s ± 0%  32.6MB/s ± 0%    ~       (p=0.334 n=9+9)
GoParse-4                16.8MB/s ± 1%  16.9MB/s ± 1%    ~     (p=0.052 n=11+11)
RegexpMatchEasy0_32-4     314MB/s ± 0%   314MB/s ± 1%    ~     (p=0.618 n=11+11)
RegexpMatchEasy0_1K-4    1.29GB/s ± 0%  1.29GB/s ± 0%    ~     (p=0.315 n=10+10)
RegexpMatchEasy1_32-4     290MB/s ± 1%   290MB/s ± 1%    ~     (p=0.667 n=10+11)
RegexpMatchEasy1_1K-4    1.03GB/s ± 0%  1.03GB/s ± 0%    ~      (p=0.829 n=10+8)
RegexpMatchMedium_32-4   7.63MB/s ± 0%  7.65MB/s ± 0%    ~     (p=0.142 n=11+11)
RegexpMatchMedium_1K-4   24.4MB/s ± 1%  24.6MB/s ± 0%    ~      (p=0.063 n=11+9)
RegexpMatchHard_32-4     13.7MB/s ± 0%  13.7MB/s ± 0%    ~     (p=0.302 n=11+11)
RegexpMatchHard_1K-4     14.4MB/s ± 0%  14.4MB/s ± 0%    ~      (p=0.784 n=9+10)
Revcomp-4                 310MB/s ± 0%   311MB/s ± 0%    ~     (p=0.243 n=10+11)
Template-4               26.2MB/s ± 0%  26.3MB/s ± 0%  +0.24%  (p=0.009 n=10+11)

Update #12970.

Change-Id: Id185080687a60c229a5cb2e5220e7ca1b53910e2
Reviewed-on: https://go-review.googlesource.com/15999Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

Fixes #12391.

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

Change-Id: I4d079d29408e5344701056c88882cfd3b3857478
Reviewed-on: https://go-review.googlesource.com/15973Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>

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

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

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

Change-Id: Ifba76413b8aa78a221385bf505b92a3a5fbc3d24
Reviewed-on: https://go-review.googlesource.com/16713Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

This requires changing the tls access code to match the patterns documented in
the ABI documentation or the system linker will "optimize" it into ridiculousness.

With this change, -buildmode=pie works, although as it is tested in testshared,
the tests are not run yet.

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

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

The PowerPC ISA does not have a PC-relative load instruction, which poses
obvious challenges when generating position-independent code. The way the ELFv2
ABI addresses this is to specify that r2 points to a per "module" (shared
library or executable) TOC pointer. Maintaining this pointer requires
cooperation between codegen and the system linker:

 * Non-leaf functions leave space on the stack at r1+24 to save the TOC pointer.
 * A call to a function that *might* have to go via a PLT stub must be followed
   by a nop instruction that the system linker can replace with "ld r1, 24(r1)"
   to restore the TOC pointer (only when dynamically linking Go code).
 * When calling a function via a function pointer, the address of the function
   must be in r12, and the first couple of instructions (the "global entry
   point") of the called function use this to derive the address of the TOC
   for the module it is in.
 * When calling a function that is implemented in the same module, the system
   linker adjusts the call to skip over the instructions mentioned above (the
   "local entry point"), assuming that r2 is already correctly set.

So this changeset adds the global entry point instructions, sets the metadata so
the system linker knows where the local entry point is, inserts code to save the
TOC pointer at 24(r1), adds a nop after any call not known to be local and copes
with the odd non-local code transfer in the runtime (e.g. the stuff around
jmpdefer). It does not actually compile PIC yet.

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

darwin/386, freebsd/386, and linux/386 use a setldt system call to
setup each M's thread-local storage area, and they need access to the
M's id for this.  The current code copies m.id into m.tls[0] (and this
logic has been cargo culted to OSes like NetBSD and OpenBSD, which
don't even need m.id to configure TLS), and then the 386 assembly
loads m.tls[0]... but since the assembly code already has a pointer to
the M, it might as well just load m.id directly.

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

The larger stack frames causes the nosplit stack to overflow so the next change
increases the stackguard.

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

Larger stack frames mean nosplit functions use more stack and so the limit
needs to increase.

The change to test/nosplit.go is a bit ugly but I can't really think of a
way to make it nicer.

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

Apparently its last use was removed in CL 8899.

Change-Id: I4f3a789b3cc4c249582e81463af62b576a281e40
Reviewed-on: https://go-review.googlesource.com/16880
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

The new revision is 389d49d4943780efbfcd2a434f4462b6d0f23c44 (Nov 13, 2015).
The runtimes are built using the new x/build/cmd/racebuild utility.
This update fixes a bug in race detection algorithm that can
lead to occasional false negatives (#10589). But generally just
brings in an up-to-date runtime.

Update #8653
Fixes #10589

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

Change-Id: I37bac9680efdfd797ca5dca90bd9a9e1001bfb68
Reviewed-on: https://go-review.googlesource.com/16874Reviewed-by: Michael Matloob <matloob@golang.org>

As per mdempsky's comment on golang.org/cl/14204, textflag.h is
copied to the includes dir by cmd/dist, and the copy in
runtime/internal/atomic is not actually being used.

Updates #11647

Change-Id: Ie95c08903a9df54cea4c70ee9d5291176f7b5609
Reviewed-on: https://go-review.googlesource.com/16871
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

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/16853Reviewed-by: Russ Cox <rsc@golang.org>

Fixes #7864

Change-Id: Id13369352aeccac8387876f0b911e383c543c28e
Reviewed-on: https://go-review.googlesource.com/16714Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Russ Cox <rsc@golang.org>

Fixes #10802

Compare Volume name and each path elements using strings.EqualFold.

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

Change-Id: I22216df83898e560cfe6d97344f05e3678c2db99
Reviewed-on: https://go-review.googlesource.com/16872Reviewed-by: Michael Matloob <matloob@golang.org>

Somehow these were left out of the orignial CL.

Updates #11647

Change-Id: I058a30eaa25fbb72d60e7fb6bc9ff0a3b54fdb2a
Reviewed-on: https://go-review.googlesource.com/16870Reviewed-by: Minux Ma <minux@golang.org>

Calling flag.Parse twice can be problematic if other goroutines called
flag.Parsed in between: the race detector complains due to the
write after read from a different goroutine.

This can happen if TestMain calls flag.Parse and launches goroutines
that call flag.Parsed, for example if it initializes a server which
checks flags.

This patch makes testing.M.Run only parse the flags if they have not
been parsed already.

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

The heap profile is only guaranteed to be up-to-date after two GC
cycles, so force two GCs instead of just one.

Updates #13098.

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

I made a copy of the per-arch _CacheLineSize definitons when checking in
runtime/internal/atomic. Now that runtime/internal/sys is checked in,
we can use the definition there.

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

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/16819Reviewed-by: Daniel Morsing <daniel.morsing@gmail.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>