_main has an early check to verify if a binary is statically or dynamically
linked that depends on R0 being zero. R0 is not guaranteed to be zero at that
point and this was breaking Go on Alpine for ppc64le.

Change-Id: I4a1059ff7fd3db6fc489e7dcfe631c1814dd965b
Reviewed-on: https://go-review.googlesource.com/54730
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>

The gofmt bug in question seems to be fixed (at least gofmt doesn't
complain), so reenable the commented-out ... test.

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

This implements trunc, floor, and ceil in the math package
as intrinsics on ppc64x.  Significant improvement mainly due
to avoiding call overhead of args and return value.

BenchmarkCeil-16                    5.95          0.69          -88.40%
BenchmarkFloor-16                   5.95          0.69          -88.40%
BenchmarkTrunc-16                   5.82          0.69          -88.14%

Updates #21390

Change-Id: I951e182694f6e0c431da79c577272b81fb0ebad0
Reviewed-on: https://go-review.googlesource.com/54654
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com>
Reviewed-by: David Chase <drchase@google.com>

This change adds a better implementation in asm for AddMulVVW and
mulAddVWW for ppc64x, with speedups up to 1.54x.

benchmark                       old ns/op     new ns/op     delta
BenchmarkAddMulVVW/1-8          6.58          6.29          -4.41%
BenchmarkAddMulVVW/2-8          7.43          7.25          -2.42%
BenchmarkAddMulVVW/3-8          8.95          8.15          -8.94%
BenchmarkAddMulVVW/4-8          10.1          9.37          -7.23%
BenchmarkAddMulVVW/5-8          12.0          10.7          -10.83%
BenchmarkAddMulVVW/10-8         22.1          20.1          -9.05%
BenchmarkAddMulVVW/100-8        211           154           -27.01%
BenchmarkAddMulVVW/1000-8       2046          1450          -29.13%
BenchmarkAddMulVVW/10000-8      20407         14793         -27.51%
BenchmarkAddMulVVW/100000-8     223857        145548        -34.98%

benchmark                       old MB/s     new MB/s     speedup
BenchmarkAddMulVVW/1-8          9719.88      10175.79     1.05x
BenchmarkAddMulVVW/2-8          17233.97     17657.54     1.02x
BenchmarkAddMulVVW/3-8          21446.05     23550.49     1.10x
BenchmarkAddMulVVW/4-8          25375.70     27334.33     1.08x
BenchmarkAddMulVVW/5-8          26650.52     30029.34     1.13x
BenchmarkAddMulVVW/10-8         28984.29     31833.68     1.10x
BenchmarkAddMulVVW/100-8        30249.41     41531.69     1.37x
BenchmarkAddMulVVW/1000-8       31273.35     44108.54     1.41x
BenchmarkAddMulVVW/10000-8      31360.47     43263.54     1.38x
BenchmarkAddMulVVW/100000-8     28589.58     43971.66     1.54x

Change-Id: I8a8105d4da3592afdef3125757a99f378a0254bb
Reviewed-on: https://go-review.googlesource.com/53931
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>

Change-Id: Icdd0566d3b7dbc034256e16f8a6b6f1af07069b3
Reviewed-on: https://go-review.googlesource.com/54350Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

As noted in the TODO comment, the sticky bit is only used
when the rounding bit is zero or the rounding mode is
ToNearestEven.  This change makes that check explicit and
will eliminate half the sticky bit calculations on average
when rounding mode is not ToNearestEven.

Change-Id: Ia4709f08f46e682bf97dabe5eb2a10e8e3d7af43
Reviewed-on: https://go-review.googlesource.com/54111Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>

Although mincore is declared in stubs.go, mincore isn't used by any
OSes except linux. Move it to os_linux.go and clean up unused code.

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

This parameter is always false. The last occurrence of s.skipSpace(true)
was removed in mid-2015.

While at it, merge skipSpace into SkipSpace, since the latter was just a
wrapper without the parameter.

