Clean mod cache should print remove commands and not run them when with set "-n" option.
Fixes #27458.

Change-Id: I97242cb40c062b347784cdb61653c84a3a7eab44
GitHub-Last-Rev: 5a6f10cad8c5f2c3916a74ca5eea27b1fdd1dc38
GitHub-Pull-Request: golang/go#27710
Reviewed-on: https://go-review.googlesource.com/135695
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>

Since there are no nested loops and/or switches,
loop label can be removed and "bare continue" can be used.

Change-Id: Id642a0859299e4470af544d59884fec51dbb31ee
Reviewed-on: https://go-review.googlesource.com/135837Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Teach samesafeexpr to handle arithmetic unary and binary ops.

It makes map lookup optimization possible in

	m[k+1] = append(m[k+1], ...)
	m[-k] = append(m[-k], ...)
	... etc

Does not cover "+" for strings (concatenation).

Change-Id: Ibbb16ac3faf176958da344be1471b06d7cf33a6c
Reviewed-on: https://go-review.googlesource.com/135795
Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

Change-Id: I4ee4f702e1bfc9ad9ea899c255104d5e18cf2c96
Reviewed-on: https://go-review.googlesource.com/135838Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Currently "arr[idx] |= 0x80" is compiled to MOVLload->BTSL->MOVLstore.
And this CL optimizes it to a single BTSLconstmodify. Other bit wise
operations with a direct memory operand are also implemented.

1. The size of the executable bin/go decreases about 4KB, and the total size
of pkg/linux_amd64 (excluding cmd/compile) decreases about 0.6KB.

2. There a little improvement in the go1 benchmark test (excluding noise).
name                     old time/op    new time/op    delta
BinaryTree17-4              2.66s ± 4%     2.66s ± 3%    ~     (p=0.596 n=49+49)
Fannkuch11-4                2.38s ± 2%     2.32s ± 2%  -2.69%  (p=0.000 n=50+50)
FmtFprintfEmpty-4          42.7ns ± 4%    43.2ns ± 7%  +1.31%  (p=0.009 n=50+50)
FmtFprintfString-4         71.0ns ± 5%    72.0ns ± 3%  +1.33%  (p=0.000 n=50+50)
FmtFprintfInt-4            80.7ns ± 4%    80.6ns ± 3%    ~     (p=0.931 n=50+50)
FmtFprintfIntInt-4          125ns ± 3%     126ns ± 4%    ~     (p=0.051 n=50+50)
FmtFprintfPrefixedInt-4     158ns ± 1%     142ns ± 3%  -9.84%  (p=0.000 n=36+50)
FmtFprintfFloat-4           215ns ± 4%     212ns ± 4%  -1.23%  (p=0.002 n=50+50)
FmtManyArgs-4               519ns ± 3%     510ns ± 3%  -1.77%  (p=0.000 n=50+50)
GobDecode-4                6.49ms ± 6%    6.52ms ± 5%    ~     (p=0.866 n=50+50)
GobEncode-4                5.93ms ± 8%    6.01ms ± 7%    ~     (p=0.076 n=50+50)
Gzip-4                      222ms ± 4%     224ms ± 8%  +0.80%  (p=0.001 n=50+50)
Gunzip-4                   36.6ms ± 5%    36.4ms ± 4%    ~     (p=0.093 n=50+50)
HTTPClientServer-4         59.1µs ± 1%    58.9µs ± 2%  -0.24%  (p=0.039 n=49+48)
JSONEncode-4               9.23ms ± 4%    9.21ms ± 5%    ~     (p=0.244 n=50+50)
JSONDecode-4               48.8ms ± 4%    48.7ms ± 4%    ~     (p=0.653 n=50+50)
Mandelbrot200-4            3.81ms ± 4%    3.80ms ± 3%    ~     (p=0.834 n=50+50)
GoParse-4                  3.20ms ± 5%    3.19ms ± 5%    ~     (p=0.494 n=50+50)
RegexpMatchEasy0_32-4      78.1ns ± 2%    77.4ns ± 3%  -0.86%  (p=0.005 n=50+50)
RegexpMatchEasy0_1K-4       233ns ± 3%     233ns ± 3%    ~     (p=0.074 n=50+50)
RegexpMatchEasy1_32-4      74.2ns ± 3%    73.4ns ± 3%  -1.06%  (p=0.000 n=50+50)
RegexpMatchEasy1_1K-4       369ns ± 2%     364ns ± 4%  -1.41%  (p=0.000 n=36+50)
RegexpMatchMedium_32-4      109ns ± 4%     107ns ± 3%  -2.06%  (p=0.001 n=50+50)
RegexpMatchMedium_1K-4     31.5µs ± 3%    30.8µs ± 3%  -2.20%  (p=0.000 n=50+50)
RegexpMatchHard_32-4       1.57µs ± 3%    1.56µs ± 2%  -0.57%  (p=0.016 n=50+50)
RegexpMatchHard_1K-4       47.4µs ± 4%    47.0µs ± 3%  -0.82%  (p=0.008 n=50+50)
Revcomp-4                   414ms ± 7%     412ms ± 7%    ~     (p=0.285 n=50+50)
Template-4                 64.3ms ± 4%    62.7ms ± 3%  -2.44%  (p=0.000 n=50+50)
TimeParse-4                 316ns ± 3%     313ns ± 3%    ~     (p=0.122 n=50+50)
TimeFormat-4                291ns ± 3%     293ns ± 3%  +0.80%  (p=0.001 n=50+50)
[Geo mean]                 46.5µs         46.2µs       -0.81%

