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>

Per RFC 6265.

Change-Id: I2b6b145f5d057f96509332509d722602ed9e2bbd
Reviewed-on: https://go-review.googlesource.com/10711Reviewed-by: Brett Slatkin <bslatkin@google.com>
Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>

Also modifies 'dist test' to use that sharding, and removes some old
temporary stuff from dist test which are no longer required.

'dist test' now also supports running a list of tests given in
arguments, mutually exclusive with the existing -run=REGEXP flag. The
hacky fast paths for avoiding the 1 second "go list" latency are now
removed and only apply to the case where partial tests are run via
args, instead of regex.  The build coordinator will use both styles
for awhile. (the statically-sharded ARM builders on scaleway will
continue to use regexps, but the dynamically-shared builders on GCE
will use the list of tests)

Updates #10029

Change-Id: I557800a54dfa6f3b5100ef4c26fe397ba5189813
Reviewed-on: https://go-review.googlesource.com/10688Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Static branch prediction guesses that forward branches aren't taken.
Since stacks are rarely grown, make the forward branch mean grow.

While we're here, remove the debug-only instruction
saving the frame size in the temp register.

Sample disassembly for

func f() {
	_ = [128]byte{}
}

Before:

0x4008248         ldr        x1, [x28, #0x10]
0x400824c         sub        x2, sp, #0x90
0x4008250         cmp        x2, x1
0x4008254         b.hi       0x4008268
0x4008258         mov        x3, x30
0x400825c         movz       x27, #0x90
0x4008260         bl         runtime.morestack_noctxt
0x4008264         b          main.f
0x4008268         sub        sp, sp, #0x90
0x400826c         add        x16, sp, #0x10
0x4008270         str        xzr, [x16]
0x4008274         str        xzr, [x16, #0x8]
0x4008278         str        xzr, [x16, #0x10]
0x400827c         str        xzr, [x16, #0x18]
0x4008280         str        xzr, [x16, #0x20]
0x4008284         str        xzr, [x16, #0x28]
0x4008288         str        xzr, [x16, #0x30]
0x400828c         str        xzr, [x16, #0x38]
0x4008290         str        xzr, [x16, #0x40]
0x4008294         str        xzr, [x16, #0x48]
0x4008298         str        xzr, [x16, #0x50]
0x400829c         str        xzr, [x16, #0x58]
0x40082a0         str        xzr, [x16, #0x60]
0x40082a4         str        xzr, [x16, #0x68]
0x40082a8         str        xzr, [x16, #0x70]
0x40082ac         str        xzr, [x16, #0x78]
0x40082b0         add        sp, sp, #0x90
0x40082b4         ret

After:

0x4004bc8         ldr        x1, [x28, #0x10]
0x4004bcc         sub        x2, sp, #0x90
0x4004bd0         cmp        x2, x1
0x4004bd4         b.ls       0x4004c28
0x4004bd8         sub        sp, sp, #0x90
0x4004bdc         add        x16, sp, #0x10
0x4004be0         str        xzr, [x16]
0x4004be4         str        xzr, [x16, #0x8]
0x4004be8         str        xzr, [x16, #0x10]
0x4004bec         str        xzr, [x16, #0x18]
0x4004bf0         str        xzr, [x16, #0x20]
0x4004bf4         str        xzr, [x16, #0x28]
0x4004bf8         str        xzr, [x16, #0x30]
0x4004bfc         str        xzr, [x16, #0x38]
0x4004c00         str        xzr, [x16, #0x40]
0x4004c04         str        xzr, [x16, #0x48]
0x4004c08         str        xzr, [x16, #0x50]
0x4004c0c         str        xzr, [x16, #0x58]
0x4004c10         str        xzr, [x16, #0x60]
0x4004c14         str        xzr, [x16, #0x68]
0x4004c18         str        xzr, [x16, #0x70]
0x4004c1c         str        xzr, [x16, #0x78]
0x4004c20         add        sp, sp, #0x90
0x4004c24         ret
0x4004c28         mov        x3, x30
0x4004c2c         bl         runtime.morestack_noctxt
0x4004c30         b          main.f

Updates #10587.

Package sort benchmarks using an iPhone 6:

name            old time/op  new time/op  delta
SearchWrappers   355ns ± 1%   328ns ± 1%  -7.57%  (p=0.000 n=25+19)
SortString1K     580µs ± 1%   577µs ± 1%  -0.48%  (p=0.000 n=25+25)
StableString1K  1.04ms ± 0%  1.04ms ± 0%    ~     (p=0.851 n=24+25)
SortInt1K        251µs ± 1%   247µs ± 1%  -1.52%  (p=0.000 n=23+25)
StableInt1K      267µs ± 2%   261µs ± 2%  -2.02%  (p=0.000 n=25+25)
SortInt64K      23.8ms ± 1%  23.6ms ± 0%  -0.97%  (p=0.000 n=25+23)
StableInt64K    22.8ms ± 0%  22.4ms ± 1%  -1.76%  (p=0.000 n=24+25)
Sort1e2          123µs ± 1%   124µs ± 1%    ~     (p=0.256 n=23+23)
Stable1e2        248µs ± 1%   247µs ± 1%  -0.69%  (p=0.000 n=23+25)
Sort1e4         24.3ms ± 2%  24.6ms ± 5%  +1.36%  (p=0.017 n=22+25)
Stable1e4       77.2ms ± 6%  76.2ms ± 5%  -1.36%  (p=0.020 n=25+25)
Sort1e6          3.95s ± 8%   3.95s ± 8%    ~     (p=0.863 n=25+25)
Stable1e6        15.7s ± 1%   15.5s ± 1%  -1.11%  (p=0.000 n=22+23)

Change-Id: I377b3817af2ed27ddeecf24edef97fad91fc1afc
Reviewed-on: https://go-review.googlesource.com/10500Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Dave Cheney <dave@cheney.net>

When stack growth is not needed, as it usually is not,
execute only a single conditional branch
rather than three conditional instructions.
This adds 4 bytes to every function,
but might speed up execution in the common case.

Sample disassembly for

func f() {
	_ = [128]byte{}
}

Before:

TEXT main.f(SB) x.go
	x.go:3	0x2000	e59a1008	MOVW 0x8(R10), R1
	x.go:3	0x2004	e59fb028	MOVW 0x28(R15), R11
	x.go:3	0x2008	e08d200b	ADD R11, R13, R2
	x.go:3	0x200c	e1520001	CMP R1, R2
	x.go:3	0x2010	91a0300e	MOVW.LS R14, R3
	x.go:3	0x2014	9b0118a9	BL.LS runtime.morestack_noctxt(SB)
	x.go:3	0x2018	9afffff8	B.LS main.f(SB)
	x.go:3	0x201c	e52de084	MOVW.W R14, -0x84(R13)
	x.go:4	0x2020	e28d1004	ADD $4, R13, R1
	x.go:4	0x2024	e3a00000	MOVW $0, R0
	x.go:4	0x2028	eb012255	BL 0x4a984
	x.go:5	0x202c	e49df084	RET #132
	x.go:5	0x2030	eafffffe	B 0x2030
	x.go:5	0x2034	ffffff7c	?

After:

TEXT main.f(SB) x.go
	x.go:3	0x2000	e59a1008	MOVW 0x8(R10), R1
	x.go:3	0x2004	e59fb02c	MOVW 0x2c(R15), R11
	x.go:3	0x2008	e08d200b	ADD R11, R13, R2
	x.go:3	0x200c	e1520001	CMP R1, R2
	x.go:3	0x2010	9a000004	B.LS 0x2028
	x.go:3	0x2014	e52de084	MOVW.W R14, -0x84(R13)
	x.go:4	0x2018	e28d1004	ADD $4, R13, R1
	x.go:4	0x201c	e3a00000	MOVW $0, R0
	x.go:4	0x2020	eb0124dc	BL 0x4b398
	x.go:5	0x2024	e49df084	RET #132
	x.go:5	0x2028	e1a0300e	MOVW R14, R3
	x.go:5	0x202c	eb011b0d	BL runtime.morestack_noctxt(SB)
	x.go:5	0x2030	eafffff2	B main.f(SB)
	x.go:5	0x2034	eafffffe	B 0x2034
	x.go:5	0x2038	ffffff7c	?

Updates #10587.

package sort benchmarks on an iPhone 6:

name            old time/op  new time/op  delta
SortString1K     569µs ± 0%   565µs ± 1%  -0.75%  (p=0.000 n=23+24)
StableString1K   872µs ± 1%   870µs ± 1%  -0.16%  (p=0.009 n=23+24)
SortInt1K        317µs ± 2%   316µs ± 2%    ~     (p=0.410 n=26+26)
StableInt1K      343µs ± 1%   339µs ± 1%  -1.07%  (p=0.000 n=22+23)
SortInt64K      30.0ms ± 1%  30.0ms ± 1%    ~     (p=0.091 n=25+24)
StableInt64K    30.2ms ± 0%  30.0ms ± 0%  -0.69%  (p=0.000 n=22+22)
Sort1e2          147µs ± 1%   146µs ± 0%  -0.48%  (p=0.000 n=25+24)
Stable1e2        290µs ± 1%   286µs ± 1%  -1.30%  (p=0.000 n=23+24)
Sort1e4         29.5ms ± 2%  29.7ms ± 1%  +0.71%  (p=0.000 n=23+23)
Stable1e4       88.7ms ± 4%  88.6ms ± 8%  -0.07%  (p=0.022 n=26+26)
Sort1e6          4.81s ± 7%   4.83s ± 7%    ~     (p=0.192 n=26+26)
Stable1e6        18.3s ± 1%   18.1s ± 1%  -0.76%  (p=0.000 n=25+23)
SearchWrappers   318ns ± 1%   344ns ± 1%  +8.14%  (p=0.000 n=23+26)

package sort benchmarks on a first generation rpi:

name            old time/op  new time/op  delta
SearchWrappers  4.13µs ± 0%  3.95µs ± 0%   -4.42%  (p=0.000 n=15+13)
SortString1K    5.81ms ± 1%  5.82ms ± 2%     ~     (p=0.400 n=14+15)
StableString1K  9.69ms ± 1%  9.73ms ± 0%     ~     (p=0.121 n=15+11)
SortInt1K       3.30ms ± 2%  3.66ms ±19%  +10.82%  (p=0.000 n=15+14)
StableInt1K     5.97ms ±15%  4.17ms ± 8%  -30.05%  (p=0.000 n=15+15)
SortInt64K       319ms ± 1%   295ms ± 1%   -7.65%  (p=0.000 n=15+15)
StableInt64K     343ms ± 0%   332ms ± 0%   -3.26%  (p=0.000 n=12+13)
Sort1e2         3.36ms ± 2%  3.22ms ± 4%   -4.10%  (p=0.000 n=15+15)
Stable1e2       6.74ms ± 1%  6.43ms ± 2%   -4.67%  (p=0.000 n=15+15)
Sort1e4          247ms ± 1%   247ms ± 1%     ~     (p=0.331 n=15+14)
Stable1e4        864ms ± 0%   820ms ± 0%   -5.15%  (p=0.000 n=14+15)
Sort1e6          41.2s ± 0%   41.2s ± 0%   +0.15%  (p=0.000 n=13+14)
Stable1e6         192s ± 0%    182s ± 0%   -5.07%  (p=0.000 n=14+14)

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