Clang 3.2 and older (as shipped with OS X Mountain Lion and older)
outputs ambiguous DWARF debug info that makes it impossible for us to
reconstruct accurate type information as required for this test.

Fixes #8611.

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

Shrinks the text segment size by about 1.5% for the "go", "gofmt",
and "camlistored" commands on linux/amd64.

Before:
$ size go gofmt camlistored
   text	   data	    bss	    dec	    hex	filename
6506842	 136996	 105784	6749622	 66fdb6	go
2376046	  85232	  90984	2552262	 26f1c6	gofmt
17051050	 190256	 130320	17371626	10911ea	camlistored

After:
$ size go gofmt camlistored
   text	   data	    bss	    dec	    hex	filename
6403034	 136996	 105784	6645814	 656836	go
2331118	  85232	  90984	2507334	 264246	gofmt
16842586	 190256	 130320	17163162	105e39a	camlistored

Fixes #8604.

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

LGTM=0intro, rsc
R=rsc, 0intro
CC=golang-codereviews
https://golang.org/cl/132320043

This is a reapplication of CL 93520045 (changeset 5012df7fac58)
since that was lost during the move to an internal package.

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

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

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

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

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

In revision 05c3fee13eb3, openbsd/386's tfork implementation was
accidentally changed in one instruction from using the "params"
parameter to using the "psize" parameter.

While here, OpenBSD's __tfork system call returns a pid_t which is an
int32 on all OpenBSD architectures, so change runtime.tfork's return
type from int64 to int32 and update the assembly implementations
accordingly.

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

LGTM=dvyukov
R=golang-codereviews, dvyukov, khr
CC=golang-codereviews
https://golang.org/cl/124630043

Package addition.

PositionFor permits access to both, positions
adjusted by //line comments (like the Position
accessors), and unadjusted "raw" positions
unaffected by //line comments.

Raw positions are required for correct formatting
of source code via go/printer which until now had
to manually fix adjusted positions.

Fixes #7702.

LGTM=adonovan
R=adonovan
CC=golang-codereviews
https://golang.org/cl/135110044

Only grab the lock once, don't allocate, add more tests.

LGTM=ruiu
R=ruiu, josharian
CC=golang-codereviews
https://golang.org/cl/139780043

Follow-up to https://golang.org/cl/107020044/
Also add a little comment.

LGTM=ruiu, josharian
R=josharian, ruiu
CC=golang-codereviews
https://golang.org/cl/139760043

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

Preparation for fixing issue 5769 (method selectors
do not auto-dereference): The actual fix may require
some cleanups in all these sections, and syntactically,
method expressions and method values are selector
expressions. Moving them next to each other so that
it's easy to see the actual changes (next CL).

No content changes besides the section moves.

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

This is getting a little annoying, but once the runtime structs are
being defined in Go, these will go away. So it's only a temporary cost.

TBR=bradfitz
CC=golang-codereviews
https://golang.org/cl/135940043

Significantly reduces the number of allocations, while also
simplifying the code and increasing performance by a 1-2%.

benchmark                          old ns/op     new ns/op     delta
BenchmarkConcurrentDBExec          13290567      13026236      -1.99%
BenchmarkConcurrentStmtQuery       13249399      13008879      -1.82%
BenchmarkConcurrentStmtExec        8806237       8680182       -1.43%
BenchmarkConcurrentTxQuery         13628379      12756293      -6.40%
BenchmarkConcurrentTxExec          4794800       4722440       -1.51%
BenchmarkConcurrentTxStmtQuery     5040804       5200721       +3.17%
BenchmarkConcurrentTxStmtExec      1366574       1336626       -2.19%
BenchmarkConcurrentRandom          11119120      10926113      -1.74%

benchmark                          old allocs     new allocs     delta
BenchmarkConcurrentDBExec          14191          13684          -3.57%
BenchmarkConcurrentStmtQuery       16020          15514          -3.16%
BenchmarkConcurrentStmtExec        4179           3672           -12.13%
BenchmarkConcurrentTxQuery         16025          15518          -3.16%
BenchmarkConcurrentTxExec          12717          12709          -0.06%
BenchmarkConcurrentTxStmtQuery     15532          15525          -0.05%
BenchmarkConcurrentTxStmtExec      2175           2168           -0.32%
BenchmarkConcurrentRandom          12320          11997          -2.62%

benchmark                          old bytes     new bytes     delta
BenchmarkConcurrentDBExec          2164827       2139760       -1.16%
BenchmarkConcurrentStmtQuery       2418070       2394030       -0.99%
BenchmarkConcurrentStmtExec        1728782       1704371       -1.41%
BenchmarkConcurrentTxQuery         2477144       2452620       -0.99%
BenchmarkConcurrentTxExec          588920        588343        -0.10%
BenchmarkConcurrentTxStmtQuery     790866        796578        +0.72%
BenchmarkConcurrentTxStmtExec      98502         98143         -0.36%
BenchmarkConcurrentRandom          1725906       1710220       -0.91%

LGTM=ruiu, dave, bradfitz
R=golang-codereviews, ruiu, gobot, bradfitz, dave, minux
CC=bradfitz, golang-codereviews
https://golang.org/cl/107020044

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

'range hash' makes a copy of the hash array in the stack, creating
a very large stack frame. It's just the right amount that it
uses most but not all of the total stack size. If you have a lot
of environment variables, like the builders, then this is too
much and the g0 stack runs out of space.

