Currently checkmarks mode fails to rescan stacks because it sees the
leftover state bits indicating that the stacks haven't changed since
the last scan. As a result, it won't detect lost marks caused by
failing to scan stacks correctly during regular garbage collection.

Fix this by marking all stacks dirty before performing the checkmark
phase.

Change-Id: I1f06882bb8b20257120a4b8e7f95bb3ffc263895
Reviewed-on: https://go-review.googlesource.com/10794Reviewed-by: Russ Cox <rsc@golang.org>

Change-Id: Ib43b21daef5d8291e03c0f0fbf56999e37e21e21
Reviewed-on: https://go-review.googlesource.com/10820Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: Ibf2879c0034250c5699e21ecea0eb76340597a2a
Reviewed-on: https://go-review.googlesource.com/10810Reviewed-by: Austin Clements <austin@google.com>

Change-Id: I283ab238b60d3a47e86296e1fbfc73ba121bef19
Reviewed-on: https://go-review.googlesource.com/10745Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: I999b57ef5535c18e02cc27c9bc9f896d73126b50
Reviewed-on: https://go-review.googlesource.com/10674Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>

obj.ARET is the portable return mnemonic. ppc64.ARETURN is a legacy
alias.

This was done with
    sed -i s/ppc64\.ARETURN/obj.ARET/ cmd/compile/**/*.go
    sed -i s/ARETURN/obj.ARET/ cmd/internal/obj/ppc64/obj9.go

Change-Id: I4d8e83ff411cee764774a40ef4c7c34dcbca4e43
Reviewed-on: https://go-review.googlesource.com/10673Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>

All of the architectures except ppc64 have only "RET" for the return
mnemonic. ppc64 used to have only "RETURN", but commit cf06ea68
introduced RET as a synonym for RETURN to make ppc64 consistent with
the other architectures. However, that commit was never followed up to
make the code itself consistent by eliminating uses of RETURN.

This commit replaces all uses of RETURN in the ppc64 assembly with
RET.