Found with github.com/mvdan/unparam.

Change-Id: I884ea4036f41234a898d6aeee515211c49b0b435
Reviewed-on: https://go-review.googlesource.com/52890Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Avelino <t@avelino.xxx>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>

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

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

The current logic in writeHeader attempts to encode the Header in one
format and if it discovered that it could not it would attempt to
switch to a different format mid-way through. This makes it very
hard to reason about what format will be used in the end and whether
it will even be a valid format.

Instead, we should verify from the start what formats are allowed
to encode the given input Header. If no formats are possible,
then we can return immediately, rejecting the Header.

For now, we continue on to the hairy logic in writeHeader, but
a future CL can split that logic up and specialize them for each
format now that we know what is possible.

Update #9683
Update #12594

Change-Id: I8406ea855dfcb8b478a03a7058ddf8b2b09d46dc
Reviewed-on: https://go-review.googlesource.com/54433
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

I also wanted to test net sockets, but I do not know how to
access their file handles. So I did not implement socket tests.

Updates #21172

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

The prior logic would over-write the NUL-terminator if the octal value
was long enough. In order to prevent this, we add a fitsInOctal function
that does the proper check.

The relevant USTAR specification about NUL-terminator is:
<<<
Each numeric field is terminated by one or more <space> or NUL characters.
>>>

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

USTAR and GNU strings are NUL-terminated. Thus, we should never
allow the NUL terminator, otherwise we will lose data round-trip.

Relevant specification text:
<<<
The fields magic, uname, and gname are character strings each terminated by a NUL character.
>
> Technically, PAX keys and values should be UTF-8, but the observance
> of invalid files in the wild causes us to be more liberal.
> <<<
> The <length> field, <blank>, <equals-sign>, and <newline> shown shall
> be limited to the portable character set, as encoded in UTF-8.

Thus, we only reject NULs in PAX keys, and NULs for PAX values
representing the USTAR string fields (i.e., path, linkpath, uname, gname).
These are treated more strictly because they represent strings that
are typically represented as C-strings on POSIX systems.

Change-Id: I305b794d9d966faad852ff660bd0b3b0964e52bf
Reviewed-on: https://go-review.googlesource.com/14724
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Given that sparse file logic is not trivial, there should be a test
in TestPartialRead to ensure that partial reads work.

Change-Id: I913da3e331da06dca6758a8be3f5099abba233a6
Reviewed-on: https://go-review.googlesource.com/54430
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

The encoding/hex package provides a nice Dump formatter that
prints both hex and ASCII. Use that instead for better visual
debugging of binary diffs.

Change-Id: Iad1084e8e52d7d523595e97ae20912657cea2ab5
Reviewed-on: https://go-review.googlesource.com/14729
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Prior to Go1.8, the Writer had a bug where it would output
an invalid tar file in certain rare situations because the logic
incorrectly believed that the old GNU format had a prefix field.
This is wrong and leads to an output file that mangles the
atime and ctime fields, which are often left unused.

In order to continue reading tar files created by former, buggy
versions of Go, we skeptically parse the atime and ctime fields.
If we are unable to parse them and the prefix field looks like
an ASCII string, then we fallback on the pre-Go1.8 behavior
of treating these fields as the USTAR prefix field.

Note that this will not use the fallback logic for all possible
files generated by a pre-Go1.8 toolchain. If the generated file
happened to have a prefix field that parses as valid
atime and ctime fields (e.g., when they are valid octal strings),
then it is impossible to distinguish between an valid GNU file
and an invalid pre-Go1.8 file.

Fixes #21005

Change-Id: Iebf5c67c08e0e46da6ee41a2e8b339f84030dd90
Reviewed-on: https://go-review.googlesource.com/53635
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

In Go1.0, Writer.Flush used to finish off the current file with zeros
(if it was not already finished) and then write the padding.

