Update #8525

Some temporary variables that were fully registerized nevertheless had stack space allocated for them because the Addrs were still marked as having associated nodes.

Distribution of stack space reserved for temporary variables while running make.bash (6g):

BEFORE

40.89%  7026 allocauto: 0 to 0
 7.83%  1346 allocauto: 0 to 24
 7.22%  1241 allocauto: 0 to 8
 6.30%  1082 allocauto: 0 to 16
 4.96%   853 allocauto: 0 to 56
 4.59%   789 allocauto: 0 to 32
 2.97%   510 allocauto: 0 to 40
 2.32%   399 allocauto: 0 to 48
 2.10%   360 allocauto: 0 to 64
 1.91%   328 allocauto: 0 to 72

AFTER

48.49%  8332 allocauto: 0 to 0
 9.52%  1635 allocauto: 0 to 16
 5.28%   908 allocauto: 0 to 48
 4.80%   824 allocauto: 0 to 32
 4.73%   812 allocauto: 0 to 8
 3.38%   581 allocauto: 0 to 24
 2.35%   404 allocauto: 0 to 40
 2.32%   399 allocauto: 0 to 64
 1.65%   284 allocauto: 0 to 56
 1.34%   230 allocauto: 0 to 72

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

TBR=dfc
CC=golang-codereviews
https://golang.org/cl/126210047

cmd/6g has been doing this for a long time.

Arrays are still problematic on 5g because the addressing
for t[0] where local var t has type [3]uintptr takes the address of t.
That's issue 8125.

Fixes #8123.

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

CL 130240043 did this but broke ARM, because
it made newErrorCString start allocating, so we rolled
it back in CL 133810043.

CL 133820043 removed that allocation.

Try again.

Fixes #8405.

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

Fixes #8494.

LGTM=rsc
R=golang-codereviews, gobot, rsc, evankroske
CC=golang-codereviews
https://golang.org/cl/123040043

Now 'go vet runtime' only shows:

        malloc.go:200: possible misuse of unsafe.Pointer
        malloc.go:214: possible misuse of unsafe.Pointer
        malloc.go:250: possible misuse of unsafe.Pointer
        stubs.go:167: possible misuse of unsafe.Pointer

Those are all unavoidable.

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

It now serves as an example for go generate as well as for yacc.

NOTE: Depends on go generate, which is not yet checked in.
This is a proof of concept of the approach.
That is https://golang.org/cl/125580044.

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

First cut.

Works well enough to support yacc via
        https://golang.org/cl/125620044.

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

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

TBR=dvyukov
CC=golang-codereviews
https://golang.org/cl/131150043

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

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

This is based on the crash dump provided by Alan
and on mental experiments:

sweep 0 74
fatal error: gc: unswept span
runtime stack:
runtime.throw(0x9df60d)
markroot(0xc208002000, 0x3)
runtime.parfordo(0xc208002000)
runtime.gchelper()

I think that when we moved all stacks into heap,
we introduced a bunch of bad data races. This was later
worsened by parallel stack shrinking.

Observation 1: exitsyscall can allocate a stack from heap at any time (including during STW).
Observation 2: parallel stack shrinking can (surprisingly) grow heap during marking.
Consider that we steadily grow stacks of a number of goroutines from 8K to 16K.
And during GC they all can be shrunk back to 8K. Shrinking will allocate lots of 8K
stacks, and we do not necessary have that many in heap at this moment. So shrinking
can grow heap as well.

Consequence: any access to mheap.allspans in GC (and otherwise) must take heap lock.
This is not true in several places.

Fix this by protecting accesses to mheap.allspans and introducing allspans cache for marking,
similar to what we use for sweeping.

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

Cache unrolled GC bitmask for types up to 64/32K on 64/32-bit systems,
this corresponds to up to 4K cached bitmask.
Perf builders say that 2% of time is spent in unrollgcproginplace_m/unrollgcprog1
on http benchmark:
http://goperfd.appspot.com/log/f42045f45bf61a0da53b724a7c8567824a0ad6c9

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

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

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

The low-level implementation of divide on ARM assumes that
it can panic with an error created by newErrorCString without
allocating. If we make interface data words require pointer values,
the current definition would require an allocation when stored
in an interface. Changing the definition to use unsafe.Pointer
instead of uintptr avoids the allocation. This change is okay
because the field really is a pointer (to a C string in rodata).

Update #8405.

This should make CL 133830043 safe to try again.

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

This change broke divmod.go on all arm platforms.

««« original CL description
cmd/gc: change interface representation: only pointers in data word

Note that there are various cleanups that can be made if we keep
this change, but I do not want to start making changes that
depend on this one until the 1.4 cycle closes.

Fixes #8405.

LGTM=r
R=golang-codereviews, adg, r, bradfitz
CC=golang-codereviews, iant
https://golang.org/cl/130240043
»»»

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

This is a very dumb translation to keep the code as close to the original C as possible.

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

Note that there are various cleanups that can be made if we keep
this change, but I do not want to start making changes that
depend on this one until the 1.4 cycle closes.

Fixes #8405.

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

LGTM=bradfitz
R=daniel.morsing, bradfitz
CC=golang-codereviews
https://golang.org/cl/130500044

This makes newproc invisible to the GC. This is a pretty simple change since parts of newproc already depends on being run on the M stack.

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

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

Note is required for timers and heap scavenger.

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

The current code is correct, but vet does not understand it:
asm_amd64.s:963: [amd64] invalid MOVL of ret+0(FP); int64 is 8-byte value
asm_amd64.s:964: [amd64] invalid offset ret+4(FP); expected ret+0(FP)

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

Fix issue by always appending newline after user input, before
the closing curly bracket. The adjust func is modified to remove
this new newline.

Add test case (it fails before CL, passes after).

Fixes #8411.

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

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

Fixes #8503.

Thanks to no.smile.face for the original report.

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

Add gofmt.go and gofmt_test.go as they are part of the test data set.

See CL 130440043.

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

Timer callback does not accept now as first arg anymore.

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

Fixes #8145.

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

1) Interpret a comment of the form

//gofmt <flags>

in test files to drive the respective
gofmt command. Eliminates the need to
enumerate all test files in the test
harness.

2) Added -update flag to make it easier
to update test cases.

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

Fixes #8543.

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

Update #8527

Fixes, src/cmd/6l/../ld/pcln.c:93:18: runtime error: left shift of negative value -2

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

Generated by a+c.

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

This files were added accidentally and are
not required for running the tests (they
are produced by failing tests for easier
debugging).

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

Fixes compilation of runtime on Solaris where the inner struct
was not called "_4_".

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

Australian timezones abbreviation for standard and daylight saving time were recently
changed from EST for both to AEST and AEDT in the icann tz database (see changelog
on www.iana.org/time-zones).

A test in the time package was written to check that the ParseInLocation function
understand that Feb EST and Aug EST are different time zones, even though they are
both called EST. This is no longer the case, and the Date function now returns
AEST or AEDT for australian tz on every Linux system with an up to date tz database
(and this makes the test fail).

Since I wasn't able to find another country that 1) uses daylight saving and 2) has
the same abbreviation for both on tzdata, I changed the test to make sure that
ParseInLocation does not get confused when it parses, in different locations, two
dates with the same abbreviation (this was suggested in the mailing list).

Fixes #8547.

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

Generated by a+c.

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

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