LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/123390043

In cgo, now that recursive calls to typeConv.Type() always work,
we can more robustly calculate the array sizes based on the size
of our element type.

Also, in debug/dwarf, the decision to call zeroType is made
based on a type's usage	within a particular struct, but dwarf.Type
values are cached in typeCache, so the modification might affect
uses of the type in other structs.  Current compilers don't appear
to share DWARF type entries for "[]foo" and "[0]foo", but they also
don't consistently share type entries in other cases.  Arguably
modifying the types is an improvement in some cases, but varying
translated types according to compiler whims seems like a bad idea.

Lastly, also in debug/dwarf, zeroType only needs to rewrite the
top-level dimension, and only if the rest of the array size is
non-zero.

Fixes #8428.

LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/127980043

Restore https://golang.org/cl/41040043 after GC rewrite.
Original description:
On the plus side, we don't need to change the bits on malloc and free.
On the downside, we need to mark objects in the free lists during GC.
But the free lists are small at GC time, so it should be a net win.

benchmark             old ns/op     new ns/op     delta
BenchmarkMalloc8      21.9          20.4          -6.85%
BenchmarkMalloc16     31.1          29.6          -4.82%

LGTM=khr
R=khr
CC=golang-codereviews, rlh, rsc
https://golang.org/cl/122280043

Basically this cleanup replaces all the usage usages of strcmp() == 0,
found by the following command line:

$ grep -R strcmp cmd/dist | grep "0"

LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/123330043

LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/128170043

LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/125170044

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/129040043

The file is used by assembly code to define symbols like NOSPLIT.
Having it hidden inside the cmd directory makes it hard to access
outside the standard repository.
Solution: As with a couple of other files used by cgo, copy the
file into the pkg directory and add a -I argument to the assembler
to access it. Thus one can write just
        #include "textflag.h"
in .s files.

The names in runtime are not updated because in the boot sequence the
file has not been copied yet when runtime is built. All other .s files
in the repository are updated.

Changes to doc/asm.html, src/cmd/dist/build.c, and src/cmd/go/build.go
are hand-made. The rest are just the renaming done by a global
substitution. (Yay sam).

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/128050043

This allows implementing address-of-global
as a pc-relative address instead of as a
32-bit integer constant.

LGTM=rminnich, iant
R=golang-codereviews, rminnich, iant
CC=golang-codereviews
https://golang.org/cl/128070045

Fixes #7453.

LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/127210043

This allows changing the addressing mode for constant
global addresses to use pc-relative addressing.

LGTM=rminnich, iant
R=golang-codereviews, rminnich, iant
CC=golang-codereviews
https://golang.org/cl/129830043

You talked me into it. This and other links should be updated
once the new import paths for the subrepos are established.

LGTM=minux
R=golang-codereviews, minux
CC=golang-codereviews
https://golang.org/cl/124260043

Add a clause to the doc comment for the package and a
paragraph in the compatibility document explaining the
situation.

LGTM=bradfitz, adg, rsc
R=golang-codereviews, adg, bradfitz, minux, rsc
CC=golang-codereviews
https://golang.org/cl/129820043

codeblk and datblk were truncating their
arguments to int32. Don't do that.

LGTM=dvyukov, rminnich
R=iant, dvyukov, rminnich
CC=golang-codereviews
https://golang.org/cl/126050043

See golang.org/s/go14customimport for design.

Added case to deps_test to allow go/build to import regexp.
Not a new dependency, because go/build already imports go/doc
which imports regexp.

Fixes #7453.

LGTM=r
R=r, josharian
CC=golang-codereviews
https://golang.org/cl/124940043

LGTM=r
R=r, rsc
CC=golang-codereviews
https://golang.org/cl/126060043

Adds internal/syscall package.

Fixes #8520

LGTM=r, agl
R=agl, rsc, r
CC=golang-codereviews, iant
https://golang.org/cl/123260044

Turns out to be unused as well.

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews, khr
https://golang.org/cl/127170044

It's unclear why we do this broken double-checked locking.
The mutex is not held for the whole duration of CPU profiling.
Fixes #8365.

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/116290043

Fixes #7757.
Fixes #8488.

LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/118690044

This function does not have a declaration/prototype in a.h, and it is used only
in buf.c, so it is local to it and thus can be marked as private by adding
'static' to it.

LGTM=iant
R=rsc, iant
CC=golang-codereviews
https://golang.org/cl/122300043

Generated by a+c.

LGTM=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/125960043