name                     old speed      new speed      delta
GobDecode-4               118MB/s ± 6%   118MB/s ± 5%    ~     (p=0.863 n=50+50)
GobEncode-4               130MB/s ± 9%   128MB/s ± 8%    ~     (p=0.076 n=50+50)
Gzip-4                   87.4MB/s ± 4%  86.8MB/s ± 7%  -0.78%  (p=0.002 n=50+50)
Gunzip-4                  531MB/s ± 5%   533MB/s ± 4%    ~     (p=0.093 n=50+50)
JSONEncode-4              210MB/s ± 4%   211MB/s ± 5%    ~     (p=0.247 n=50+50)
JSONDecode-4             39.8MB/s ± 4%  39.9MB/s ± 4%    ~     (p=0.654 n=50+50)
GoParse-4                18.1MB/s ± 5%  18.2MB/s ± 5%    ~     (p=0.493 n=50+50)
RegexpMatchEasy0_32-4     410MB/s ± 2%   413MB/s ± 3%  +0.86%  (p=0.004 n=50+50)
RegexpMatchEasy0_1K-4    4.39GB/s ± 3%  4.38GB/s ± 3%    ~     (p=0.063 n=50+50)
RegexpMatchEasy1_32-4     432MB/s ± 3%   436MB/s ± 3%  +1.07%  (p=0.000 n=50+50)
RegexpMatchEasy1_1K-4    2.77GB/s ± 2%  2.81GB/s ± 4%  +1.46%  (p=0.000 n=36+50)
RegexpMatchMedium_32-4   9.16MB/s ± 3%  9.35MB/s ± 4%  +2.09%  (p=0.001 n=50+50)
RegexpMatchMedium_1K-4   32.5MB/s ± 3%  33.2MB/s ± 3%  +2.25%  (p=0.000 n=50+50)
RegexpMatchHard_32-4     20.4MB/s ± 3%  20.5MB/s ± 2%  +0.56%  (p=0.017 n=50+50)
RegexpMatchHard_1K-4     21.6MB/s ± 4%  21.8MB/s ± 3%  +0.83%  (p=0.008 n=50+50)
Revcomp-4                 613MB/s ± 4%   618MB/s ± 7%    ~     (p=0.152 n=48+50)
Template-4               30.2MB/s ± 4%  30.9MB/s ± 3%  +2.49%  (p=0.000 n=50+50)
[Geo mean]                127MB/s        128MB/s       +0.64%

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

