Now builders say:
pkg/net/dnsclient_unix_test.go:10: imported and not used: "runtime"

R=golang-dev
CC=golang-dev
https://golang.org/cl/12890043

Windows builders say:
pkg\net\dnsclient_unix_test.go:24: undefined: dnsConfig
pkg\net\dnsclient_unix_test.go:25: undefined: exchange

R=golang-dev
CC=golang-dev
https://golang.org/cl/12889043

The schedtrace value sets dump period in milliseconds.
In default mode the trace looks as follows:
SCHED 0ms: gomaxprocs=4 idleprocs=0 threads=3 idlethreads=0 runqueue=0 [1 0 0 0]
SCHED 1001ms: gomaxprocs=4 idleprocs=3 threads=6 idlethreads=3 runqueue=0 [0 0 0 0]
SCHED 2008ms: gomaxprocs=4 idleprocs=1 threads=6 idlethreads=1 runqueue=0 [0 1 0 0]
If GODEBUG=scheddetail=1 is set as well, then the detailed trace is printed:
SCHED 0ms: gomaxprocs=4 idleprocs=0 threads=3 idlethreads=0 runqueue=0 singleproc=0 gcwaiting=1 mlocked=0 nmspinning=0 stopwait=0 sysmonwait=0
  P0: status=3 tick=1 m=0 runqsize=1/128 gfreecnt=0
  P1: status=3 tick=0 m=-1 runqsize=0/128 gfreecnt=0
  P2: status=3 tick=0 m=-1 runqsize=0/128 gfreecnt=0
  P3: status=3 tick=0 m=-1 runqsize=0/128 gfreecnt=0
  M2: p=-1 curg=-1 mallocing=0 throwing=0 gcing=0 locks=1 dying=0 helpgc=0 spinning=0 lockedg=-1
  M1: p=-1 curg=-1 mallocing=0 throwing=0 gcing=0 locks=1 dying=0 helpgc=0 spinning=0 lockedg=-1
  M0: p=0 curg=1 mallocing=0 throwing=0 gcing=0 locks=1 dying=0 helpgc=0 spinning=0 lockedg=1
  G1: status=2() m=0 lockedm=0
  G2: status=1() m=-1 lockedm=-1

R=golang-dev, raggi, rsc
CC=golang-dev
https://golang.org/cl/11435044

They don't work on older chips, just like the x86-32 64-bit atomics.

Update #6134

R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/12880043

Breaks the build.  Old bucket arrays kept by iterators
still need to be scanned.

««« original CL description
runtime: tell GC not to scan internal hashmap structures.
We'll do it ourselves via hash_gciter, thanks.
Fixes bug 6119.

R=golang-dev, dvyukov, cookieo9, rsc
CC=golang-dev
https://golang.org/cl/12840043
»»»

R=golang-dev
CC=golang-dev
https://golang.org/cl/12884043

We'll do it ourselves via hash_gciter, thanks.
Fixes bug 6119.

R=golang-dev, dvyukov, cookieo9, rsc
CC=golang-dev
https://golang.org/cl/12840043

The NetBSD and OpenBSD failures are apparently real,
not due to the test bug fixed in 100b9fc0c46f.

««« original CL description
runtime/pprof: test netbsd and openbsd again

Maybe these will work now.

R=golang-dev, dvyukov, bradfitz
CC=golang-dev
https://golang.org/cl/12787044
»»»

R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/12873043

Fixes #6100.

R=golang-dev, dave, bradfitz, rsc
CC=golang-dev
https://golang.org/cl/12703045

Currently it's possible that a goroutine
that periodically executes non-blocking
cgo/syscalls is never preempted.
This change splits scheduler and syscall
ticks to prevent such situation.

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/12658045