misc/cgo/testgodefs was added by revision d1cf884a594f, but not
add to run.bash.

LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/129760044

Fixes #5242.

LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/125120043

This makes GCC behavior (and cgo build failures) deterministic.

Fixes #8487.

Ran this shell command on linux/amd64 (Ubuntu 12.04) before and
after this change:

    for x in `seq 100`; do
      go tool cgo -debug-gcc=true issue8441.go 2>&1 | md5sum
    done | sort | uniq -c

Before:
    67 2cdcb8c7c4e290f7d9009abc581b83dd  -
    10 9a55390df94f7cec6d810f3e20590789  -
    10 acfad22140d43d9b9517bbc5dfc3c0df  -
    13 c337f8fee2304b3a8e3158a4362d8698  -

After:
    100 785c316cbcbcd50896695050e2fa23c1  -

LGTM=minux, iant
R=golang-codereviews, bradfitz, minux, iant
CC=golang-codereviews
https://golang.org/cl/126990043

Tested against GnuTLS and Python.

LGTM=agl
R=golang-codereviews, agl, ashankar
CC=agl, golang-codereviews
https://golang.org/cl/117100043

Our other CloseFlushers (archive/tar, compress/flate) do mention this.

The original change was accidentally submitted to the release branch:
        https://golang.org/cl/117430043/

TBR=rsc
R=r, rsc
CC=golang-codereviews
https://golang.org/cl/124130043

LGTM=rsc
R=gri, rsc
CC=golang-codereviews
https://golang.org/cl/127950043

Fixes #8510.

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/129720043

Replaces CL 123980043 which I created on the dev.power64 branch.

LGTM=rsc
R=rsc, iant
CC=golang-codereviews
https://golang.org/cl/123120043

LGTM=bradfitz, rsc
R=rsc, iant, bradfitz
CC=golang-codereviews
https://golang.org/cl/126940043

Generated by a+c.

R=gobot
CC=golang-codereviews
https://golang.org/cl/124120043

Credit to Rémy for finding and writing test case.

Fixes #8325.

LGTM=r
R=golang-codereviews, r
CC=dave, golang-codereviews, iant, remyoudompheng
https://golang.org/cl/124950043

The >>1 shift needs to happen before converting to int32, otherwise
large values will decode with an incorrect sign bit.

The <<31 shift can happen before or after, but before is consistent
with liblink and the go12symtab doc.

Bug demo at http://play.golang.org/p/jLrhPUakIu

LGTM=rsc
R=golang-codereviews, minux, rsc
CC=golang-codereviews
https://golang.org/cl/119630043

CC=golang-codereviews
https://golang.org/cl/124050043

Generated by a+c.

R=gobot
CC=golang-codereviews
https://golang.org/cl/127800043

When formatting time zone offsets with seconds using the stdISO8601Colon
and stdNumColon layouts, the colon was missing between the hour and minute
parts.

Fixes #8497.

LGTM=r
R=golang-codereviews, iant, gobot, r
CC=golang-codereviews
https://golang.org/cl/126840043

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/124020044

There was a number of improvements related to GC parallelization:
1. Parallel roots/stacks scanning.
2. Parallel stack shrinking.
3. Per-thread workbuf caches.
4. Workset reduction.
Currently 32 threads work well.
go.benchmarks:garbage benchmark on 2 x Intel Xeon E5-2690 (16 HT cores)

1 thread/1 processor:
time=16405255
cputime=16386223
gc-pause-one=546793975
gc-pause-total=3280763

2 threads/1 processor:
time=9043497
cputime=18075822
gc-pause-one=331116489
gc-pause-total=2152257

4 threads/1 processor:
time=4882030
cputime=19421337
gc-pause-one=174543105
gc-pause-total=1134530

8 threads/1 processor:
time=4134757
cputime=20097075
gc-pause-one=158680588
gc-pause-total=1015555

16 threads/1 processor + HT:
time=2006706
cputime=31960509
gc-pause-one=75425744
gc-pause-total=460097

16 threads/2 processors:
time=1513373
cputime=23805571
gc-pause-one=56630946
gc-pause-total=345448

32 threads/2 processors + HT:
time=1199312
cputime=37592764
gc-pause-one=48945064
gc-pause-total=278986

LGTM=rlh
R=golang-codereviews, tracey.brendan, rlh
CC=golang-codereviews, khr, rsc
https://golang.org/cl/123920043

Update #8092

LGTM=dvyukov
R=golang-codereviews, minux, dvyukov
CC=golang-codereviews
https://golang.org/cl/122250043