Change-Id: I5afba2c10372252be4b65dae7a95461722de904f
Reviewed-on: https://go-review.googlesource.com/135835Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

AMD64's ADDQconstmodify/ADDLconstmodify have similar logic with
other constmodify like operators, but seperated case statements.
This CL simplify them with a fallthrough.

Change-Id: Ia73ffeaddc5080182f68c06c9d9b48fe32a14e38
Reviewed-on: https://go-review.googlesource.com/135855
Run-TryBot: Ben Shi <powerman1st@163.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

Updates #26148

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

The rules are subtle, but under some circumstances the result
can be constant. Mention this and refer to the appropriate
section of the specification.

Fixes #27588.

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

That optimization is not valid if x == -0.

The test is a bit tricky because 0 == -0. We distinguish
0 from -0 with 1/0 == inf, 1/-0 == -inf.

This has been a bug since CL 24790 in Go 1.8. Probably doesn't
warrant a backport.

Fixes #27718

Note: the optimization x-0 -> x is actually valid.
But it's probably best to take it out, so as to not confuse readers.

Change-Id: I99f16a93b45f7406ec8053c2dc759a13eba035fa
Reviewed-on: https://go-review.googlesource.com/135701Reviewed-by: Cherry Zhang <cherryyz@google.com>

They aren't really races, or at least they don't have any
observable effect. The spec is silent on whether these are actually
races or not.

Fix this problem by not using the address of len (or of cap)
as the location where channel operations are recorded to occur.
Use a random other field of hchan for that.

I'm not 100% sure we should in fact fix this. Opinions welcome.

Fixes #27070

Change-Id: Ib4efd4b62e0d1ef32fa51e373035ef207a655084
Reviewed-on: https://go-review.googlesource.com/135698Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

On Linux, sysUnused currently uses madvise(MADV_DONTNEED) to signal the
kernel that a range of allocated memory contains unneeded data. After a
successful call, the range (but not the data it contained before the
call to madvise) is still available but the first access to that range
will unconditionally incur a page fault (needed to 0-fill the range).

A faster alternative is MADV_FREE, available since Linux 4.5. The
mechanism is very similar, but the page fault will only be incurred if
the kernel, between the call to madvise and the first access, decides to
reuse that memory for something else.

In sysUnused, test whether MADV_FREE is supported and fall back to
MADV_DONTNEED in case it isn't. This requires making the return value of
the madvise syscall available to the caller, so change runtime.madvise
to return it.

Fixes #23687

Change-Id: I962c3429000dd9f4a00846461ad128b71201bb04
Reviewed-on: https://go-review.googlesource.com/135395
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

For types defined as:

type typename struct { ... }

the linker produces two DIEs: (1) a DW_TAG_structure_type DIE and (2) a
DW_TAG_typedef_type DIE having (1) as its type attribute.

All subsequent references to 'typename' should use the
DW_TAG_typedef_type DIE, not the DW_TAG_structure_type. Mostly this is
true but sometimes one reference will use the DW_TAG_structure_type
directly. In particular, this happens to the 'first' reference to the
type in question (where 'first' means whatever happens first in the way
the linker scans its symbols).

This isn't only true of struct types: pointer types, array types, etc.
can also be affected.

This fix solves the problem by always returning the typedef DIE in
newtype, when one is created.

Fixes #27614

Change-Id: Ia65b4a1d8c2b752e33a4ebdb74ccd92faa69526e
Reviewed-on: https://go-review.googlesource.com/134555
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>

Fixes #27731

Change-Id: Ifb4d57923b1bba0210ec1f623d779d7b5f442812
Reviewed-on: https://go-review.googlesource.com/135995
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

The -mod=release flag is not supported, so this appears to be a
documentation mistake.

