The USEFIELD instructions no longer make it to the linker,
so we have to do something else to pin the references
they were pinning. Emit a 0-length relocation of type R_USEFIELD.

Fixes #7486.

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

The move from 4kB to 8kB in Go 1.2 was to eliminate many stack split hot spots.

The move back to 4kB was predicated on copying stacks eliminating
the potential for hot spots.

Unfortunately, the fact that stacks do not copy 100% of the time means
that hot spots can still happen under the right conditions, and the slowdown
is worse now than it was in Go 1.2. There is a real program in issue 8030 that
sees about a 30x slowdown: it has a reflect call near the top of the stack
which inhibits any stack copying on that segment.

Go back to 8kB until stack copying can be used 100% of the time.

Fixes #8030.

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

The float32 const conversion used to round to float64
and then use the hardware to round to float32.
Even though there was a range check before this
conversion, the double rounding introduced inaccuracy:
the round to float64 might round the value further away
from the float32 range, reaching a float64 value that
could not actually be rounded to float32. The hardware
appears to give us 0 in that case, but it is probably undefined.
Double rounding also meant that the wrong value might
be used for certain border cases.

Do the rounding the float32 ourselves, just as we already
did the rounding to float64. This makes the conversion
precise and also makes the conversion match the range check.

Finally, add some code to print very large (bigger than float64)
floating point constants in decimal floating point notation instead
of falling back to the precise but human-unreadable binary floating
point notation.

Fixes #8015.

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

Update #7980
This CL make the linker abort for the example program. For Go 1.4,
we need to find a general way to handle large memory model programs.

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

Fixes #7445.

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

The temporary-introducing pass was not recursing
into the argumnt of a receive operation.

Fixes #8011.

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

Fixes #7256

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

This is the main point of confusion and the emphasis of
a recent Gophercon talk.

Fixes #5886. (mostly fixed in previous commits)

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

CL 22730043 fixed a bug in these functions: they could
return 1.0 despite documentation saying otherwise.
But the fix changed the values returned in the non-buggy case too,
which might invalidate programs depending on a particular
stream when using rand.Seed(0) or when passing their own
Source to rand.New.

The example test says:
        // These tests serve as an example but also make sure we don't change
        // the output of the random number generator when given a fixed seed.
so I think there is some justification for thinking we have
promised not to change the values. In any case, there's no point in
changing the values gratuitously: we can easily fix this bug without
changing the values, and so we should.

That CL just changed the test values too, which defeats the
stated purpose, but it was just a comment.
Add an explicit regression test, which might be
a clearer signal next time that we don't want to change
the values.

Fixes #6721. (again)
Fixes #8013.

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

Fixes #8023.

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

Discussion here: https://golang.org/cl/100490044/#msg14

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

Fixes #8010.

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

Currently freeOSMemory makes only marking phase of GC, but not sweeping phase.
So recently memory is not released after freeOSMemory.
Do both marking and sweeping during freeOSMemory.
Fixes #8019.

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

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

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

Rename Seek to seek in asm file, was overlooked in CL 99320043.

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

Accidental change from fixing Content-Length on 204s
in http://golang.org/issue/6685 earlier.

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

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

LGTM=r
R=golang-codereviews, aram, 0intro, gobot, r
CC=golang-codereviews
https://golang.org/cl/100490044

Found by go vet.

LGTM=crawshaw
R=golang-codereviews, crawshaw
CC=golang-codereviews
https://golang.org/cl/100510044

Fixes #8007.

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

TBR=rsc

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

These functions claimed to return error (an interface)
and be implemented entirely in assembly, but it's not
possible to create an interface from assembly
(at least not easily).

In reality the functions were written to return an errno uintptr
despite the Go prototype saying error.
When the errno was 0, they coincidentally filled out a nil error
by writing the 0 to the type word of the interface.
If the errno was ever non-zero, the functions would
create a non-nil error that would crash when trying to
call err.Error().

Luckily these functions (Seek, Time, Gettimeofday) pretty
much never fail, so it was all kind of working.

Found by go vet.

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

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

Update #7947.

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

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

TestLargeDefs was issuing over one million small writes to
create a 7MB file (large.go). This is quite slow on Plan 9
since our disk file systems aren't very fast and they're
usually accessed over the network.

Buffering the writes makes the test about six times faster.
Even on Linux, it's about 1.5 times faster.

Here are the results on a slow Plan 9 machine:

Before:
        % ./pack.test -test.v -test.run TestLargeDefs
        === RUN TestLargeDefs
        --- PASS: TestLargeDefs (125.11 seconds)
        PASS

After:
        % ./pack.test -test.v -test.run TestLargeDefs
        === RUN TestLargeDefs
        --- PASS: TestLargeDefs (20.835 seconds)
        PASS

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

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

