When functions are inlined, for instructions in the inlined body, does
-S print the location of the call, or the location of the body? Right
now, we do the former. I'd like to do the latter by default, it makes
much more sense when reading disassembly. With mid-stack inlining
enabled in more cases, this quandry will come up more often.

The original behavior is still available with -S=2. Some tests
use this mode (so they can find assembly generated by a particular
source line).

This helped me with understanding what the compiler was doing
while fixing #29007.

Change-Id: Id14a3a41e1b18901e7c5e460aa4caf6d940ed064
Reviewed-on: https://go-review.googlesource.com/c/153241Reviewed-by: David Chase <drchase@google.com>

[root] reports whether the current effective user ID is 0.

Updates #29127

Change-Id: I9ef42f1271ea669689011e7ceff4d918c0cecb6b
Reviewed-on: https://go-review.googlesource.com/c/153637
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

This commit adds support to read XCOFF files and AIX big archives in
go/internal/gccgoimporter.

Fixes: #29113

Change-Id: Id84d40358ff98fae5a576d1ebdd65980896365b9
Reviewed-on: https://go-review.googlesource.com/c/152720
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

Change-Id: I5d4f65553f6c368d101be59aae9440f5ec9573b7
Reviewed-on: https://go-review.googlesource.com/c/153461
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

This commit adds support to read AIX big archive inside internal/xcoff
package.

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

The OpenBSD arm port switched to EABI in September 2016 - this revises the layout
of the runtime definitions to match what the kernel currently uses.

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

The set of bad pointer typedefs changes as we see more typedefs, so
avoid looking in the cache when we find one.

Fixes #29175

Change-Id: Idd82289bdd8628d11a983fa5ec96517e3a5bcbf1
Reviewed-on: https://go-review.googlesource.com/c/153597
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Per comment on CL 120316.

Updates #25280

Change-Id: I7d078de4030bd10934468e04ff696a34749bd454
Reviewed-on: https://go-review.googlesource.com/c/153500
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

Saves about 35% on total test time on my laptop.

Fixes #26471

Change-Id: I15b28b1bc00f889934d577dc7996864bbab10105
Reviewed-on: https://go-review.googlesource.com/c/153499
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

This avoids a warning from old versions of the GNU linker or glibc.

No test because these old versions are not readily available.
I tested this by hand on CentOS 6.

Fixes #28722

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

CL 122575 and its successors introduced a loop calling loadDWARF,
whereas before we only called it once. Pass a single typeConv to each
call, rather than creating a new one in loadDWARF itself. Change the
maps from dwarf.Type to use string keys rather than dwarf.Type keys,
since when the DWARF is reloaded the dwarf.Type pointers will be
different. These changes permit typeConv.Type to return a consistent
value for a given DWARF type, avoiding spurious type conversion errors
due to typedefs loaded after the first loop iteration.

Fixes #27340

Change-Id: Ic33467bbfca4c54e95909621b35ba2a58216d96e
Reviewed-on: https://go-review.googlesource.com/c/152762
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

Fixes #25065

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

The https scheme is supported, and should be used per best practices.

The previous http link redirected to https:

	$ curl -i 'http://oss-security.openwall.org/wiki/mailing-lists/distros'
	HTTP/1.1 302 Moved Temporarily
	Location: https://oss-security.openwall.org/wiki/mailing-lists/distros

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

When converting a method to a function, like this:

type T ...
func (t T) foo() {
}
var t T
f := t.foo

We need to build a wrapper function for the partially evaluated
method. Currently that wrapper function gets the line number of
the first place where t.foo appears. Instead it should have the
line number of where foo is declared.

Fixes #26839

Change-Id: I7dbe2094e53d5d336f329273f10f8430e0af544e
Reviewed-on: https://go-review.googlesource.com/c/153498
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

Without this, each additional C frame found via SetCgoTraceback will
cause a frame to be dropped from the bottom of the traceback stack.