Fixes #27354.

Change-Id: I895e8d5b4918adcb1f605361773173f312fa7b65
GitHub-Last-Rev: 42bfe0c11e38c90e76887771654ea81af98d50ec
GitHub-Pull-Request: golang/go#27358
Reviewed-on: https://go-review.googlesource.com/132116
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>

Makes use of bounded shift information to generate
more efficient shift instructions.

Updates #25167 for ppc64x

Change-Id: I7fc8d49a3fb3e0f273cc51bc767470b239cbdca7
Reviewed-on: https://go-review.googlesource.com/135380
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Munday <mike.munday@ibm.com>

Fixes missing commas where it wasn't immediately apparent whether
"requests" was being used as a verb or a noun.

Change-Id: Ic8c99b4f46475f40a6160d26a3cd11c215940dd5
GitHub-Last-Rev: 1becf6fabeb6f928e37526e96297dd60397ccf9b
GitHub-Pull-Request: golang/go#27649
Reviewed-on: https://go-review.googlesource.com/135135Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>

Change-Id: Idcd79788e64947a927af662b6394ac7218e62ba8
Reviewed-on: https://go-review.googlesource.com/135836Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

According to AMD64.rules, BTS&BTR&BTC use arg1 as the bit index,
while BT uses arg0. This CL fixes the wrong comment message in
AMD64Ops.go, which indicates all bit indexes are in arg0.

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

If a cyclic declaration uses a non-type object where it expects
a type, don't report the cycle error in favor of the clearer and
more informative error about the missing type.

Fixes #25790.

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

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

Fixes: #27298

Change-Id: Icfc6992b470136bb25a77912f670a25883642316
Reviewed-on: https://go-review.googlesource.com/132095Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Use float <-> int register moves without conversion instead of stores
and loads to move float <-> int values.