The introduction of temporaries in order.c was not
quite right for two corner cases:

1) The rewrite that pushed new variables on the lhs of
a receive into the body of the case was dropping the
declaration of the variables. If the variables escape,
the declaration is what allocates them.
Caught by escape analysis sanity check.
In fact the declarations should move into the body
always, so that we only allocate if the corresponding
case is selected. Do that. (This is an optimization that
was already present in Go 1.2. The new order code just
made it stop working.)

Fixes #7997.

2) The optimization to turn a single-recv select into
an ordinary receive assumed it could take the address
of the destination; not so if the destination is _.

Fixes #7998.

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

Calling tar.Reader.Read() used to work fine, but without this patch it panics.
Simply return EOF to indicate the tar.Reader.Next() needs to be called.

LGTM=iant, bradfitz
R=golang-codereviews, bradfitz, iant, mikioh.mikioh, dominik.honnef
CC=golang-codereviews
https://golang.org/cl/94530043

This CL restores dropped constants not supported in OpenBSD 5.5
and tris to keep the promise of API compatibility.

Update #7049

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

This CL restores dropped constants not supported in OpenBSD 5.5
and tris to keep the promise of API compatibility.

Update #7049

LGTM=jsing, bradfitz, rsc
R=rsc, jsing, robert.hencke, minux.ma, bradfitz, iant
CC=golang-codereviews
https://golang.org/cl/96970043

- use Init to establish heap invariant on
  a non-empty heap
- use Fix to update heap after an element's
  properties have been changed

(The old code used Init where it wasn't needed,
 and didn't use Fix because Fix was added after
 the example was written.)

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

for GOOS in darwin freebsd linux nacl netbsd openbsd plan9 solaris windows
do
        for GOARCH in 386 amd64 amd64p32 arm
        do
                go vet
        done
done

These are all real mistakes being corrected, but none
of them should be able to cause problems today
due to the NOSPLIT on the functions.

However, vet has also identified a few important problems.
I'm sending this CL to get rid of the trivial 'go vet' results
before attacking the real ones.

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

None of these are real bugs.
The variable name in the reference is not semantically meaningful,
except that 'go vet' will double check the offset against the name for you.

The stack sizes being corrected really are incorrect but they are also
in NOSPLIT functions so they typically don't matter.

Found by vet.

GOOS=linux GOARCH=amd64 go vet sync/atomic
GOOS=linux GOARCH=amd64p32 go vet sync/atomic
GOOS=linux GOARCH=386 go vet sync/atomic
GOOS=linux GOARCH=arm go vet sync/atomic
GOOS=freebsd GOARCH=arm go vet sync/atomic
GOOS=netbsd GOARCH=arm go vet sync/atomic

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

The vet check is in CL 10470044.

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

The GC program describing a data structure sometimes trusts the
pointer base type and other times does not (if not, the garbage collector
must fall back on per-allocation type information stored in the heap).
Make the scanning of a pointer in an interface do the same.
This fixes a crash in a particular use of reflect.SliceHeader.

Fixes #8004.

LGTM=khr
R=golang-codereviews, khr
CC=0xe2.0x9a.0x9b, golang-codereviews, iant, r
https://golang.org/cl/100470045

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

Globals, function arguments, and results are special cases in
registerization.

Globals must be flushed aggressively, because nearly any
operation can cause a panic, and the recovery code must see
the latest values. Globals also must be loaded aggressively,
because nearly any store through a pointer might be updating a
global: the compiler cannot see all the "address of"
operations on globals, especially exported globals. To
accomplish this, mark all globals as having their address
taken, which effectively disables registerization.

If a function contains a defer statement, the function results
must be flushed aggressively, because nearly any operation can
cause a panic, and the deferred code may call recover, causing
the original function to return the current values of its
function results. To accomplish this, mark all function
results as having their address taken if the function contains
any defer statements. This causes not just aggressive flushing
but also aggressive loading. The aggressive loading is
overkill but the best we can do in the current code.

Function arguments must be considered live at all safe points
in a function, because garbage collection always preserves
them: they must be up-to-date in order to be preserved
correctly. Accomplish this by marking them live at all call
sites. An earlier attempt at this marked function arguments as
having their address taken, which disabled registerization
completely, making programs slower. This CL's solution allows
registerization while preserving safety. The benchmark speedup
is caused by being able to registerize again (the earlier CL
lost the same amount).

benchmark                old ns/op     new ns/op     delta
BenchmarkEqualPort32     61.4          56.0          -8.79%

benchmark                old MB/s     new MB/s     speedup
BenchmarkEqualPort32     521.56       570.97       1.09x

Fixes #1304. (again)
Fixes #7944. (again)
Fixes #7984.
Fixes #7995.

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

Do not compare nil and true.

Fixes #7996.

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