The spec was unclear about whether blank methods should be
permitted in interface types. gccgo permits at most one, gc
crashes if there are more than one, go/types permits at most
one.

Discussion:

Since method sets of non-interface types never contain methods
with blank names (blank methods are never declared), it is impossible
to satisfy an interface with a blank method.

It is possible to declare variables of assignable interface types
(but not necessarily identical types) containing blank methods, and
assign those variables to each other, but the values of those
variables can only be nil.

There appear to be two "reasonable" alternatives:

1) Permit at most one blank method (since method names must be unique),
and consider it part of the interface. This is what appears to happen
now, with corner-case bugs. Such interfaces can never be implemented.

2) Permit arbitrary many blank methods but ignore them. This appears
to be closer to the handling of blank identifiers in declarations.
However, an interface type literal is not a declaration (it's a type
literal). Also, for struct types, blank identifiers are not ignored;
so the analogy with declarations is flawed.

Both these alternatives don't seem to add any benefit and are likely
(if only slightly) more complicated to explain and implement than
disallowing blank methods in interfaces altogether.

Fixes #6604.

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

The key property here is what the bit pattern represents,
not what its type is. Storing 5 into a pointer is the problem.
Storing a uintptr that holds pointer bits back into a pointer
is not as much of a problem, and not what we are claiming
the runtime will detect.

Longer discussion at
https://groups.google.com/d/msg/golang-nuts/dIGISmr9hw0/0jO4ce85Eh0J

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