Math package benchmark results.
name                 old time/op  new time/op  delta
Acosh                 153ns ± 0%   147ns ± 0%   -3.92%  (p=0.000 n=10+10)
Asinh                 183ns ± 0%   177ns ± 0%   -3.28%  (p=0.000 n=10+10)
Atanh                 157ns ± 0%   155ns ± 0%   -1.27%  (p=0.000 n=10+10)
Atan2                 118ns ± 0%   117ns ± 1%   -0.59%  (p=0.003 n=10+10)
Cbrt                  119ns ± 0%   114ns ± 0%   -4.20%  (p=0.000 n=10+10)
Copysign             7.51ns ± 0%  6.51ns ± 0%  -13.32%  (p=0.000 n=9+10)
Cos                  73.1ns ± 0%  70.6ns ± 0%   -3.42%  (p=0.000 n=10+10)
Cosh                  119ns ± 0%   121ns ± 0%   +1.68%  (p=0.000 n=10+9)
ExpGo                 154ns ± 0%   149ns ± 0%   -3.05%  (p=0.000 n=9+10)
Expm1                 101ns ± 0%    99ns ± 0%   -1.88%  (p=0.000 n=10+10)
Exp2Go                150ns ± 0%   146ns ± 0%   -2.67%  (p=0.000 n=10+10)
Abs                  7.01ns ± 0%  6.01ns ± 0%  -14.27%  (p=0.000 n=10+9)
Mod                   234ns ± 0%   212ns ± 0%   -9.40%  (p=0.000 n=9+10)
Frexp                34.5ns ± 0%  30.0ns ± 0%  -13.04%  (p=0.000 n=10+10)
Gamma                 112ns ± 0%   111ns ± 0%   -0.89%  (p=0.000 n=10+10)
Hypot                73.6ns ± 0%  68.6ns ± 0%   -6.79%  (p=0.000 n=10+10)
HypotGo              77.1ns ± 0%  72.1ns ± 0%   -6.49%  (p=0.000 n=10+10)
Ilogb                31.0ns ± 0%  28.0ns ± 0%   -9.68%  (p=0.000 n=10+10)
J0                    437ns ± 0%   434ns ± 0%   -0.62%  (p=0.000 n=10+10)
J1                    433ns ± 0%   431ns ± 0%   -0.46%  (p=0.000 n=10+10)
Jn                    927ns ± 0%   922ns ± 0%   -0.54%  (p=0.000 n=10+10)
Ldexp                41.5ns ± 0%  37.0ns ± 0%  -10.84%  (p=0.000 n=9+10)
Log                   124ns ± 0%   118ns ± 0%   -4.84%  (p=0.000 n=10+9)
Logb                 34.0ns ± 0%  32.0ns ± 0%   -5.88%  (p=0.000 n=10+10)
Log1p                 110ns ± 0%   108ns ± 0%   -1.82%  (p=0.000 n=10+10)
Log10                 136ns ± 0%   132ns ± 0%   -2.94%  (p=0.000 n=10+10)
Log2                 51.6ns ± 0%  47.1ns ± 0%   -8.72%  (p=0.000 n=10+10)
Nextafter32          33.0ns ± 0%  30.5ns ± 0%   -7.58%  (p=0.000 n=10+10)
Nextafter64          29.0ns ± 0%  26.5ns ± 0%   -8.62%  (p=0.000 n=10+10)
PowInt                169ns ± 0%   160ns ± 0%   -5.33%  (p=0.000 n=10+10)
PowFrac               375ns ± 0%   361ns ± 0%   -3.73%  (p=0.000 n=10+10)
RoundToEven          14.0ns ± 0%  12.5ns ± 0%  -10.71%  (p=0.000 n=10+10)
Remainder             206ns ± 0%   192ns ± 0%   -6.80%  (p=0.000 n=10+9)
Signbit              6.01ns ± 0%  5.51ns ± 0%   -8.32%  (p=0.000 n=10+9)
Sin                  70.1ns ± 0%  69.6ns ± 0%   -0.71%  (p=0.000 n=10+10)
Sincos               99.1ns ± 0%  99.6ns ± 0%   +0.50%  (p=0.000 n=9+10)
SqrtGoLatency         178ns ± 0%   146ns ± 0%  -17.70%  (p=0.000 n=8+10)
SqrtPrime            9.19µs ± 0%  9.20µs ± 0%   +0.01%  (p=0.000 n=9+9)
Tanh                  125ns ± 1%   127ns ± 0%   +1.36%  (p=0.000 n=10+10)
Y0                    428ns ± 0%   426ns ± 0%   -0.47%  (p=0.000 n=10+10)
Y1                    431ns ± 0%   429ns ± 0%   -0.46%  (p=0.000 n=10+9)
Yn                    906ns ± 0%   901ns ± 0%   -0.55%  (p=0.000 n=10+10)
Float64bits          4.50ns ± 0%  3.50ns ± 0%  -22.22%  (p=0.000 n=10+10)
Float64frombits      4.00ns ± 0%  3.50ns ± 0%  -12.50%  (p=0.000 n=10+9)
Float32bits          4.50ns ± 0%  3.50ns ± 0%  -22.22%  (p=0.002 n=8+10)
Float32frombits      4.00ns ± 0%  3.50ns ± 0%  -12.50%  (p=0.000 n=10+10)

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

For sweep events, we used to modify the ViewerEvent returned from
ctx.emitSlice later in order to embed more details about the sweep
operation. The trick no longer works after the change
https://golang.org/cl/92375 and caused a regression.

ctx.emit method encodes the ViewerEvent, so any modification to the
ViewerEvent object after ctx.emit returns will not be reflected.

Refactor ctx.emitSlice, so ctx.makeSlice can be used when producing
slices for SWEEP. ctx.emit* methods are meant to truely emit
ViewerEvents.

Fixes #27711

Change-Id: I0b733ebbbfd4facd8714db0535809ec3cab0833d
Reviewed-on: https://go-review.googlesource.com/135775Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

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

