MOVSD is properly handled but its encoding test wasn't enabled. Enable
it.

For reference this was found with a little tool I wrote [1] to explore
which instructions are missing or not tested in the go obj package and
assembler:

"which SSE2 instructions aren't tested? And don't list instructions
which can take MMX operands"

$ x86db-gogen list --extension SSE2 --not-tested --not-mmx
CLFLUSH mem           [m:  np 0f ae /7] WILLAMETTE,SSE2
MOVSD   xmmreg,xmmreg [rm: f2 0f 10 /r] WILLAMETTE,SSE2
MOVSD   xmmreg,xmmreg [mr: f2 0f 11 /r] WILLAMETTE,SSE2
MOVSD   mem64,xmmreg  [mr: f2 0f 11 /r] WILLAMETTE,SSE2
MOVSD   xmmreg,mem64  [rm: f2 0f 10 /r] WILLAMETTE,SSE2

(CLFLUSH was introduced with SSE2, but has its own CPUID bit)

[1] https://github.com/dlespiau/x86db

Change-Id: Ic3af3028cb8d4f02e53fdebb9b30fb311f4ee454
Reviewed-on: https://go-review.googlesource.com/42814Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Currently windows Stat uses combination of Lstat and Readlink to
walk symlinks until it reaches file or directory. Windows Readlink
is implemented via Windows DeviceIoControl(FSCTL_GET_REPARSE_POINT, ...)
call, but that call does not work on network shares or inside of
Docker container (see issues #18555 ad #19922 for details).

But Raymond Chen suggests different approach:
https://blogs.msdn.microsoft.com/oldnewthing/20100212-00/?p=14963/
- he suggests to use Windows I/O manager to dereferences the
symbolic link.

This appears to work for all normal symlinks, but also for network
shares and inside of Docker container.

This CL implements described procedure.

I also had to adjust TestStatSymlinkLoop, because the test is
expecting Stat to return syscall.ELOOP for symlink with a loop.
But new Stat returns Windows error of ERROR_CANT_RESOLVE_FILENAME
= 1921 instead. I could map ERROR_CANT_RESOLVE_FILENAME into
syscall.ELOOP, but I suspect the former is broader than later.
And ERROR_CANT_RESOLVE_FILENAME message text of "The name of
the file cannot be resolved by the system." sounds fine to me.

Fixes #10935
Fixes #18555
Fixes #19922

Change-Id: I979636064cdbdb9c7c840cf8ae73fe2c24499879
Reviewed-on: https://go-review.googlesource.com/41834Reviewed-by: Harshavardhana <hrshvardhana@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

gcc on windows writes invalid location for .debug_gdb_scripts
which causes the executable loading to fail.

Fixes #20183

Change-Id: I5134013bc926b44a55b528f66ab79555855d1f4d
Reviewed-on: https://go-review.googlesource.com/42651Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

As discussion in issue #19141, the addend should be the third
argument of MULA. This patch fixes it in both the front end
and the back end of the assembler. And also tests are added to
the encoding test.

Fixes #19141

Change-Id: Idbc6f338b8fdfcad97a135f27a98c5b375b27d43
Reviewed-on: https://go-review.googlesource.com/42028
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

Fixes #20249

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

NewPackage required through documentation that the package name not
be blank (which wasn't true since each time we check a new package
we create one with a blank name (api.go:350). NewPackage also asserted
that a package name not be "_". While it is invalid for a package name
to be "_", one could conceivably create a package named "_" through
export data manipulation. Furthermore, it is ok to import a package
with package path "_" as long as the package itself is not named "_".

- removed misleading documentation
- removed unnecessary assertion
- added safety checks when we actually do the import

Fixes #20231.

Change-Id: I1eb1ab7b5e3130283db715374770cf05d749d159
Reviewed-on: https://go-review.googlesource.com/42852
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>

Fixes #20230.

Change-Id: I2e9b9e9d2540eb66c8411ac7910962933bc2c0e9
Reviewed-on: https://go-review.googlesource.com/42870
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

Generated hash and eq routines don't need nil checks.
Prior to this CL, this was accomplished by
temporarily incrementing the global variable disable_checknil.
However, that increment lasted only the lifetime of the
call to funccompile. After CL 41503, funccompile may
do nothing but enqueue the function for compilation,
resulting in nil checks being generated.

Fix this by adding an explicit flag to a function
indicating whether nil checks should be disabled
for that function.

While we're here, allow concurrent compilation
with the -w and -W flags, since that was needed
to investigate this issue.

Fixes #20242

Change-Id: Ib9140c22c49e9a09e62fa3cf350f5d3eff18e2bd
Reviewed-on: https://go-review.googlesource.com/42591
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Marvin Stenger <marvin.stenger94@gmail.com>
Reviewed-by: Robert Griesemer <gri@golang.org>

The Power processor manual states that "Branches not from the last instruction
of an aligned quadword and not to the first instruction of an aligned quadword
cause inefficiencies in the IBuffer". This changes the function alignment from 8
to 16 bytes to comply with that.

Fixes #18963

Change-Id: Ibce9bf8302110a86c6ab05948569af9ffdfcf4bb
Reviewed-on: https://go-review.googlesource.com/36390
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>

Allow the predefined escapers "html", "urlquery", and "js" to be used
in pipelines when they have no potential to affect the correctness or
safety of the escaped pipeline output. Specifically:
- "urlquery" may be used if it is the last command in the pipeline.
- "html" may be used if it is the last command in the pipeline, and
  the pipeline does not occur in an unquoted HTML attribute value
  context.
- "js" may be used in any pipeline, since it does not affect the
  merging of contextual escapers.

This change will loosens the restrictions on predefined escapers
introduced in golang.org/cl/37880, which will hopefully ease the
upgrade path for existing template users.

This change brings back the escaper-merging logic, and associated
unit tests, that were removed in golang.org/cl/37880. However, a
few notable changes have been made:
- "_html_template_nospaceescaper" is no longer considered
  equivalent to "html", since the former escapes spaces, while
  the latter does not (see #19345). This change should not silently
  break any templates, since pipelines where this substituion will
  happen will already trigger an explicit error.
- An "_eval_args_" internal directive has been added to
  handle pipelines containing a single explicit call to a
  predefined escaper, e.g. {{html .X}} (see #19353).

Also, the HTMLEscape function called by the predefined
text/template "html" function now escapes the NULL character as
well. This effectively makes it as secure as the internal
html/template HTML escapers (see #19345). While this change is
backward-incompatible, it will only affect illegitimate uses
of this escaper, since the NULL character is always illegal in
valid HTML.

Fixes #19952

Change-Id: I9b5570a80a3ea284b53901e6a1f842fc59b33d3a
Reviewed-on: https://go-review.googlesource.com/40936Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Execute incurs separate writes for each "step", e.g. each
variable that needs to be printed, and the final newline.
While it is correct to state that templates can be executed
concurrently, there is a more subtle nuance that is easily missed:
when writing to the same writer, the writes from concurrent execute
calls can be interleaved, leading to unexpected output.

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

The external darwin linker has been printing:

	ld: warning: -read_only_relocs cannot be used with x86_64

for a long time. Now that it is printed by CL 33301, we may as
well get rid of it.

Fixes #20246

Change-Id: I1147cf1ff197fdfda228a1349f13627bcf9fc72f
Reviewed-on: https://go-review.googlesource.com/42730
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Todd Neal <todd@tneal.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

For .bss section symbol ldelf does not set P (raw symbol data).
Make ldpe do the same.

Change-Id: Ib3d558456f505ee568d0972465fa9b08b5794a87
Reviewed-on: https://go-review.googlesource.com/42631Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fixes #20228

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

If we've already complained about a type T,
don't complain again about further expressions
involving it.

Fixes #20245 and hopefully all of its ilk.

Change-Id: Ic0abe8235d52e8a7ac40e3615aea8f3a54fd7cec
Reviewed-on: https://go-review.googlesource.com/42690
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

We already set it for mips32 objects. The native ELF linker warns when
linking PIC objects with non-PIC objects. Our objects are PIC, but we
were not marking them as such.

Fixes #20243.

Change-Id: Ifab131200b263e4c72cf81f7b131a65ac02a13a9
Reviewed-on: https://go-review.googlesource.com/42710
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

This change passes runtime.Version from the go tool to the compiler.
If the versions do not match, the compilation fails.
The result is a go tool from one GOROOT will complain loudly if it
is invoked with a different GOROOT value.

Only release versions are checked, so that when developing Go
you can still use "go install cmd/go" and "go install cmd/compile"
separately.

Fixes #19064

Change-Id: I17e184d07d3c1092b1d9af53ba55ed3ecf67791d
Reviewed-on: https://go-review.googlesource.com/42595
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

- remove <code> from <pre>
- replace `` with <code></code>

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

(Found by making time.Time uncomparable and rerunning std tests
locally.)

Change-Id: I4fa6fb0ba7334965362387e2f6541c17a27ac3aa
Reviewed-on: https://go-review.googlesource.com/42616
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Martin Möhrmann <moehrmann@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Before this change, building a GOROOT using make.bash, and then
moving the entire to a new path confused the go tool. Correct
operation of the go tool under these conditions required either
running make.bash again (not always possible if the new location
was owned by a different system user) or setting the GOROOT
environment variable. Setting GOROOT is unfortunate and
discouraged, as it makes it too easy to use the go tool from
one GOROOT and the compiler from another GOROOT.

With this change, the go tool finds its GOROOT relative to its
own location, using os.Executable. It checks it is in a GOROOT
by searching for the GOROOT/pkg/tool directory, to avoid two
plausible situations:

	ln -s $GOROOT/bin/go /usr/local/bin/go

and

	PATH=$HOME/bin:$PATH
	GOPATH=$HOME
	ln -s $GOROOT/bin/go $HOME/bin/go

Additionally, if the current executable path is not in a GOROOT,
the tool will follow any symlinks for the executable and check
to see if its original path is a GOROOT.

Fixes #18678

Change-Id: I151d7d449d213164f98193cc176b616849e6332c
Reviewed-on: https://go-review.googlesource.com/42533
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Updates text from https://golang.org/cl/42511

Updates #14395

Change-Id: I711100525e074ab360e577520280c37645db1c95
Reviewed-on: https://go-review.googlesource.com/42614Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Rob Pike <r@golang.org>

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

Compile:

package p

var f = func(...A)


Before this CL:

x.go:3:13: type %!v(PANIC=runtime error: invalid memory address or nil pointer dereference) is not an expression
x.go:3:17: undefined: A


After this CL:

x.go:3:13: type func(...<T>) is not an expression
x.go:3:17: undefined: A


Found with go-fuzz.

Fixes #20233

Change-Id: Ibb232b3954c4091071440eba48b44c4022a8083f
Reviewed-on: https://go-review.googlesource.com/42610
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

This change explicitly documents that DES, MD5, RC4 and SHA-1 are
insecure / broken - at all or at least within a commonly used scenario.

Fixes #14395

Change-Id: Id1d543c85d67968ba64ed7495313501953c3ef3a
Reviewed-on: https://go-review.googlesource.com/42511Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Updates bundled http2 to x/net/http2 git rev feeb485 for:

    http2: add all bad ciphers, use package constants
    https://golang.org/cl/42510

Updates #20213

Change-Id: I851453e3785e6b126db7a5c5eec2ebbbf61358ae
Reviewed-on: https://go-review.googlesource.com/42494
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitry Savintsev <dsavints@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Add the ability to override the default file and directory from
which certificates are loaded by setting the OpenSSL compatible
environment variables: SSL_CERT_FILE, SSL_CERT_DIR.

If the variables are set the default locations are not checked.

Added new default file "/usr/local/etc/ssl/cert.pem" for FreeBSD.

Certificates in the first valid location found for both file and
directory are added, instead of only the first file location if
a valid one was found, which is consistent with OpenSSL.

Fixes #3905
Fixes #14022
Fixes #14311
Fixes #16920
Fixes #18813 - If user sets SSL_CERT_FILE.

Change-Id: Ia24fb7c1c2ffff4338b4cf214bd040326ce27bb0
Reviewed-on: https://go-review.googlesource.com/36093Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fixes #17935.

Change-Id: I49b0f6cee29ea76ed62b8faa5d6d1f51be41bf84
Reviewed-on: https://go-review.googlesource.com/33301
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

When compiling the program:

package p

func _(){
	*;:=
}

Before:

x.go:4:3: syntax error: unexpected semicolon, expecting expression
x.go:4:4: non-name *%!v(PANIC=runtime error: invalid memory address or nil pointer dereference) on left side of :=
x.go:5:1: syntax error: unexpected }, expecting expression

After:

x.go:4:3: syntax error: unexpected semicolon, expecting expression
x.go:4:4: non-name *<N> on left side of :=
x.go:5:1: syntax error: unexpected }, expecting expression

No test because:

(1) we don't have a good mechanism to check for the
    absence of the string "PANIC" in an error message
(2) the string "*<N>", while better, is itself ugly enough
    that I don't want to actively check for it
(3) the bug isn't very important, the kind of thing only fuzzers encounter
(4) the fix is obvious and trivial

Fixes #20220

Change-Id: I35faa986b60b671414ee999d6264b06937f250e3
Reviewed-on: https://go-review.googlesource.com/42498
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Brings in chacha20poly1305 directory from golang.org/x/crypto revision
12e9ca725de4806fbda1610fd95aacad15bd6810, adding:

CL 41862: chacha20poly1305: add runtime internal independent cpu feature detection
CL 39952: add import comment

Change-Id: Ic46ff24b081bc1c66b6317334d33180e33bfd318
Reviewed-on: https://go-review.googlesource.com/42513
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: Ica7179d225c1fb79381f82f58ea5050ac6418b9c
Reviewed-on: https://go-review.googlesource.com/42493Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>

This allows to pre-allocate the final size of the hashmap and avoid
re-allocating as we insert entries. Furthermore for the current
implementation of the hashmap it allows avoiding several rounds of
evacuating hashmap entries after each re-allocation.

DecodeComplex128Slice-8  51.9µs ± 1%  51.9µs ± 2%     ~     (p=0.797 n=30+29)
DecodeFloat64Slice-8     31.5µs ± 2%  31.6µs ± 2%     ~     (p=0.050 n=28+28)
DecodeInt32Slice-8       32.0µs ± 2%  31.9µs ± 3%     ~     (p=0.666 n=29+28)
DecodeStringSlice-8      57.7µs ± 2%  57.8µs ± 3%     ~     (p=0.780 n=27+30)
DecodeInterfaceSlice-8    498µs ± 2%   495µs ± 2%     ~     (p=0.070 n=28+29)
DecodeMap-8               300µs ± 2%   230µs ± 5%  -23.31%  (p=0.000 n=27+27)

Updates #19525

Change-Id: Ia7233da49f05bae7a86c064d9ecebca966f5f2f7
Reviewed-on: https://go-review.googlesource.com/40113
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Because the hint parameter is supposed to be treated
purely as a hint, if it doesn't meet the requirements
we disregard it and continue as if there was no hint
at all.

Fixes #19926

Change-Id: I86e7f99472fad6b99ba4e2fd33e4a9e55d55115e
Reviewed-on: https://go-review.googlesource.com/40854
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

There's no Settings->Agreement path for PolyGerrit users, but if we
link directly to the page in the instructions, Gerrit will inform them
that they can access the page by switching to the old UI.

Fixes #20207

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

Change-Id: Ifbfd71a9c0d447e22c369c9d1209063b2a5c657b
Reviewed-on: https://go-review.googlesource.com/42490
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

This CL modifies how MOV[DWHB] instructions that store a constant to
memory are assembled to avoid them clobbering the condition code
(flags). It also modifies zeroAuto to use MOVD instructions instead of
CLEAR (which is assembled as XC).

MOV[DWHB]storeconst ops also no longer clobbers flags.

Note: this CL modifies the assembler so that it can no longer handle
immediates outside the range of an int16 or offsets from SB, which
reflects what the machine instructions support. The compiler doesn't
need this capability any more and I don't think this affects any existing
assembly, but it is easy to workaround if it does.

Fixes #20187.

Change-Id: Ie54947ff38367bd6a19962bf1a6d0296a4accffb
Reviewed-on: https://go-review.googlesource.com/42179Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Use Load instead of LoadOrStore in the fast path to save 1 alloc/op
for existing keys.

name                          old time/op    new time/op    delta
IntAdd                          6.39ns ± 7%    6.97ns ±19%     ~     (p=0.105 n=8+8)
IntAdd-6                        12.3ns ± 1%    12.2ns ± 1%     ~     (p=0.396 n=7+7)
IntSet                          6.41ns ± 6%    6.94ns ±21%     ~     (p=0.168 n=8+8)
IntSet-6                        12.1ns ± 3%    11.7ns ± 9%     ~     (p=0.496 n=7+8)
FloatAdd                        14.3ns ± 9%    14.7ns ± 4%     ~     (p=0.088 n=8+8)
FloatAdd-6                      36.5ns ± 1%    36.6ns ± 0%     ~     (p=0.709 n=7+6)
FloatSet                        6.59ns ± 7%    6.47ns ± 7%     ~     (p=0.397 n=8+7)
FloatSet-6                      12.2ns ± 1%    12.2ns ± 2%     ~     (p=0.748 n=7+7)
StringSet                       67.8ns ± 6%    68.7ns ± 6%     ~     (p=0.342 n=8+8)
StringSet-6                     41.8ns ± 5%    41.7ns ± 5%     ~     (p=0.979 n=8+8)
MapSet                           294ns ± 6%     234ns ± 4%  -20.35%  (p=0.000 n=8+8)
MapSet-6                        95.8ns ± 2%    89.4ns ± 3%   -6.73%  (p=0.000 n=8+8)
MapSetDifferent                 1.31µs ± 5%    1.07µs ± 4%  -18.21%  (p=0.000 n=8+8)
MapSetDifferent-6                260ns ± 8%     210ns ± 9%  -19.44%  (p=0.000 n=8+8)
MapSetString                     294ns ± 6%     236ns ± 4%  -19.92%  (p=0.000 n=8+8)
MapSetString-6                  95.6ns ± 2%    89.9ns ± 2%   -5.97%  (p=0.000 n=7+8)
MapAddSame                      1.46µs ± 3%    1.46µs ± 5%     ~     (p=0.721 n=8+8)
MapAddSame-6                     328ns ± 6%     330ns ± 4%     ~     (p=0.776 n=8+8)
MapAddDifferent                 4.89µs ± 7%    4.98µs ± 6%     ~     (p=0.505 n=8+8)
MapAddDifferent-6               1.02µs ± 3%    1.01µs ± 4%     ~     (p=0.352 n=7+8)
MapAddSameSteadyState           62.1ns ± 7%    60.8ns ± 4%     ~     (p=0.521 n=8+8)
MapAddSameSteadyState-6         38.1ns ± 3%    37.7ns ± 0%     ~     (p=0.185 n=7+6)
MapAddDifferentSteadyState       290ns ± 5%     293ns ± 4%     ~     (p=0.515 n=8+8)
MapAddDifferentSteadyState-6    63.0ns ± 7%    63.7ns ±11%     ~     (p=0.482 n=7+8)
RealworldExpvarUsage            7.39µs ± 5%    7.51µs ± 5%     ~     (p=0.382 n=8+8)
RealworldExpvarUsage-6          3.07µs ±28%    3.04µs ±43%     ~     (p=0.798 n=8+8)

name                          old alloc/op   new alloc/op   delta
IntAdd                           0.00B          0.00B          ~     (all equal)
IntAdd-6                         0.00B          0.00B          ~     (all equal)
IntSet                           0.00B          0.00B          ~     (all equal)
IntSet-6                         0.00B          0.00B          ~     (all equal)
FloatAdd                         0.00B          0.00B          ~     (all equal)
FloatAdd-6                       0.00B          0.00B          ~     (all equal)
FloatSet                         0.00B          0.00B          ~     (all equal)
FloatSet-6                       0.00B          0.00B          ~     (all equal)
StringSet                        16.0B ± 0%     16.0B ± 0%     ~     (all equal)
StringSet-6                      16.0B ± 0%     16.0B ± 0%     ~     (all equal)
MapSet                           48.0B ± 0%     32.0B ± 0%  -33.33%  (p=0.000 n=8+8)
MapSet-6                         48.0B ± 0%     32.0B ± 0%  -33.33%  (p=0.000 n=8+8)
MapSetDifferent                   192B ± 0%      128B ± 0%  -33.33%  (p=0.000 n=8+8)
MapSetDifferent-6                 192B ± 0%      128B ± 0%  -33.33%  (p=0.000 n=8+8)
MapSetString                     48.0B ± 0%     32.0B ± 0%  -33.33%  (p=0.000 n=8+8)
MapSetString-6                   48.0B ± 0%     32.0B ± 0%  -33.33%  (p=0.000 n=8+8)
MapAddSame                        480B ± 0%      480B ± 0%     ~     (all equal)
MapAddSame-6                      480B ± 0%      480B ± 0%     ~     (all equal)
MapAddDifferent                 1.09kB ± 0%    1.09kB ± 0%     ~     (all equal)
MapAddDifferent-6               1.09kB ± 0%    1.09kB ± 0%     ~     (all equal)
MapAddSameSteadyState            0.00B          0.00B          ~     (all equal)
MapAddSameSteadyState-6          0.00B          0.00B          ~     (all equal)
MapAddDifferentSteadyState       0.00B          0.00B          ~     (all equal)
MapAddDifferentSteadyState-6     0.00B          0.00B          ~     (all equal)
RealworldExpvarUsage             0.00B          0.00B          ~     (all equal)
RealworldExpvarUsage-6           0.00B          0.00B          ~     (all equal)

name                          old allocs/op  new allocs/op  delta
IntAdd                            0.00           0.00          ~     (all equal)
IntAdd-6                          0.00           0.00          ~     (all equal)
IntSet                            0.00           0.00          ~     (all equal)
IntSet-6                          0.00           0.00          ~     (all equal)
FloatAdd                          0.00           0.00          ~     (all equal)
FloatAdd-6                        0.00           0.00          ~     (all equal)
FloatSet                          0.00           0.00          ~     (all equal)
FloatSet-6                        0.00           0.00          ~     (all equal)
StringSet                         1.00 ± 0%      1.00 ± 0%     ~     (all equal)
StringSet-6                       1.00 ± 0%      1.00 ± 0%     ~     (all equal)
MapSet                            3.00 ± 0%      2.00 ± 0%  -33.33%  (p=0.000 n=8+8)
MapSet-6                          3.00 ± 0%      2.00 ± 0%  -33.33%  (p=0.000 n=8+8)
MapSetDifferent                   12.0 ± 0%       8.0 ± 0%  -33.33%  (p=0.000 n=8+8)
MapSetDifferent-6                 12.0 ± 0%       8.0 ± 0%  -33.33%  (p=0.000 n=8+8)
MapSetString                      3.00 ± 0%      2.00 ± 0%  -33.33%  (p=0.000 n=8+8)
MapSetString-6                    3.00 ± 0%      2.00 ± 0%  -33.33%  (p=0.000 n=8+8)
MapAddSame                        11.0 ± 0%      11.0 ± 0%     ~     (all equal)
MapAddSame-6                      11.0 ± 0%      11.0 ± 0%     ~     (all equal)
MapAddDifferent                   31.0 ± 0%      31.0 ± 0%     ~     (all equal)
MapAddDifferent-6                 31.0 ± 0%      31.0 ± 0%     ~     (all equal)
MapAddSameSteadyState             0.00           0.00          ~     (all equal)
MapAddSameSteadyState-6           0.00           0.00          ~     (all equal)
MapAddDifferentSteadyState        0.00           0.00          ~     (all equal)
MapAddDifferentSteadyState-6      0.00           0.00          ~     (all equal)
RealworldExpvarUsage              0.00           0.00          ~     (all equal)
RealworldExpvarUsage-6            0.00           0.00          ~     (all equal)

https://perf.golang.org/search?q=upload:20170501.1

Change-Id: I28fc3906473f2b7307f6d1ae05a8d9b01ef8a6f8
Reviewed-on: https://go-review.googlesource.com/42211
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Fixes #20196.

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

5 shards, each of which spins up NumCPU processes,
each of which is running at GOMAXPROCS=NumCPU,
is too much for one machine. It makes my laptop unusable.

It might also be in part responsible for test flakes
that require a moderately responsive system,
like #18589 (backedge scheduling) and #19276 (locklinear).

It's possible that Go should be a better neighbor in general;
that's #17969. In the meantime, fix this corner of the world.

Builders snapshot the world and run shards on different
machines, so keeping sharding high for them is good.

This is a partial reversion of CL 18199.

Fixes #20141.

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

Prior to this CL, the compiler and assembler
were sloppy about the LSym.Type for LSyms
containing static data.

The linker then fixed this up, converting
Sxxx and SBSS to SDATA, and SNOPTRBSS to SNOPTRDATA
if it noticed that the symbol had associated data.

It is preferable to just get this right in cmd/compile
and cmd/asm, because it removes an unnecessary traversal
of the symbol table from the linker (see #14624).
Do this by touching up the LSym.Type fixes in
LSym.prepwrite and Link.Globl.

I have confirmed by instrumenting the linker
that the now-eliminated code paths were unreached.
And an additional check in the object file writing code
will help preserve that invariant.

There was a case in the Windows linker,
with internal linking and cgo,
where we were generating SNOPTRBSS symbols with data.
For now, convert those at the site at which they occur
into SNOPTRDATA, just like they were.

Does not pass toolstash-check,
but does generate identical linked binaries.

No compiler performance changes.

Change-Id: I77b071ab103685ff8e042cee9abb864385488872
Reviewed-on: https://go-review.googlesource.com/40864
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>

On Android, the exec wrapper passes on output from adb to its parent
process by passing on os.Stderr and os.Stdout to adb. If the adb
process somehow hangs, it will keep stderr and stdout will open, in turn
blocking go test from ever returning from its cmd.Wait() even though
it has killed the exec wrapper process.

Break the short circuit by introducing a wrapper between adb and the
exec wrapper, preventing os/exec.Run from passing along the raw
file descriptors for os.Stdout and os.Stderr.

(Hopefully) fixes occasional indefinite hangs on the Android builder.

Change-Id: I1188211fbde79b4a66bf93ff8e9d0091abf34560
Reviewed-on: https://go-review.googlesource.com/42271
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>