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

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

For Solaris. Sigh.

LGTM=dave
R=aram, iant, dave
CC=golang-codereviews
https://golang.org/cl/129540043

Also: use 0x644 file permission if a new file
is created (should not happen anymore, though).

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

Simplify the invocation (and speed it up substantially) in preparation
for move to go generate.

LGTM=bradfitz, mpvl
R=mpvl, bradfitz, josharian
CC=golang-codereviews
https://golang.org/cl/135790043

Fixes #8143.

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

Post-submit glitches caught by reviewers.

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

Once and for all.
Broken in cl/108640043.
I've messed it before. To test scavenger-related changes
one needs to alter the constants during final testing.
And then it's very easy to submit with the altered constants.

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

Deleted in cl/123700044.
I am not sure whether I need to restore it,
or delete rest of the uses...

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

Fixes #8261

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

Fixes #8576.

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

Before, a slice with cap=0 or a string with len=0 might have its
base pointer pointing beyond the actual slice/string data into
the next block. The collector had to ignore slices and strings with
cap=0 in order to avoid misinterpreting the base pointer.

Now, a slice with cap=0 or a string with len=0 still has a base
pointer pointing into the actual slice/string data, no matter what.
The collector can now always scan the pointer, which means
strings and slices are no longer special.

Fixes #8404.

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

Fixes test failure in build, probably a good idea anyway.

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

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

It was respected by unmarshal, but not marshal, so they didn't
round-trip.

Fixes #8582

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

Followup to CL 128700043.

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

A whole thread is too much for background scavenger that sleeps all the time anyway.
We already have sysmon thread that can do this work.
Also remove g->isbackground and simplify enter/exitsyscall.

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

Explain why it's safe to allocate chans with flagNoScan.

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

LGTM=rsc
R=golang-codereviews, ruiu, rsc, daniel.morsing
CC=golang-codereviews, khr
https://golang.org/cl/123700044

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

LGTM=0intro
R=0intro
CC=golang-codereviews
https://golang.org/cl/131190043

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

Normally, an expression of the form x.f or *y can be reordered
with function calls and communications.

Select is stricter than normal: each channel expression is evaluated
in source order. If you have case <-x.f and case <-foo(), then if the
evaluation of x.f causes a panic, foo must not have been called.
(This is in contrast to an expression like x.f + foo().)

Enforce this stricter ordering.

Fixes #8336.

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

Reduce duration of critical section,
make pcbuf local to function.

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

Part of cl/128670043 that got lost during submit.

TBR=rsc
R=golang-codereviews
CC=golang-codereviews
https://golang.org/cl/129570043