Currently we lose lots of profiling signals.
Most notably, GC is not accounted at all.
But stack splits, scheduler, syscalls, etc are lost as well.
This creates seriously misleading profile.
With this change all profiling signals are accounted.
Now I see these additional entries that were previously absent:
161  29.7%  29.7%      164  30.3% syscall.Syscall
 12   2.2%  50.9%       12   2.2% scanblock
 11   2.0%  55.0%       11   2.0% markonly
 10   1.8%  58.9%       10   1.8% sweepspan
  2   0.4%  85.8%        2   0.4% runtime.newstack
It is still impossible to understand what causes stack splits,
but at least it's clear how many time is spent on them.
Update #2197.
Update #5659.

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/12179043

Fixes #6070.
Update #6055.

R=golang-dev, nightlyone, rsc
CC=golang-dev
https://golang.org/cl/12602043

R=cshapiro
CC=golang-dev
https://golang.org/cl/12877043

Return an ErrClosedPipe rather than allowing the write to proceed.

Fixes #5330.

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/12541053

R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/12870043

so that we don't need to traceback through __kuser_cmpxchg

R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/12869043

Fixes #5686.

R=golang-dev, bradfitz, mikioh.mikioh
CC=golang-dev
https://golang.org/cl/12458043

* Add a new kind of Name, "fpvar" which stands for function pointer variable
* When walking the AST, find functions used as expressions and create a new Name object for them
* Track functions which are only used in expr contexts, and avoid generating bridge code for them

R=golang-dev, minux.ma, fullung, rsc, iant
CC=golang-dev
https://golang.org/cl/9835047

Maybe these will work now.

R=golang-dev, dvyukov, bradfitz
CC=golang-dev
https://golang.org/cl/12787044

R=bradfitz, dave, rsc, r
CC=golang-dev
https://golang.org/cl/10001045

R=golang-dev, bradfitz, rsc
CC=golang-dev
https://golang.org/cl/12790043

Ensure that deadlines affect already issued IO.

R=golang-dev, mikioh.mikioh, bradfitz
CC=golang-dev
https://golang.org/cl/12847043

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/12851043

Fixes #5722.

R=golang-dev, khr, cshapiro, rsc, r
CC=golang-dev
https://golang.org/cl/12670045

Just for readability reasons; to prevent overlooking deadline stuff
across over platforms.

R=golang-dev, dvyukov
CC=golang-dev
https://golang.org/cl/8656044

The new version does not require any memory allocations and is 30-50% faster.
Also detect and painc if Cond is copied after first.

benchmark            old ns/op    new ns/op    delta
BenchmarkCond1             317          195  -38.49%
BenchmarkCond1-2           875          607  -30.63%
BenchmarkCond1-4          1116          548  -50.90%
BenchmarkCond1-8          1013          613  -39.49%
BenchmarkCond1-16          983          450  -54.22%
BenchmarkCond2             559          352  -37.03%
BenchmarkCond2-2          1916         1378  -28.08%
BenchmarkCond2-4          1518         1322  -12.91%
BenchmarkCond2-8          2313         1291  -44.19%
BenchmarkCond2-16         1885         1078  -42.81%
BenchmarkCond4            1070          614  -42.62%
BenchmarkCond4-2          4899         3047  -37.80%
BenchmarkCond4-4          3813         3006  -21.16%
BenchmarkCond4-8          3605         3045  -15.53%
BenchmarkCond4-16         4148         2637  -36.43%
BenchmarkCond8            2086         1264  -39.41%
BenchmarkCond8-2          9961         6736  -32.38%
BenchmarkCond8-4          8135         7689   -5.48%
BenchmarkCond8-8          9623         7517  -21.89%
BenchmarkCond8-16        11661         8093  -30.60%

R=sougou, rsc, bradfitz, r
CC=golang-dev
https://golang.org/cl/11573043

If the timer goroutine is wakeup by timeout,
other goroutines will still notewakeup because sleeping is still set.

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/12763043

Fixes #5517.
Fixes #5659.

R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/12183044

Fixes #6103.