This is a quick documentation change/clarification, as this
confused me before: in my own cgo-based projects, I currently have
identical #cgo directives in each relevant source file, and I notice
with go build -x that cgo is combining the directives, leading to
pkg-config invocations with the same package name (gtk+-3.0, in my
case) repeated several times, or on Mac OS X, LDFLAGS listing
-framework Foundation -framework AppKit multiple times. Since I am
about to add a CFLAGS as well, I checked the source to cmd/cgo and
go/build (where the work is actually done) to see if that still holds
true there. Hopefully other people who have made the same mistake I
have (I don't know if anyone has) can remove the excess declarations
now; this should make things slightly easier to manage as well.

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

Generated by addca.

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

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

Update #8030

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

Ignore symbols that aren't text, data, or bss since they cause
problems when dissassembling instructions with small immediate
values.

Before:
        build.go:142    0x10ee  83ec50      SUBL $text/template/parse.autotmp_1293(SB), SP

After:
        build.go:142    0x10ee  83ec50      SUBL $0x50, SP

Fixes #7947.

LGTM=rsc
R=rsc, 0intro
CC=golang-codereviews
https://golang.org/cl/93520045

Noted by gri in CL 100660044 review but I missed them.

TBR=gri
CC=golang-codereviews
https://golang.org/cl/97570049

Add larger comment explaining testing methodology,
and derive tests arithmetically.

(These tests are checking rounding again; the derived
tests they replace were checking exact values.)

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

Passes the expanded test in CL 100660044,
which gives me some confidence that it
might be right.

(The old code failed by not considering all the
low bits.)

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

Rewrite formatFloat to be much simpler and clearer and
avoid the tricky interaction with padding.
The issue refers to complex but the problem is just floating-point.
The new tests added were incorrectly formatted before this fix.
Fixes #8064.

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

Fixes #8062.

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

Fixes #7983.

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

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

These constants pass go/types constant conversions as well.

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

Fixes #8061.

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

Patch from http://gnats.NetBSD.org/48811.

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

Fixes #8032.

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

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

The spec did not specify the order in which
init() functions are called. Specify that
they are called in source order since we have
now also specified the initialization order
of independent variables.

While technically a language change, no
existing code could have relied on this,
so this should not break anything.

Per suggestion from rsc.

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

Fixes #8051

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

- split description of package initialization and
  program execution
- better grouping of concerns in section on package
  initialization
- more explicit definition of what constitues a
  dependency
- removed language about constant dependencies -
  they are computed at compile-time and not
  initialized at run-time
- clarified that independent variables are initialized
  in declaration order (rather than reference order)

Note that the last clarification is what distinguishes
gc and gccgo at the moment: gc uses reference order
(i.e., order in which variables are referenced in
initialization expressions), while gccgo uses declaration
order for independent variables.

Not a language change. But adopting this CL will
clarify what constitutes a dependency.

Fixes #6703.

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

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

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

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

Fixes #7701. (again, differently)

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

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

This idea was rejected in CL 5731059. We should fix the
runtime docs instead.

««« original CL description
cmd/dist: reflect local changes to tree in goversion

runtime.Version() requires a trailing "+" when
tree had local modifications at time of build.

Fixes #7701

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

»»»

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

- Don't export Prog structure.
- Remove ProgHeader and ExecTable structures.
- Add Magic, Bss and Entry fields in FileHeader.
- Replace ?_MAGIC variables with constants.
- Ignore final EOF from ReadAt.
- Improve documentation.

Fixes #7989.

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

Explain which files the go command looks at, and what they represent.
Fixes #6348.

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

Fixes #7958.

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

Add nacl.bash, the NaCl version of all.bash.
It's a separate script because it builds a variant of package syscall
with a large zip file embedded in it, containing all the input files
needed for tests.

Disable various tests new since the last round, mostly the ones using os/exec.

Fixes #7945.

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

I don't know when the bug was fixed, but empirically it was.
Make sure it stays fixed by adding a test.

Fixes #7884.

LGTM=adg
R=golang-codereviews, adg
CC=golang-codereviews
https://golang.org/cl/93500043

Fixes #7050.

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

Apparently all the __DWARF sections need addresses
even though they are marked as "do not load from disk".
Continue the address numbering from the data segment.

With this change:

g% lldb helloworld
Current executable set to 'helloworld' (x86_64).
(lldb) b main.main
Breakpoint 1: where = helloworld`main.main + 25 at helloworld.go:12, address = 0x0000000000002019
(lldb) r
Process 68509 launched: '/Users/rsc/g/go/src/cmd/6l/helloworld' (x86_64)
1 location added to breakpoint 1
(lldb)
[KProcess 68509 stopped
* thread #1: tid = 0x8b7a27, 0x0000000000002019 helloworld`main.main + 25 at helloworld.go:12, stop reason = breakpoint 1.2
    frame #0: 0x0000000000002019 helloworld`main.main + 25 at helloworld.go:12
   9   	package main
   10
   11  	func main() {
-> 12  		print("hello, world\n")
   13  	}
(lldb) bt
* thread #1: tid = 0x8b7a27, 0x0000000000002019 helloworld`main.main + 25 at helloworld.go:12, stop reason = breakpoint 1.2
  * frame #0: 0x0000000000002019 helloworld`main.main + 25 at helloworld.go:12
(lldb) disas
helloworld`main.main at helloworld.go:11:
   0x2000:  movq   %gs:0x8a0, %rcx
   0x2009:  cmpq   (%rcx), %rsp
   0x200c:  ja     0x2015                    ; main.main + 21 at helloworld.go:11
   0x200e:  callq  0x20da0                   ; runtime.morestack00_noctxt at atomic_amd64x.c:28
   0x2013:  jmp    0x2000                    ; main.main at helloworld.go:11
   0x2015:  subq   $0x10, %rsp
-> 0x2019:  leaq   0x2c2e0, %rbx
   0x2021:  leaq   (%rsp), %rbp
   0x2025:  movq   %rbp, %rdi
   0x2028:  movq   %rbx, %rsi
   0x202b:  movsq
   0x202d:  movsq
   0x202f:  callq  0x10300                   ; runtime.printstring at compiler.go:1
   0x2034:  addq   $0x10, %rsp
   0x2038:  ret
   0x2039:  addb   %al, (%rax)
   0x203b:  addb   %al, (%rax)
   0x203d:  addb   %al, (%rax)
(lldb) quit
Quitting LLDB will kill one or more processes. Do you really want to proceed: [Y/n] y
g%

Fixes #7070.

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

Fixes #7835.

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

Update #8030

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

Update #4714

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

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