This was done with
    sed -i 's/\<RETURN\>/RET/' **/*_ppc64x.s
plus one manual change to syscall/asm.s.

Change-Id: I3f6c8d2be157df8841d48de988ee43f3e3087995
Reviewed-on: https://go-review.googlesource.com/10672Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>

Change-Id: I318c1ef75b18d4687f13499ac225dde2d053505e
Reviewed-on: https://go-review.googlesource.com/10776Reviewed-by: Rob Pike <r@golang.org>

Change-Id: I7d96ebcca5954152edb821bb41b6047a1c622949
Reviewed-on: https://go-review.googlesource.com/10731Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

Port of https://go-review.googlesource.com/10773 from x/tools.

Change-Id: I6aba6a63a5448b8fcbcc7f072c627c27965dbe20
Reviewed-on: https://go-review.googlesource.com/10774Reviewed-by: Alan Donovan <adonovan@google.com>

gc should ideally consider this an error too; see golang/go#8560.

Change-Id: Ieee71c4ecaff493d7f83e15ba8c8a04ee90a4cf1
Reviewed-on: https://go-review.googlesource.com/10757Reviewed-by: Robert Griesemer <gri@golang.org>

In x/tools, MethodSetCache was moved from x/tools/go/types to
x/tools/go/types/typeutil. Mirror that change.

Change-Id: Ib838a9518371473c83fa4abc2778d42f33947c98
Reviewed-on: https://go-review.googlesource.com/10771Reviewed-by: Alan Donovan <adonovan@google.com>

Currently the stack barriers are installed at the next frame boundary
after gp.sched.sp + 1024*2^n for n=0,1,2,... However, when a G is in a
system call, we set gp.sched.sp to 0, which causes stack barriers to
be installed at *every* frame. This easily overflows the slice we've
reserved for storing the stack barrier information, and causes a
"slice bounds out of range" panic in gcInstallStackBarrier.

Fix this by using gp.syscallsp instead of gp.sched.sp if it's
non-zero. This is the same logic that gentraceback uses to determine
the current SP.

Fixes #11049.

Change-Id: Ie40eeee5bec59b7c1aa715a7c17aa63b1f1cf4e8
Reviewed-on: https://go-review.googlesource.com/10755Reviewed-by: Russ Cox <rsc@golang.org>

Change-Id: I12e6990b46ea9c733a5718dc5ca67f1fcd2dec66
Reviewed-on: https://go-review.googlesource.com/10754Reviewed-by: Ian Lance Taylor <iant@golang.org>

Change-Id: I09257b8f5482cba10b5f4d3813c778d6e9e74d40
Reviewed-on: https://go-review.googlesource.com/10752Reviewed-by: Russ Cox <rsc@golang.org>

Change-Id: I95bf62c0f2d77dd67515921e6aefa511cce8d95d
Reviewed-on: https://go-review.googlesource.com/10633Reviewed-by: Ian Lance Taylor <iant@golang.org>

Change-Id: I0e6f1a39b3d6b15d05891c8b25ab6644356bde5f
Reviewed-on: https://go-review.googlesource.com/10751Reviewed-by: Russ Cox <rsc@golang.org>

ContinueOnError is particularly confusing, because it causes
FlagSet.Parse to return as soon as it sees an error. I gather that the
intent is "continue the program" rather than "continue parsing",
compared to exiting or panicking.

Change-Id: I27370ce1f321ea4debcee5b03faff3532495c71a
Reviewed-on: https://go-review.googlesource.com/10740Reviewed-by: Rob Pike <r@golang.org>

Actually add all build flags, so we also get things like -race.

Fixes #10228.

Change-Id: I5f77dda9d1ee3208e1833702f12f68c2731c4b22
Reviewed-on: https://go-review.googlesource.com/10697Reviewed-by: Russ Cox <rsc@golang.org>

Change-Id: I1d7b728bd161da7bd6dd460862d8be072921e8b9
Reviewed-on: https://go-review.googlesource.com/10763Reviewed-by: Russ Cox <rsc@golang.org>

Change-Id: If969d7a06c83447ee38da30f1477a6cf4bfa1a03
Reviewed-on: https://go-review.googlesource.com/10691Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Also fix the interaction between -buildmode and -shared.
It's okay for -shared to change the default build mode,
but it's not okay for it to silently override an explicit -buildmode=exe.

Change-Id: Id40f93d140cddf75b19e262b3ba4856ee09a07ba
Reviewed-on: https://go-review.googlesource.com/10315Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

People invoking the linker directly already have to change their scripts
to use the new "go tool link", so this is a good time to make the -X flag
behave like all other Go flags and take just a single argument.

The old syntax will continue to be accepted (it is rewritten into the new
syntax before flag parsing). Maybe some day we will be able to retire it.

Even if we never retire the old syntax, having the new syntax at least
makes the rewriting much less of a kludge.

Change-Id: I91e8df94f4c22b2186e81d7f1016b8767d777eac
Reviewed-on: https://go-review.googlesource.com/10310Reviewed-by: Rob Pike <r@golang.org>

These are the Go 1.4 docs but refreshed for Go 1.5.
The most sigificant change is that all references to the Plan 9 toolchain are gone.
The tools no longer bear any meaningful resemblance.

Change-Id: I44f5cadb832a982323d7fee0b77673e55d761b35
Reviewed-on: https://go-review.googlesource.com/10298Reviewed-by: Rob Pike <r@golang.org>

Change-Id: I5c991cad38c9e2c839314a56d3415a2aa09c1561
Reviewed-on: https://go-review.googlesource.com/10762Reviewed-by: Russ Cox <rsc@golang.org>

See golang.org/s/go15gomaxprocs for details.

Change-Id: I8de5df34fa01d31d78f0194ec78a2474c281243c
Reviewed-on: https://go-review.googlesource.com/10668Reviewed-by: Rob Pike <r@golang.org>

Fixes #10375.

Change-Id: I78dc3e12035d130c405bdb284b0cceea19f084f6
Reviewed-on: https://go-review.googlesource.com/10690Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

The flag is available from the go test command as -count:

% go test -run XXX -bench . -count 3
PASS
BenchmarkSprintfEmpty      	30000000	        54.0 ns/op
BenchmarkSprintfEmpty      	30000000	        51.9 ns/op
BenchmarkSprintfEmpty      	30000000	        53.8 ns/op
BenchmarkSprintfString     	10000000	       238 ns/op
BenchmarkSprintfString     	10000000	       239 ns/op
BenchmarkSprintfString     	10000000	       234 ns/op
BenchmarkSprintfInt        	10000000	       232 ns/op
BenchmarkSprintfInt        	10000000	       226 ns/op
BenchmarkSprintfInt        	10000000	       225 ns/op
...

If -cpu is set, each test is run n times for each cpu value.

Original by r (CL 10663).

Change-Id: If3dfbdf21698952daac9249b5dbca66f5301e91b
Reviewed-on: https://go-review.googlesource.com/10669Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

Fixes #11048.
Fixes #11075.

Change-Id: I81f5ef1e1944056ce5494c91aa4a4a63c758f566
Reviewed-on: https://go-review.googlesource.com/10709Reviewed-by: Ian Lance Taylor <iant@golang.org>

Non-ELF binary formats are much less flexible and typically do not
have a good place to store the build ID.

We store it as raw bytes at the beginning of the text segment.

The only system I know of that will be upset about this is NaCl,
and NaCl is an ELF system and does not use this.

For #11048.

Change-Id: Iaa7ace703c4cf36392e752eea9b55e2ce49e9826
Reviewed-on: https://go-review.googlesource.com/10708Reviewed-by: Ian Lance Taylor <iant@golang.org>

Other binary formats to follow.

For #11048.

Change-Id: Ia2d8b47c99c99d171c014b7cfd23c1c7ada5231c
Reviewed-on: https://go-review.googlesource.com/10707Reviewed-by: Ian Lance Taylor <iant@golang.org>

Other binary formats to follow.

Using our own note instead of the GNU build ID note because
we are not the GNU project, and I can't guarantee that the semantics
of our note and the semantics of the GNU note will match forever.
(Also they don't match today.)

For #11048.

Change-Id: Iec7e5a2e49d52b6d3a51b0aface2de7c77a45491
Reviewed-on: https://go-review.googlesource.com/10706Reviewed-by: Ian Lance Taylor <iant@golang.org>

Change-Id: I3c9b05879fe0b6e94b63e9b65e4411ba2a917134
Reviewed-on: https://go-review.googlesource.com/10705Reviewed-by: Ian Lance Taylor <iant@golang.org>

Change-Id: I038e892725836ab7718f7638e8ad5712953f2cb5
Reviewed-on: https://go-review.googlesource.com/10704Reviewed-by: Ian Lance Taylor <iant@golang.org>

The bootstrap restriction is to avoid needing cgo for package net.
There's no problem with building debug/elf and debug/dwarf,
so do that.

An upcoming CL is going to add more note processing code,
and it simplifies things not to have to think about the code being
missing half the time.

Change-Id: I0e2f120ac23f14db6ecfcec7bfe254a69abcf7b6
Reviewed-on: https://go-review.googlesource.com/10703Reviewed-by: Ian Lance Taylor <iant@golang.org>

Change-Id: I4ff42113c5dda553d6f3d58f0e4836dce7c84710
Reviewed-on: https://go-review.googlesource.com/10730Reviewed-by: Rob Pike <r@golang.org>

The go/doc package doesn't remove unexported entries from const
and var blocks, so we must trim them ourselves.

Fixes #11008

Change-Id: Ibd60d87e09333964e2588340a2ca2b8804bbaa28
Reviewed-on: https://go-review.googlesource.com/10643Reviewed-by: Russ Cox <rsc@golang.org>

- s|"golang.org/x/tools/go/exact"|"go/constant"|
- s|"golang.org/x/tools/go/types"|"go/types"|
- removed import of gcimporter
- import "go/importer" instead
- trivial adjustments to make use of go/importer
- adjusted import paths for whitelist.go

Change-Id: I43488ff44c329cd869c92dcc31193fb31bebfd29
Reviewed-on: https://go-review.googlesource.com/10695Reviewed-by: Rob Pike <r@golang.org>

cp -r x/tools/cmd/vet cmd/vet without any changes.
The next change will adjust the source to use std
repo go/types and friends.

This may (temporarily) break the build; the next
commit (immediately following) will fix it. We do
it in two commits so that we can see the manual
changes.

Change-Id: Ic45dab7066f13923e21f8c61200c8c3fd447b171
Reviewed-on: https://go-review.googlesource.com/10694Reviewed-by: Rob Pike <r@golang.org>

As of golang.org/cl/9154, running go test will override a previous
go install -a -tags=lldb std with the tag-less version of stdlib. So
we pass -tags=lldb into the relevant go test commands.

Change-Id: I1c718289d7212373a9383eff53a643f06598f5ed
Reviewed-on: https://go-review.googlesource.com/10701Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>