Since Go1.1, a regression was made (https://golang.org/cl/5777064) where it was
an error to call Flush if the current file was incomplete. Thus, Flush now only
writes out the final padding bytes, which arguably isn't very useful to anyone.
Since this has been the behavior of Flush for 9 releases of Go (1.1 to 1.9),
we should keep this behavior and just simplify the logic.

We also mark the method as deprecated since it serves no purpose.

Change-Id: I94610d942cb75cad495efd8cf799c1a275a21751
Reviewed-on: https://go-review.googlesource.com/54434
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

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

Change-Id: I78f4ec32c6445015ce626a552edcba561eb650fa
Reviewed-on: https://go-review.googlesource.com/54710Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>

https://golang.org/cl/37508 added an escape analysis test for #12397 to
escape2.go but missed to add it to escape2n.go. The comment at the top
of the former states that the latter should contain all the same tests
and the tests only differ in using -N to compile. Conform to this by
adding the function issue12397 to escape2n.go as well.

Also fix a whitespace difference in escape2.go, so the two files match
exactly (except for the comment at the top).

Change-Id: I3a09cf95169bf2150a25d6b4ec9e147265d36760
Reviewed-on: https://go-review.googlesource.com/54610Reviewed-by: Avelino <t@avelino.xxx>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>

Updates #21352

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

This computes the maximum possible waste in a size class due to both
internal and external fragmentation as a percent of the span size.
This parallels the reasoning about overhead in the comment at the top
of mksizeclasses.go and confirms that comment's assertion that (except
for the few smallest size classes), none of the size classes have
worst-case internal and external fragmentation simultaneously.

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

Change-Id: I9d77655026f16a41a77bd0036d693a40cdd6d52f
Reviewed-on: https://go-review.googlesource.com/52090Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Change-Id: I2eb4f9531372c792a98578560e946d803ad96da8
Reviewed-on: https://go-review.googlesource.com/54411Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>

Ranging over a nil slice is a no-op, so guarding it with a nil check is
not useful.

Found with honnef.co/go/tools/cmd/staticcheck.

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

Before this CL, whenever the Go runtime wanted to kill its own
process with a signal dieFromSignal would reset the signal handler
to _SIG_DFL.

Unfortunately, if any signal handler were installed before the Go
runtime initialized, it wouldn't be invoked either.

Instead, use whatever signal handler was installed before
initialization.

The motivating use case is Crashlytics on Android. Before this CL,
Crashlytics would not consider a crash from a panic() since the
corresponding SIGABRT never reached its signal handler.

Updates #11382
Updates #20392 (perhaps even fixes it)
Fixes #19389

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

To avoid gigantic core dumps, the runtime avoids raising SIGABRT
on crashes on 64-bit Darwin systems. Mobile OS'es (probably) don't
generate huge core dumps, so to aid crash reporters, allow SIGABRT
on crashes on darwin/arm64.

Change-Id: I4a29608f400967d76f9bd0643fea22244c2da9df
Reviewed-on: https://go-review.googlesource.com/49770
Run-TryBot: Elias Naur <elias.naur@gmail.com>
Reviewed-by: Avelino <t@avelino.xxx>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Probably went unnoticed because HTML normalizes multiple space
characters into one, unless you explicitly ask for them with  .

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

This reverts commit f0b36269.

Reason for revert: this change caused the runtime tests on all linux/amd64 and linux/386 builders to timeout

Change-Id: Idf8cfdfc84540e21e8da403e74df5596a1d9327b
Reviewed-on: https://go-review.googlesource.com/54490Reviewed-by: Matthew Dempsky <mdempsky@google.com>

Fixes #20898.

Change-Id: Ib3a8da34851d8b3681a6802e509fe712d6982df2
Reviewed-on: https://go-review.googlesource.com/47450
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Avelino <t@avelino.xxx>

Mostly node and position parameters that are no longer used.

Also remove an unnecessary node variable while at it.

Found with github.com/mvdan/unparam.