TBR=bradfitz
CC=golang-codereviews
https://golang.org/cl/132350043

Fixes #8350.

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

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

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

In order to support different compression levels, make the
encoder type public, and add an Encoder method to it.

Fixes #8499.

LGTM=nigeltao
R=nigeltao, ruiu
CC=golang-codereviews
https://golang.org/cl/129190043

I changed all the NACL_SYSJMP to NACL_SYSCALL in
an earlier CL, but I missed the fact that NACL_SYSCALL
will push another return PC on the stack, so that the
arguments will no longer be in the right place.
Since we have to make our own call, we also have to
copy the arguments. Do that.

Fixes nacl/386 build.

TBR=minux
CC=golang-codereviews
https://golang.org/cl/135050044

This will allow structs containing Efaces in C to be
manipulated as structs containing real interfaces in Go.
The eface struct is still defined for use by Go code.

LGTM=iant
R=golang-codereviews, iant
CC=dvyukov, golang-codereviews, khr, r
https://golang.org/cl/133980044

TBR=iant
CC=golang-codereviews
https://golang.org/cl/133150043

Mutex is consistent with package sync, and when in the
unexported Go form it avoids having a conflcit between
the type (now mutex) and the function (lock).

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

This adds the minimal support for AArch64/arm64 relocations
needed to get cgo to work (when an isomorphic patch is applied
to gccgo) and a test.

This change uses the "AAarch64" name for the architecture rather
than the more widely accepted "arm64" because that's the name that
the relevant docs from ARM such as

   http://infocenter.arm.com/help/topic/com.arm.doc.ihi0056b/IHI0056B_aaelf64.pdf

all use.

Fixes #8533.

LGTM=iant
R=golang-codereviews, aram, gobot, iant, minux
CC=golang-codereviews
https://golang.org/cl/132000043

NaCl requires the addition of a 32-byte "halt sled" at the end
of the text segment. This means that segtext.len is actually
32 bytes shorter than reality. The computation of the file offset
of the end of the data segment did not take this 32 bytes into
account, so if len and len+32 rounded up (by 64k) to different
values, the symbol table overwrote the last page of the data
segment.

The last page of the data segment is usually the C .string
symbols, which contain the strings used in error prints
by the runtime. So when this happens, your program
probably crashes, and then when it does, you get binary
garbage instead of all the usual prints.

The chance of hitting this with a randomly sized text segment
is 32 in 65536, or 1 in 2048.

If you add or remove ANY code while trying to debug this
problem, you're overwhelmingly likely to bump the text
segment one way or the other and make the bug disappear.

Correct all the computations to use segdata.fileoff+segdata.filelen
instead of trying to rederive segdata.fileoff.

This fixes the failure during the nacl/amd64p32 build.

TBR=iant
CC=golang-codereviews
https://golang.org/cl/135050043

The NaCl "system calls" were assumed to have a compatible
return convention with the C compiler, and we were using
tail jumps to those functions. Don't do that anymore.

Correct mistake introduced in newstackcall duringconversion
from (SP) to (FP) notation. (Actually this fix, in asm_amd64p32.s,
slipped into the C compiler change, but update the name to
match what go vet wants.)

Correct computation of caller stack pointer in morestack:
on amd64p32, the saved PC is the size of a uintreg, not uintptr.
This may not matter, since it's been like this for a while,
but uintreg is the correct one. (And on non-NaCl they are the same.)

This will allow the NaCl build to get much farther.
It will probably still not work completely.
There's a bug in 6l that needs fixing too.

TBR=minux
CC=golang-codereviews
https://golang.org/cl/134990043

runtime._sfloat2 now returns the lr value on the stack, not R0.

Credit to Russ Cox for the fix.

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

TBR=minux
CC=golang-codereviews
https://golang.org/cl/137810043

uintptr or uint64 in the runtime C were turning into uint in the Go,
bool was turning into uint8, and so on. Fix that.

Also delete Go wrappers for C functions.
The C functions can be called directly now
(but still eventually need to be converted to Go).

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

Broken by 8b5fc7c59d05.

Update #8092

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

Fixes #8092.

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

sighandler now returns its value on the stack.

TBR=0intro
CC=golang-codereviews
https://golang.org/cl/135900043

nanotime1 is not a Go function and must not store its result at 0(FP).
That overwrites some data owned by the caller.

TBR=aram
CC=golang-codereviews
https://golang.org/cl/138730043

Windows needs the return result in AX, but runtime.sighandler
no longer stores it in AX. Load it back during the assembly trampoline.

TBR=brainman
CC=golang-codereviews
https://golang.org/cl/133980043

The Go calling convention uses more stack space than C.
On 64-bit systems we've been right up against the limit
(128 bytes, so only 16 words) and doing awful things to
our source code to work around it. Instead of continuing
to do awful things, raise the limit to 160 bytes.
I am prepared to raise the limit to 192 bytes if necessary,
but I think this will be enough.

Should fix current link-time stack overflow errors on
        - nacl/arm
        - netbsd/amd64
        - openbsd/amd64
        - solaris/amd64
        - windows/amd64

TBR=r
CC=golang-codereviews, iant
https://golang.org/cl/131450043

It appears to have been accidentally lost when converting
Stack from C to Go in https://golang.org/cl/129510043

LGTM=rsc
R=golang-codereviews
CC=golang-codereviews, josharian, khr, remyoudompheng, rsc
https://golang.org/cl/136870043