R=golang-dev, alex.brainman
CC=golang-dev
https://golang.org/cl/12686045

R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/12836044

R=gri, r
CC=golang-dev
https://golang.org/cl/12822043

R=golang-dev, go.peter.90, rsc, r
CC=golang-dev
https://golang.org/cl/12016043

The compilers assume they can generate temporary variables
as needed to preserve the right semantics or simplify code
generation and the back end will still generate good code.
This turns out not to be true. The back ends will only
track the first 128 variables per function and give up
on the remainder. That needs to be fixed too, in a later CL.

This CL merges temporary variables with equal types and
non-overlapping lifetimes using the greedy algorithm in
Poletto and Sarkar, "Linear Scan Register Allocation",
ACM TOPLAS 1999.

The result can be striking in the right functions.

Top 20 frame size changes in a 6g godoc binary by bytes saved:

5464 1984 (-3480, -63.7%) go/build.(*Context).Import
4456 1824 (-2632, -59.1%) go/printer.(*printer).expr1
2560   80 (-2480, -96.9%) time.nextStdChunk
3496 1608 (-1888, -54.0%) go/printer.(*printer).stmt
1896  272 (-1624, -85.7%) net/http.init
2688 1400 (-1288, -47.9%) fmt.(*pp).printReflectValue
2800 1512 (-1288, -46.0%) main.main
3296 2016 (-1280, -38.8%) crypto/tls.(*Conn).clientHandshake
1664  488 (-1176, -70.7%) time.loadZoneZip
1760  608 (-1152, -65.5%) time.parse
4104 3072 (-1032, -25.1%) runtime/pprof.writeHeap
1680  712 ( -968, -57.6%) go/ast.Walk
2488 1560 ( -928, -37.3%) crypto/x509.parseCertificate
1128  392 ( -736, -65.2%) math/big.nat.divLarge
1528  864 ( -664, -43.5%) go/printer.(*printer).fieldList
1360  712 ( -648, -47.6%) regexp/syntax.(*parser).factor
2104 1528 ( -576, -27.4%) encoding/asn1.parseField
1064  504 ( -560, -52.6%) encoding/xml.(*Decoder).text
 584   48 ( -536, -91.8%) html.init
1400  864 ( -536, -38.3%) go/doc.playExample

In the same godoc build, cuts the number of functions with
too many vars from 83 to 32.

R=ken2
CC=golang-dev
https://golang.org/cl/12829043

R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/12830043

If the hg checkout of go.tools fails, check for Internet
connectivity before failing.

R=golang-dev, shivakumar.gn
CC=golang-dev
https://golang.org/cl/12814043

R=ken2
CC=golang-dev
https://golang.org/cl/12827043

Now there's only one copy of the flow graph construction
and dominator computation, and different optimizations
can attach different annotations to the instructions.

R=ken2
CC=golang-dev
https://golang.org/cl/12797045

Out of context, it can be very confusing because there can be lots of Go
files in the directory, but the error message says there aren't.

R=golang-dev, dsymonds, rsc
CC=golang-dev
https://golang.org/cl/12823043

The call builtin unconditionally tries to convert a second return value from a function to the error type. This fails in case nil is returned, effectively making call useless for functions returning two values.

This CL adds a nil check for the second return value, and adds a test.

Note that for regular function and method calls the nil error case is handled correctly and is verified by a test.

R=r
CC=golang-dev
https://golang.org/cl/12804043

Bugs pointed out by cshapiro in CL 12637051.

R=cshapiro
CC=golang-dev
https://golang.org/cl/12815043

Code in gc/popt.c is compiled as part of 5g, 6g, and 8g,
meaning it can use arch-specific headers but there's
just one copy of the code.

This is the same arrangement we use for the portable
code generation logic in gc/pgen.c.

Move fixjmp and noreturn there to get the ball rolling.

R=ken2
CC=golang-dev
https://golang.org/cl/12789043