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>

The encoding of MOVL to a register is 2 bytes shorter than for MOVQ.
The upper 32bit are automatically zeroed when MOVL to a register is used.

Replaces 1657 MOVQ by MOVL in the go binary.
Reduces go binary size by 4 kilobyte.

name                   old time/op    new time/op    delta
BinaryTree17              1.93s ± 0%     1.93s ± 0%  -0.32%  (p=0.000 n=9+9)
Fannkuch11                2.66s ± 0%     2.48s ± 0%  -6.60%  (p=0.000 n=9+9)
FmtFprintfEmpty          31.8ns ± 0%    31.6ns ± 0%  -0.63%  (p=0.000 n=10+10)
FmtFprintfString         52.0ns ± 0%    51.9ns ± 0%  -0.19%  (p=0.000 n=10+10)
FmtFprintfInt            55.6ns ± 0%    54.6ns ± 0%  -1.80%  (p=0.002 n=8+10)
FmtFprintfIntInt         87.7ns ± 0%    84.8ns ± 0%  -3.31%  (p=0.000 n=9+9)
FmtFprintfPrefixedInt    98.9ns ± 0%   102.0ns ± 0%  +3.10%  (p=0.000 n=10+10)
FmtFprintfFloat           165ns ± 0%     164ns ± 0%  -0.61%  (p=0.000 n=10+10)
FmtManyArgs               368ns ± 0%     361ns ± 0%  -1.98%  (p=0.000 n=8+10)
GobDecode                4.53ms ± 0%    4.58ms ± 0%  +1.08%  (p=0.000 n=9+10)
GobEncode                3.74ms ± 0%    3.73ms ± 0%  -0.27%  (p=0.000 n=10+10)
Gzip                      164ms ± 0%     163ms ± 0%  -0.48%  (p=0.000 n=10+10)
Gunzip                   26.7ms ± 0%    26.6ms ± 0%  -0.13%  (p=0.000 n=9+10)
HTTPClientServer         30.4µs ± 1%    30.3µs ± 1%  -0.41%  (p=0.016 n=10+10)
JSONEncode               10.9ms ± 0%    11.0ms ± 0%  +0.70%  (p=0.000 n=10+10)
JSONDecode               36.8ms ± 0%    37.0ms ± 0%  +0.59%  (p=0.000 n=9+10)
Mandelbrot200            3.20ms ± 0%    3.21ms ± 0%  +0.44%  (p=0.000 n=9+10)
GoParse                  2.35ms ± 0%    2.35ms ± 0%  +0.26%  (p=0.000 n=10+9)
RegexpMatchEasy0_32      58.3ns ± 0%    58.4ns ± 0%  +0.17%  (p=0.000 n=10+10)
RegexpMatchEasy0_1K       138ns ± 0%     142ns ± 0%  +2.68%  (p=0.000 n=10+10)
RegexpMatchEasy1_32      55.1ns ± 0%    55.6ns ± 1%    ~     (p=0.104 n=10+10)
RegexpMatchEasy1_1K       242ns ± 0%     243ns ± 0%  +0.41%  (p=0.000 n=10+10)
RegexpMatchMedium_32     87.4ns ± 0%    89.9ns ± 0%  +2.86%  (p=0.000 n=10+10)
RegexpMatchMedium_1K     27.4µs ± 0%    27.4µs ± 0%  +0.15%  (p=0.000 n=10+10)
RegexpMatchHard_32       1.30µs ± 0%    1.32µs ± 1%  +1.91%  (p=0.000 n=10+10)
RegexpMatchHard_1K       39.0µs ± 0%    39.5µs ± 0%  +1.38%  (p=0.000 n=10+10)
Revcomp                   316ms ± 0%     319ms ± 0%  +1.13%  (p=0.000 n=9+8)
Template                 40.6ms ± 0%    40.6ms ± 0%    ~     (p=0.123 n=10+10)
TimeParse                 224ns ± 0%     224ns ± 0%    ~     (all equal)
TimeFormat                230ns ± 0%     225ns ± 0%  -2.17%  (p=0.000 n=10+10)

Change-Id: I32a099b65f9e6d4ad7288ed48546655c534757d8
Reviewed-on: https://go-review.googlesource.com/38630
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

Changes all cpu features to be detected and stored in bools in rt0_go.

Updates: #15403

Change-Id: I5a9961cdec789b331d09c44d86beb53833d5dc3e
Reviewed-on: https://go-review.googlesource.com/41950
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ilya Tocar <ilya.tocar@intel.com>
Reviewed-by: Keith Randall <khr@golang.org>

DUFFZERO on 386 is not marked as clobbering flags, but rewriteToUseGot rewrote
"ADUFFZERO $offset" to "MOVL runtime.duffxxx@GOT, CX; ADDL $offset, CX; CALL CX"
which does. Luckily the fix is easier than figuring out what the problem was:
replace the ADDL $offset, CX with LEAL $offset(CX), CX.

On amd64 DUFFZERO clobbers flags, on arm, arm64 and ppc64 ADD does not clobber
flags and s390x does not use the duff functions, so I'm fairly confident this
is the only fix required.

I don't know how to write a test though.

Change-Id: I69b0958f5f45771d61db5f5ecb4ded94e8960d4d
Reviewed-on: https://go-review.googlesource.com/41821
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

ANDPS, like all others PS (Packed Single precision floats) instructions,
need Ym: they don't use the 0x66 prefix.

From the manual:

    NP 0F 54 /r        ANDPS xmm1, xmm2/m128

NP meaning, quoting the manual:

  NP - Indicates the use of 66/F2/F3 prefixes (beyond those already part
  of the instructions opcode) are not allowed with the instruction.

And indeed, the same instruction prefixed by 0x66 is ANDPD.

Updates #14069

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

We generate code that calls each user init function one at a time.
When there are lots of user init functions,
usually due to generated code, like test/rotate* or
github.com/juju/govmomi/vim25/types,
we can end up with a giant function,
which can be slow to compile.

This CL puts in an escape valve.
When there are more than 500 functions, instead of doing:

init.0()
init.1()
// ...

we construct a static array of functions:

var fns = [...]func(){init.0, init.1, ... }

and call them in a loop.

This generates marginally bigger, marginally worse code,
so we restrict it to cases in which it might start to matter.

500 was selected as a mostly arbitrary threshold for "lots".
Each call uses two Progs, one for PCDATA and one for the call,
so at 500 calls we use ~1000 Progs.
At concurrency==8, we get a Prog cache of about
1000 Progs per worker.
So a threshold of 500 should more or less avoid
exhausting the Prog cache in most cases.

Change-Id: I276b887173ddbf65b2164ec9f9b5eb04d8c753c2
Reviewed-on: https://go-review.googlesource.com/41500Reviewed-by: Keith Randall <khr@golang.org>

overLoadFactor used a uintptr for its calculations.
When the number of potential buckets was large,
perhaps due to a coding error or corrupt/malicious user input
leading to a very large map size hint,
this led to overflow on 32 bit systems.
This overflow resulted in an infinite loop.

Prevent it by always using a 64 bit calculation.

Updates #20195

Change-Id: Iaabc710773cd5da6754f43b913478cc5562d89a2
Reviewed-on: https://go-review.googlesource.com/42185
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>