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>

This reverts commit bc1f9d20.

The current go-get strategy doesn't support cases that servers
cannot handle shallow clients.

Also, `go get -u` is broken and is not compatible with already
go-getted unshallow repos.

Fixes #13213.
Fixes #13206.

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

The file was automatically placed in the cl by a tool I had built.
Since the compiler doesn't hook into the atomic package, it's unnecessary.

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

I keep losing this utility, used as part of other tools to auto-update
the AUTHORS and CONTRIBUTORS files.  Check it in to the repo so I
don't lose it, and so others can use it as well.

Updates #12042

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

Fixes #13214.

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

runtime/internal/sys will hold system-, architecture- and config-
specific constants.

Updates #11647

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

The heapsampling.go test occasionally fails on some architectures
because it finds zero heap samples in main.alloc. This happens because
the byte and object counts are only updated at a GC. Hence, if a GC
happens part way through allocInterleaved, but then doesn't happen
after we start calling main.alloc, checkAllocations will see buckets
for the lines in main.alloc (which are created eagerly), but the
object and byte counts will be zero.

Fix this by forcing a GC to update the profile before we collect it.

Fixes #13098.

Change-Id: Ia7a9918eea6399307f10499dd7abefd4f6d13cf6
Reviewed-on: https://go-review.googlesource.com/16846
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

Correct an error in the last change: it caused runtime/cgo and
runtime/race to not depend on runtime.

Fixes #13214.

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

Explictly list the alternative formats in each file.  In AUTHORS, refer
to CONTRIBUTORS' definition of multiple email addresses.  Indent with
four spaces;  AUTHORS used a tab, but CONTRIBUTORS used four spaces.
s/Rietveld/Gerrit/

Change the tab separating Sebastien Binet from his email address,
added in 2010's 18b02f6c.

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

lfstack.go:19: println call ends with newline

Change-Id: I2a903eef80a5300e9014999c2f0bc5d40ed5c735
Reviewed-on: https://go-review.googlesource.com/16836
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>

cgo_ppc64x.go:7: +build comment must appear before package clause and be followed by a blank line

Change-Id: Ib6dedddae70cc75dc3f137eb37ea338a64f8b595
Reviewed-on: https://go-review.googlesource.com/16835
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Andrew Gerrand <adg@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

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

Change-Id: I22ea3352ad0794fc611334c2f2ec5f1e894985ce
Reviewed-on: https://go-review.googlesource.com/14460Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>