Change-Id: I88f9bd5d20bfc5b0f6f63ea81869daa246175061
Reviewed-on: https://go-review.googlesource.com/54130
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

Change-Id: I23bfaa7e03a21aad4e85baa3bf52bb00c09b75d0
Reviewed-on: https://go-review.googlesource.com/44354Reviewed-by: Adam Langley <agl@golang.org>

If we've already imported a named type, then there's no need to
process its associated methods except to validate that the signature
matches the existing known method.

However, the current import code still creates a new function node for
each method, saves its inline body (if any), and adds the node to the
global importlist. Because of this, the duplicate methods are never
garbage collected.

This CL changes the compiler to avoid amassing uncollectable garbage
or performing any unnecessary processing.

This is particularly noticeable for protobuf-heavy code. For the
motivating Go package, this CL reduced compile max-RSS from ~12GB to
~3GB and compile time from ~65s to ~50s.

Passes toolstash -cmp for std, cmd, and k8s.io/kubernetes/cmd/....

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

Currently, the check for `ctx.Done() == context.Background().Done()`
comes before the check to see if we are ignoring any options.  That
check should be done earlier, so that the options are not silently
ignored.

Fixes #21350

Change-Id: I3704e4209854c7d99f3f92498bae831cabc7e419
Reviewed-on: https://go-review.googlesource.com/53970Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
Run-TryBot: Daniel Theophanes <kardianos@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

The linux getrandom system call returns at most 33554431 = 2^25-1 bytes per
call. The existing behavior for larger reads is to report a failure, because
there appears to have been an unexpected short read. In this case the system
falls back to reading from "/dev/urandom".

This change performs reads of 2^25 bytes or more with multiple calls to
getrandom.

Fixes #20877

Change-Id: I618855bdedafd86cd11219fe453af1d6fa2c88a7
Reviewed-on: https://go-review.googlesource.com/49170Reviewed-by: Adam Langley <agl@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

The current modInverse implementation allocates a big.Int
for the second parameter of GCD, while only the first is needed.
This is unnecessary and can lead to a speed up for optimizations
of GCD where the second parameter is not calculated at all.

Change-Id: I3f042e140ff643311bc3d0b8d192992d4d2c4c70
Reviewed-on: https://go-review.googlesource.com/50531
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filosottile.wiki@gmail.com>
Reviewed-by: Adam Langley <agl@golang.org>

Change-Id: I30563d31f6acea594cc853cc6b672ec664f90d48
Reviewed-on: https://go-review.googlesource.com/53636Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Now that issue #12438 is resolved, this TODO can be completed.
Create a logf helper, which is similar to Server.logf method,
but takes a *Request to infer the *Server and its ErrorLog from.

Update documentation of Server.ErrorLog to mention a new type
of errors that may be logged to it.

Also update a statement in documentation of Server.ErrorLog from:

	// If nil, logging goes to os.Stderr via the log package's
	// standard logger.

To:

	// If nil, logging is done via the log package's standard logger.

The motivation for doing so is to avoid making inaccurate claims.
Logging may not go to os.Stderr if anyone overrides the log package's
default output via https://godoc.org/log#SetOutput. Saying that
the standard logger is used should be sufficient to explain the
behavior, and users can infer that os.Stderr is used by default,
unless it's changed.

Updates #12438.

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

This change enables buildmode c-shared on ppc64le.

A bug was fixed in runtime/rt0_linux_ppc64le.s that was necessary to
make this work.  In _rt0_ppc64le_linux_lib, there is code to store
the value of r2 onto the caller's stack.  However, if this file
is compiled using a build mode that maintains the TOC address in
r2, then instructions will be inserted at the beginning of this
function to generate the r2 value for the callee, not the caller.
That means the r2 value for the callee is stored onto the caller's
stack.  If caller and callee don't have the same r2 values, then
the caller will restore the wrong r2 value after it returns.  This
situation can happen when using dlopen since the caller of this
function will be in ld64.so and will definitely have a different
TOC.

Updates #20756

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