Fixes #6500.

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

IsNil isn't quite the same as == nil, as this snippet shows:

// http://play.golang.org/p/huomslDZgw
package main

import "fmt"
import "reflect"

func main() {
        var i interface{}
        v := reflect.ValueOf(i)
        fmt.Println(v.IsValid(), i == nil)
        fmt.Println(v.IsNil())
}

The fact that IsNil panics if you call it with an untyped nil
was not apparent. Verbiage added for clarity.

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

Update #6853

Nothing reads the Plan 9 symbol table anymore.
The last holdout was 'go tool nm', but since being rewritten in Go
it uses the standard symbol table for the binary format
(ELF, Mach-O, PE) instead.

Removing the Plan 9 symbol table saves ~15% disk space
on most binaries.

Two supporting changes included in this CL:

debug/gosym: use Go 1.2 pclntab to synthesize func-only
symbol table when there is no Plan 9 symbol table

debug/elf, debug/macho, debug/pe: ignore final EOF from ReadAt

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

c-mode classically uses ff-find-other-file to toggle between headers
and implementation. For Go it seemingly makes sense to jump between
implementation and test.

While there's no enforced mapping of file names for tests, the mapping
in this CL seems to be very common at least throughout the standard
library, and ff-find-other-file fails gracefully when the mapping
doesn't apply.

LGTM=adonovan
R=adonovan
CC=golang-codereviews
https://golang.org/cl/65750044

LGTM=adonovan
R=adonovan
CC=golang-codereviews
https://golang.org/cl/62600043

The code was returning the original value rather than the cloned value
resulting in the tests not being repeatable.

Fixes #7111.

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

Prevent bitrot. (similar to the previous sha1 and md5 CLs)

Fixes #6642

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

Unbreaks the build.

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

LGTM=mpvl
R=mpvl
CC=golang-codereviews
https://golang.org/cl/65550044

This is a relatively minor change.

This does not result in changes to go.text/unicode/norm. The go.text
packages will therefore be relatively unaffected. It does make the
way for an upgrade to CLDR 24, though.

The tests of all.bash pass, as well as the tests in go.text after
this update.

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

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

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

broke 32-bit builds

««« original CL description
cmd/gc, runtime: enable precisestack by default

Precisestack makes stack collection completely precise,
in the sense that there are no "used and not set" errors
in the collection of stack frames, no times where the collector
reads a pointer from a stack word that has not actually been
initialized with a pointer (possibly a nil pointer) in that function.

The most important part is interfaces: precisestack means
that if reading an interface value, the interface value is guaranteed
to be initialized, meaning that the type word can be relied
upon to be either nil or a valid interface type word describing
the data word.

This requires additional zeroing of certain values on the stack
on entry, which right now costs about 5% overall execution
time in all.bash. That cost will come down before Go 1.3
(issue 7345).

There are at least two known garbage collector bugs right now,
issues 7343 and 7344. The first happens even without precisestack.
The second I have only seen with precisestack, but that does not
mean that precisestack is what causes it. In fact it is very difficult
to explain by what precisestack does directly. Precisestack may
be exacerbating an existing problem. Both of those issues are
marked for Go 1.3 as well.

The reasons for enabling precisestack now are to give it more
time to soak and because the copying stack work depends on it.

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

TBR=r
CC=golang-codereviews
https://golang.org/cl/65230043

LGTM=dsymonds
R=dsymonds
CC=golang-codereviews
https://golang.org/cl/64100045

Precisestack makes stack collection completely precise,
in the sense that there are no "used and not set" errors
in the collection of stack frames, no times where the collector
reads a pointer from a stack word that has not actually been
initialized with a pointer (possibly a nil pointer) in that function.

The most important part is interfaces: precisestack means
that if reading an interface value, the interface value is guaranteed
to be initialized, meaning that the type word can be relied
upon to be either nil or a valid interface type word describing
the data word.

This requires additional zeroing of certain values on the stack
on entry, which right now costs about 5% overall execution
time in all.bash. That cost will come down before Go 1.3
(issue 7345).

There are at least two known garbage collector bugs right now,
issues 7343 and 7344. The first happens even without precisestack.
The second I have only seen with precisestack, but that does not
mean that precisestack is what causes it. In fact it is very difficult
to explain by what precisestack does directly. Precisestack may
be exacerbating an existing problem. Both of those issues are
marked for Go 1.3 as well.

The reasons for enabling precisestack now are to give it more
time to soak and because the copying stack work depends on it.

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

I have seen this cause leaks where not all objects in a sync.Pool
would be reclaimed during the sync package tests.
I found it while debugging the '0 of 100 finalized' failure we are
seeing on arm, but it seems not to be the root cause for that one.

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

Callers of md5.Sum should do so to avoid allocations, the example did not demonstate this property.

««« original CL description
crypto/md5: add example for Sum

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

»»»

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

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

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

Add b.RunParallel function that captures parallel benchmark boilerplate:
creates worker goroutines, joins worker goroutines, distributes work
among them in an efficient way, auto-tunes grain size.
Fixes #7090.

R=bradfitz, iant, josharian, tracey.brendan, r, rsc, gobot
CC=golang-codereviews
https://golang.org/cl/57270043

Is it required? Why don't we do it?

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

Update #7331

cgo is currently broken on freebsd/arm.

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

CL 64170043 disabled it in run.bash for Unix systems.
I did not realize Windows systems also ran the race detector test.

TBR=iant
CC=golang-codereviews
https://golang.org/cl/64480043

