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

The byte that r is or'd into is already 0x7, so the failure to zero r only
impacts the generated machine code if the register is > 7.

Fixes #7044.

LGTM=dave, minux.ma, rsc
R=dave, minux.ma, bradfitz, rsc
CC=golang-codereviews
https://golang.org/cl/73730043

Fixes #7507.

LGTM=agl
R=agl
CC=golang-codereviews
https://golang.org/cl/74090043

Spans are now private to threads, and the loop
is removed from all other functions.
Remove it from marknogc for consistency.

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

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

Not many windows users have perl installed. They can just use
standard go tools instead. Also mkerrors_windows.sh script
removed - we don't add any new "unix" errors to windows
syscall package anymore.

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

Thanks to Ian for spotting these.

runtime.h: define uintreg correctly.
stack.c: address warning caused by the type of uintreg being 32 bits on amd64p32.

Commentary (mainly for my own use)

nacl/amd64p32 defines a machine with 64bit registers, but address space is limited to a 4gb window (the window is placed randomly inside the full 48 bit virtual address space of a process). To cope with this 6c defines _64BIT and _64BITREG.

_64BITREG is always defined by 6c, so both GOARCH=amd64 and GOARCH=amd64p32 use 64bit wide registers.

However _64BIT itself is only defined when 6c is compiling for amd64 targets. The definition is elided for amd64p32 environments causing int, uint and other arch specific types to revert to their 32bit definitions.

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

gc does not report this as an error, but go/types does.
(I suspect that constructing a closure counts as a reference
to &all in gc's implementation).

This is not a tool bug, since the spec doesn't require
implementations to implement this check, but it does
illustrate that dialect variations are always a nuisance.

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

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

Generated by addca.

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

mem_nacl.c: add SysFault
env_posix.c: add nacl to build tag, from CL 15790043

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

Generated by addca.

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

Previously, passing a long duration to ParseDuration could result in
random, even negative, values.

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

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

Fixes #7496.

LGTM=jsing
R=golang-codereviews, jsing
CC=golang-codereviews
https://golang.org/cl/72840043

CL 69340044 requires that syscall.SO_ERROR be defined on all unix like platforms. Add SO_ERROR to the list of dummy constants in sycall/net_nacl.go.

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

Fixes #7442

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

Fixes #7072

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

Fixes #7194.

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

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

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

If we report a leak, make sure we've waited long enough to be sure.
The new sleep regimen waits 1.05 seconds before failing; the old
one waited 0.005 seconds.

(The single linux/amd64 failure in this test feels more like a
timing problem than a leak. I don't want to spend time on it unless
we're sure.)

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

We provide amd64p32 implementations for md5 and sha1 so we need to exclude amd64p32 from the generic implementations in those packages.

Fixes build once CL 72360044 lands.

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

This produces about a 2.3x speedup for patterns
that can be handled this way.

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

Fixes build on windows/386 and plan9/386.
Fixes #7487.

LGTM=mattn.jp, dvyukov, rsc
R=golang-codereviews, mattn.jp, dvyukov, 0intro, rsc
CC=golang-codereviews
https://golang.org/cl/72360043

This fixes the following amd64p32 issue:
    pkg/time/format.go:724: internal compiler error: twobitwalktype1: invalid initial alignment, Time

caused by the pointer zone ending on a 32-bit-aligned boundary.

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

This code being buggy is the only explanation I can come up
with for issue 7325. It's probably not, but the only alternative
is a Windows kernel bug. Comment this out to see what breaks
or gets fixed.

Update #7325

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

From the trace it appears that stackalloc is being
called with 0x1800 which is 6k = 4k + (StackSystem=2k).
Make StackSystem 4k too, to make stackalloc happy.
It's already 4k on windows/amd64.

TBR=khr
CC=golang-codereviews
https://golang.org/cl/72600043

It was using MOVL to pass a 64-bit argument
(concatenated framesize and argsize) to morestack11.

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

There are at least 3 bugs:
1. g->stacksize accounting is broken during copystack/shrinkstack
2. stktop->free is not properly maintained during copystack/shrinkstack
3. stktop->free logic is broken:
        we can have stktop->free==FixedStack,
        and we will free it into stack cache,
        but it actually comes from heap as the result of non-copying segment shrink
This shows as at least spurious races on race builders (maybe something else as well I don't know).

The idea behind the refactoring is to consolidate stacksize and
segment origin logic in stackalloc/stackfree.

Fixes #7490.

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

Recursive panics leave dangling Panic structs in g->panic stack.
At best it leads to a Defer leak and incorrect output on a subsequent panic.
At worst it arbitrary corrupts heap.

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

One reason the sync.Pool finalizer test can fail is that
this function's ef1 contains uninitialized data that just
happens to point at some of the old pool. I've seen this cause
retention of a single pool cache line (32 elements) on arm.

Really we need liveness information for C functions, but
for now we can be more careful about data in long-lived
C functions that block.

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

Replaces CL 70000043.

Switch to the amd64p32 linker model if we are building under nacl/amd64p32.

No need to introduce linkarchinit() as 6a contains its own main() function.

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

Replaces CL 70000043.

Introduce linkarchinit() from cmd/ld.

For cmd/6g, switch to the amd64p32 linker model if we are building under nacl/amd64p32.

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

Just commentary describing existing behavior, no code changes.

Fixes #7033.

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

Documenting existing behavior; new commentary only.
Fixes #7105.

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

This documents the status quo for most implementations,
with one exception: gc generates a run-time error for
constant but out-of-range indices when slicing a constant
string. See issue 7200 for a detailed discussion.

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

Instead, split the underlying storage in half and
free just half of it.

Shrinking without copying lets us reclaim storage used
by a previously profligate Go routine that has now blocked
inside some C code.

To shrink in place, we need all stacks to be a power of 2 in size.

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

This is a test case for CL 34680044.

Fixes #6333.

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

Two memory allocator bug fixes.

- efence is not maintaining the proper heap metadata
  to make eventual memory reuse safe, so use SysFault.

- now that our heap PageSize is 8k but most hardware
  uses 4k pages, SysAlloc and SysReserve results must be
  explicitly aligned. Do that in a few more call sites and
  document this fact in malloc.h.

Fixes #7448.

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