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

To date, the C compilers and Go compilers differed only in how
values were returned from functions. This made it difficult to call
Go from C or C from Go if return values were involved. It also made
assembly called from Go and assembly called from C different.

This CL changes the C compiler to use the Go conventions, passing
results on the stack, after the arguments.
[Exception: this does not apply to C ... functions, because you can't
know where on the stack the arguments end.]

By doing this, the CL makes it possible to rewrite C functions into Go
one at a time, without worrying about which languages call that
function or which languages it calls.

This CL also updates all the assembly files in package runtime to use
the new conventions. Argument references of the form 40(SP) have
been rewritten to the form name+10(FP) instead, and there are now
Go func prototypes for every assembly function called from C or Go.
This means that 'go vet runtime' checks effectively every assembly
function, and go vet's output was used to automate the bulk of the
conversion.

Some functions, like seek and nsec on Plan 9, needed to be rewritten.

Many assembly routines called from C were reading arguments
incorrectly, using MOVL instead of MOVQ or vice versa, especially on
the less used systems like openbsd.
These were found by go vet and have been corrected too.
If we're lucky, this may reduce flakiness on those systems.

Tested on:
        darwin/386
        darwin/amd64
        linux/arm
        linux/386
        linux/amd64
If this breaks another system, the bug is almost certainly in the
sys_$GOOS_$GOARCH.s file, since the rest of the CL is tested
by the combination of the above systems.

LGTM=dvyukov, iant
R=golang-codereviews, 0intro, dave, alex.brainman, dvyukov, iant
CC=golang-codereviews, josharian, r
https://golang.org/cl/135830043

Every change to g->atomicstatus is now done atomically so that we can
ensure that all gs pass through a gc safepoint on demand. This allows
the GC to move from one phase to the next safely. In some phases the
stack will be scanned. This CL only deals with the infrastructure that
allows g->atomicstatus to go from one state to another. Future CLs
will deal with scanning and monitoring what phase the GC is in.

The major change was to moving to using a Gscan bit to indicate that
the status is in a scan state. The only bug fix was in oldstack where
I wasn't moving to a Gcopystack state in order to block scanning until
the new stack was in place. The proc.go file is waiting for an atomic
load instruction.

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

TBR=rlh
CC=golang-codereviews
https://golang.org/cl/131410043

Update #8527

Fixes two warnings:

src/cmd/gc/mparith3.c:255:10: runtime error: shift exponent 52 is too large for 32-bit type 'int'
src/cmd/gc/mparith3.c:254:14: runtime error: shift exponent 52 is too large for 32-bit type 'int'

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

Also make genzabbrs.go more self-contained.
Also run it (on Linux; does that matter?) to update the table.

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

LGTM=mpvl, rsc
R=mpvl, rsc
CC=golang-codereviews
https://golang.org/cl/135820043

Generated by a+c.

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

Makes vet happy.

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

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

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

I noticed that 5g doesn't flush the float64 result back to the stack, hence the change in the function signature. I'm wondering if I should also change the signature for the other two functions.

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

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

I can't reproduce the race, but this should fix it.

Fixes #8483

LGTM=dvyukov
R=dvyukov
CC=golang-codereviews
https://golang.org/cl/126610043

There are both many callers and many implementations of these
interfaces, so make the contract explicit. Callers generally
assume this, and at least the standard library and other
implementations obey this, but it's never stated explicitly,
making it somewhat risky to assume.

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

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