Check the size of uintptr instead of listing GOARCHes explicitly. This
will make the test also run on linux/mips{,le}.

Change-Id: I649f15d293002afc1360b1913910202c3e5188b7
Reviewed-on: https://go-review.googlesource.com/135715
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

The CMPconstload opcodes take a ValAndOff as their AuxInt, not just
an offset.

Originally introduced in CL 135379.

Change-Id: I244b2d56ef2e99d2975faa2e97f4291ec97c64b7
Reviewed-on: https://go-review.googlesource.com/135418
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ilya Tocar <ilya.tocar@intel.com>

Change-Id: Ib0544adc1444a473f8edcb9dd92aefa9fcbc7330
Reviewed-on: https://go-review.googlesource.com/134656Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Use the new custom truncate/extension code when storing or extracting
float32 values from AuxInts to avoid the value being changed by the
host platform's floating point conversion instructions (e.g. sNaN ->
qNaN).

Updates #27516.

Change-Id: Id39650f1431ef74af088c895cf4738ea5fa87974
Reviewed-on: https://go-review.googlesource.com/134855
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

Instead of skipping all OSLICEARR, skip only ones with non-pointer
array type. For pointers to arrays, it's safe to apply the
self-assignment slicing optimizations.

Refactored the matching code into separate function for readability.

This is an extension to already existing optimization.

On its own, it does not improve any code under std, but
it opens some new optimization opportunities. One
of them is described in the referenced issue.

Updates #7921

Change-Id: I08ac660d3ef80eb15fd7933fb73cf53ded9333ad
Reviewed-on: https://go-review.googlesource.com/133375
Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

OLEN and OCAP can't affect memory state as long as their
arguments don't.

Re-organized case bodies to avoid duplicating same branches for
recursive invocations.

Change-Id: I30407143429f7dd1891badb70df88969ed267535
Reviewed-on: https://go-review.googlesource.com/133555
Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

Removes a redundant err check and replaces some returns in a testing
loop with continue to prevent skipping unrelated test cases when
a failure is encountered.

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

It's worth clarifying that the language is called "Go".

Fixes #27616.

Change-Id: Ie4a9cb5e7e6afa437c60e06914125ef7490f27d0
Reviewed-on: https://go-review.googlesource.com/135517Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Clarify the behavior of splice on older kernels, merge comments so
control flow becomes more obvious, as discussed in CL 133575.

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

This makes Android consistent with the change in CL 121877.

Updates #20969

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

The cmd/compile/internal/ld/go.go file not exist, actually cmd/link/internal/ld/go.go.
Also, write line number is not good because it changes every commit of the file.

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

Gracefully fallback to a userspace copy when the kernel does not support
splice(2) on a unix domain socket. EINVAL is returned by the splice
syscall if it does not support unix domain sockets. Keeping the handled
return value as false when the first splice call fails with EINVAL will
cause the caller to fall back to a userspace copy.

Fixes #27513

Change-Id: I4b10c1900ba3c096cb32edb7c8a6044f468efb52
Reviewed-on: https://go-review.googlesource.com/133575
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>

In Go 1.11, cmd/go gained support for the GOFLAGS environment variable.
It was added and described in detail in CL 126656.
Mention it in the Go 1.11 release notes, link to the cmd/go documentation,
and add more details there.

Fixes #27282.

Change-Id: Ifc35bfe3e0886a145478d36dde8e80aedd8ec68e
Reviewed-on: https://go-review.googlesource.com/135035Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Rob Pike <r@golang.org>

Currently, when a tz file was being checked inside a zoneInfo dir,
a syscall.ENOENT error was being returned, which caused it to look
in the zoneinfo.zip file and return an error for that case.

We return a syscall.ENOENT error for the zip file case too, so that
it falls through to the end of the loop and returns an uniform error
for both cases.

Fixes #20969

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

This makes TestRuntimePanic keep most of the existing environment,
just as the other runtime tests do.

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