Fixes #29034

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

At the moment, the cover tool does not check that the argument of -var
is a valid identifier. Hence, it could generate a file that fails to
compile afterwards.

Updates #25280

Change-Id: I6eb1872736377680900a18a4a28ba002ab5ea8ca
Reviewed-on: https://go-review.googlesource.com/c/120316
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Replace the 128-bit multiplication in 4 parts with bits.Mul64
and two single-width multiplications.  This simplifies the code
and increases throughput by ~50% on amd64.

name         old time/op   new time/op   delta
Fnv128KB-4    9.64µs ± 0%   6.09µs ± 0%  -36.89%  (p=0.016 n=4+5)
Fnv128aKB-4   9.11µs ± 0%   6.17µs ± 5%  -32.32%  (p=0.008 n=5+5)

name         old speed     new speed     delta
Fnv128KB-4   106MB/s ± 0%  168MB/s ± 0%  +58.44%  (p=0.016 n=4+5)
Fnv128aKB-4  112MB/s ± 0%  166MB/s ± 5%  +47.85%  (p=0.008 n=5+5)

Change-Id: Id752f2a20ea3de23a41e08db89eecf2bb60b7e6d
Reviewed-on: https://go-review.googlesource.com/c/133936
Run-TryBot: Matt Layher <mdlayher@gmail.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matt Layher <mdlayher@gmail.com>
Reviewed-by: Robert Griesemer <gri@golang.org>

I think we ought to make these tests hermetic, but in the meantime we
should at least make them pass.

Fixes #27692
Updates #28856

Change-Id: Ia78fa60e998dea3c871f640ffa2ece67b054f866
Reviewed-on: https://go-review.googlesource.com/c/153460
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>

Fixes #26144

Change-Id: Ie69dab1bd819eaf158be11769903b2636bbcf516
Reviewed-on: https://go-review.googlesource.com/c/152165
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Nikhil Benesch <nikhil.benesch@gmail.com>

Since CL 148517, several commands (including list and get) work when
GO111MODULE=on even when no go.mod file is present. This broke an
assumption made by "fix" and "generate" which caused panics when run
with a list of .go files (whether or not the command was run inside a
module).

This change fixes those assumptions and adds test cases for other
commands run outside modules.

Fixes #29097

Change-Id: I7927559769c5d4617d73eb63f3b17e2f26d8c219
Reviewed-on: https://go-review.googlesource.com/c/153158Reviewed-by: Bryan C. Mills <bcmills@google.com>

Fixes #25953

Change-Id: I4f3a64b42fce76cc5ea6cfe2888d103c7423457d
Reviewed-on: https://go-review.googlesource.com/c/126736Reviewed-by: Bryan C. Mills <bcmills@google.com>

This commit moves cmd/internal/xcoff package to internal/xcoff because
it will be needed to add XCOFF support in go/internal/gccgoimporter.

Change-Id: Id12df0c438fb7db4a6a458fc1478480851bf7771
Reviewed-on: https://go-review.googlesource.com/c/152719
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

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

TrailingZeros16 is the only one of the TrailingZeros functions with a
named return value in the signature. This creates a sligthly
unpleasant effect in the godoc listing:

  func TrailingZeros(x uint) int
  func TrailingZeros16(x uint16) (n int)
  func TrailingZeros32(x uint32) int
  func TrailingZeros64(x uint64) int
  func TrailingZeros8(x uint8) int

Since the named return value is not even used, remove it.

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

Also skip TestNooptCgoBuild in short mode.

Also fix a couple of obscure constants to use values named in
cmd/internal/dwarf.

This brings the time of the cmd/link/internal/ld tests down to about 1
second on my laptop.

Updates #26470

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

IsSliceInBounds(x, y) asserts that y is not negative, but
there were cases where this is not true.  Change code
generation to ensure that this is true when it's not obviously
true.  Prove phase cleans a few of these out.