Not recording the address being taken was causing
the liveness analysis not to preserve x in the absence
of direct references to x, which in turn was making the
net test fail with GOGC=0.

In addition to the test, this fixes a bug wherein
        GOGC=0 go test -short net
crashed if liveness analysis was in use (like at tip, not like Go 1.2).

TBR=ken2
CC=golang-codereviews
https://golang.org/cl/64470043

This problem was discovered by reading the code.
I have not seen it in practice, nor do I have any ideas
on how to trigger it reliably in a test. But it's still worth
fixing.

TBR=ken2
CC=golang-codereviews
https://golang.org/cl/64370046

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

The VARDEF placement must be before the initialization
but after any final use. If you have something like s = ... using s ...
the rhs must be evaluated, then the VARDEF, then the lhs
assigned.

There is a large comment in pgen.c on gvardef explaining
this in more detail.

This CL also includes Ian's suggestions from earlier CLs,
namely commenting the use of mode in link.h and fixing
the precedence of the ~r check in dcl.c.

This CL enables the check that if liveness analysis decides
a variable is live on entry to the function, that variable must
be a function parameter (not a result, and not a local variable).
If this check fails, it indicates a bug in the liveness analysis or
in the generated code being analyzed.

The race detector generates invalid code for append(x, y...).
The code declares a temporary t and then uses cap(t) before
initializing t. The new liveness check catches this bug and
stops the compiler from writing out the buggy code.
Consequently, this CL disables the race detector tests in
run.bash until the race detector bug can be fixed
(golang.org/issue/7334).

Except for the race detector bug, the liveness analysis check
does not detect any problems (this CL and the previous CLs
fixed all the detected problems).

The net test still fails with GOGC=0 but the rest of the tests
now pass or time out (because GOGC=0 is so slow).

TBR=iant
CC=golang-codereviews
https://golang.org/cl/64170043

The existing tests issue4463.go and issue4654.go had failures at
typechecking and did not test walking the AST.

Fixes #7272.

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

Catch the error instead and return it to the user. Before this fix,
the template package panicked. Now you get:
        template: bug11:1:14: executing "bug11" at <.PS>: dereference of nil pointer of type *string
Extended example at http://play.golang.org/p/uP6pCW3qKT

Fixes #7333.

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

The branchtags method was removed but we should've
been using branchmap all along.

http://selenic.com/hg/rev/4274eda143cb

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

These should never be found in a bzip2 file but it does appear that
there's a buggy encoder that is producing them. Since the official
bzip2 handles this case, this change makes the Go code do likewise.

With this change, the code produces the same output as the official
bzip2 code on the invalid example given in the bug.

Fixes #7279.

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

Rfork is not splitting the stack when creating a new thread,
so the parent and child are executing on the same stack.
However, if the parent returns and keeps executing before
the child can read the arguments from the parent stack,
the child will not see the right arguments. The solution
is to load the needed pieces from the parent stack into
register before INT $64.

Thanks to Russ Cox for the explanation.

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

Fixes #7329

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

A previous CL added support for cross compiling with cgo, but
missed the GOOS check in cmd/go. Remove it.

Update #4714

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

Changing the PC confuses gdb, because execution does not
continue where gdb expects it.  Not changing the PC has the
potential to confuse a stack dump, but when running under gdb
it seems better to confuse a stack dump than to confuse gdb.

Fixes #6776.

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

A configuration like the following:

7: tun6rd: <NOARP,UP,LOWER_UP> mtu 1280
        link/sit 10.11.12.13 brd 0.0.0.0
        inet 1.2.3.4/24 scope global tun6rd
        inet6 2014:1001:a0b:c0d::1/32 scope global
        inet6 ::10.11.12.13/128 scope global
9: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1496
        link/ppp
        inet 192.168.101.234 peer 192.168.102.234/32 scope global ppp0
        inet 10.20.30.40/24 scope global ppp0
        inet6 2014:1002::1/64 scope global
11: tun0@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1480
        link/ipip 192.168.202.34 peer 192.168.202.69
        inet 192.168.10.1/24 scope global tunnel0
        inet6 2014:1003::1/64 scope global

will be handled like below.

"tun6rd": flags "up", ifindex 7, mtu 1280
        hardware address ""
        interface address "1.2.3.4/24"
        interface address "2014:1001:a0b:c0d::1/32"
        interface address "::a0b:c0d/128"
"ppp0": flags "up|pointtopoint|multicast", ifindex 9, mtu 1496
        hardware address ""
        interface address "192.168.101.234/32"
        interface address "10.20.30.40/24"
        interface address "2014:1002::1/64"
"tun0": flags "up|pointtopoint", ifindex 11, mtu 1480
        hardware address ""
        interface address "192.168.10.1/24"
        interface address "2014:1003::1/64"

Fixes #6433.
Update #4839

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

On Linux include/net directory is just to help porting applications
from BSDs and files under net keep less information than include/linux.
Making use of files under include/linux instead of include/net prevents
lack of information.

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

The following checkdead message is false positive:

$ go test -race -c runtime
$ ./runtime.test -test.cpu=2 -test.run=TestSmhasherWindowed -test.v
=== RUN TestSmhasherWindowed-2
checkdead: find g 18 in status 1
SIGABRT: abort
PC=0x42bff1

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

Currently small and large (size>rate) objects are merged into a single entry.
But rate adjusting is required only for small objects.
As a result pprof either incorrectly adjusts large objects
or does not adjust small objects.
With this change objects of different sizes are stored in different buckets.

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

TBR=iant
CC=golang-codereviews
https://golang.org/cl/63680045