With this change the compiler text section is 0.06% larger,
that is, not very much.  Benchmarking still TBD, may need
to wait for access to a benchmarking box (next week).

Also corrected run.go to handle '?' in -update_errors output.

Fixes #28797.

Change-Id: Ia8af90bc50a91ae6e934ef973def8d3f398fac7b
Reviewed-on: https://go-review.googlesource.com/c/152477
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

To prevent confusion, go mod init should not allow version strings in
the module path when provided as an argument. Instead, fail with a
useful error message.

Fixes #28803

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

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

Fixes #26917

Change-Id: I676f016ed43aaa523b6d3a87b28a1d1d2ebe72c4
Reviewed-on: https://go-review.googlesource.com/c/153237
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

That file is supposed to make unexpected dependencies on the main
module easier to diagnose in 'go test cmd/go', but I accidentally left
off the build constraint, so it was triggering outside of the test.

Updates #29097

Change-Id: I1cde3fe6c1d80add37c98a8c95ce48524ea05024
Reviewed-on: https://go-review.googlesource.com/c/153159
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>

After a recent change to runtime-gdb_test.go the ppc64le builder
has had intermittent failures. The failures occur when trying to
invoke the goroutineCmd function to display the backtrace for
a selected goroutine. There is nothing wrong with the testcase
but it seems to intermittently leave goroutines in a state
where an error can occur.

The error message indicates that the problem occurs when trying
to change the sp back to the original after displaying the
stacktrace for the goroutine.

gdb.error: Attempt to assign to an unmodifiable value.

After some searching I found that this error message can happen
if the sp register is changed when on a frame that is not the
top-most frame. To fix the problem, frame 0 is selected before
changing the value of sp. This fixes the problem in my
reproducer environment, and hopefully will fix the problem on
the builder.

Updates #28679

Change-Id: I329bc95b30f8c95acfb161b0d9cfdcbd917a1954
Reviewed-on: https://go-review.googlesource.com/c/152540
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

A mark worker goroutine may attempt to preempt the mark termination
goroutine to scan its stack while the mark termination goroutine is
trying to preempt that worker to flush its work buffer, in rare
cases.

This change makes it so that, like a worker goroutine, the mark
termination goroutine stack is preemptible while it is on the
system stack, attempting to preempt others.

Fixes #28695.

Change-Id: I23bbb191f4fdad293e8a70befd51c9175f8a1171
Reviewed-on: https://go-review.googlesource.com/c/153077Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Austin Clements <austin@google.com>

Updates #26241

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

Updates #28152

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

I didn't bother with a test as there doesn't seem to be an existing
framework for testing assembler failures, and tests for invalid code
aren't all that interesting.

Fixes #26700

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

Fixes #27736.

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

This speeds up the cmd/cover testsuite by about 40% on my laptop.

Updates #26473
Updates #28386

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

After CL 128056 the build fails on darwin/386 with

  src/crypto/x509/root_cgo_darwin.go:218:55: warning: values of type 'SInt32' should not be used as format arguments; add an explicit cast to 'int' instead [-Wformat]
  go build crypto/x509: C compiler warning promoted to error on Go builders

Fix the warning by explicitly casting the argument to an int as
suggested by the warning.

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

If the replacements specify one or more versions, we choose the latest
(for consistency with the QueryPackage path, with resolves the latest
version from upstream).

Otherwise, we synthesize a pseudo-version with a zero timestamp and an
appropriate major version.

Fixes #26241

RELNOTE=yes

Change-Id: I14b4c63858c8714cc3e1b05ac52c33de5a16dea9
Reviewed-on: https://go-review.googlesource.com/c/152739Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

In order to further diagnose #27993, I need to see exactly what
pointers are being added to the gcWork buffer too late.

Change-Id: I8d92113426ffbc6e55d819c39e7ab5eafa68668d
Reviewed-on: https://go-review.googlesource.com/c/152957
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>