Fixes #29627

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

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

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

Follow the convertion (https://golang.org/s/generatedcode) for generated
code in fastlog2table.go

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

The kqueue based netpoller always registers file descriptors with EVFILT_READ and EVFILT_WRITE.
However only EVFILT_READ notification is supported for regular files.
On FreeBSD a regular file is always reported as ready for writing, resulting in a busy wait.
On Darwin, Dragonfly, NetBSD and OpenBSD, a regular file is reported as ready for both reading and writing only once.

Updates #19093

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

Fixes #29387

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

Updates #24331

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

Returning the innermost frame instead of the outermost
makes code that walks the results of runtime.Caller{,s}
still work correctly in the presence of mid-stack inlining.

Fixes #29582

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

It was recently updated (again) to version 2018i. Since we're here,
wrap the paragraph at ~70 columns, like all the others.

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

Change a link in the cgo section of the 1.12 release notes from

  https://golang.org/cmd/cgo ...

to

  /cmd/cgo/ ...

to uniform it with other links on the page, and to ensure correct
target when the page is displayed on tip.golang.org.

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

In 1.11 we stored "return addresses" in the result of runtime.Callers.
I changed that behavior in CL 152537 to store an address in the call
instruction itself. This CL reverts that part of 152537.

The change in 152537 was made because we now store pcs of inline marks
in the result of runtime.Callers as well. This CL will now store the
address of the inline mark + 1 in the results of runtime.Callers, so
that the subsequent -1 done in CallersFrames will pick out the correct
inline mark instruction.

This CL means that the results of runtime.Callers can be passed to
runtime.FuncForPC as they were before. There are a bunch of packages
in the wild that take the results of runtime.Callers, subtract 1, and
then call FuncForPC. This CL keeps that pattern working as it did in
1.11.

The changes to runtime/pprof in this CL are exactly a revert of the
changes to that package in 152537 (except the locForPC comment).

Update #29582

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

The output refers to 'go help modules-get' but the actual command is 'go
help module-get', singular.

Change-Id: Ie001f4181d80d3bf1995af2f257bf789dad5b33f
GitHub-Last-Rev: ce9b90e9a656fbab097d440458e93ab29ba014af
GitHub-Pull-Request: golang/go#29605
Reviewed-on: https://go-review.googlesource.com/c/156737Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>

The in-tree GDB is too old (6.1.1) on all the builders except the
FreeBSD 12.0 one, where it was removed from the base system.

Update #29508

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

Fixes #29589

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

With gccgo, if a profiling signal arrives in certain time during
traceback, it may crash or hang. The fix is CL 156037 and
CL 156038.  This CL adds a test.

Updates #29448.

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

Updates #22487

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

The original port of Log1p incorrectly translated a ternary statement
so that a correction was only applied to one of the branches.

Fixes #29488

Change-Id: I035b2fc741f76fe7c0154c63da6e298b575e08a4
Reviewed-on: https://go-review.googlesource.com/c/156120
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

Fixes #29545

Change-Id: Ida98c23b8fc5c676d8bf0b3daad8320e495ebf64
GitHub-Last-Rev: d38e8a90c75f92031f6a8cf1f69f7bc7c28a52d8
GitHub-Pull-Request: golang/go#29546
Reviewed-on: https://go-review.googlesource.com/c/156297
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fixes #29543

Change-Id: Ib7f3c32cc1e57c583ee52c486673a5b9568c2df8
GitHub-Last-Rev: 0cb3dc536245bb4f414cf09bb353fbafd5ca7537
GitHub-Pull-Request: golang/go#29544
Reviewed-on: https://go-review.googlesource.com/c/156279
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

The check below can fail incorrectly if the buildid ends with '-p'.

    ! stderr 'compile.* -e .*-p [^z]'

This fix changes regular expressions to '-e.* -p' or '-N.* -p' instead
of '-e .*-p'. '-l' is no longer used because the compiler accepts
multiple flags starting with '-l' ('-e' and '-N' do not have this
problem), so there could be false matches.

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

Change-Id: I321890237f703b945711e59c15233ccf59c4f190
Reviewed-on: https://go-review.googlesource.com/c/156477
Run-TryBot: Gabriel Aszalos <gabriel.aszalos@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Fixes #29555

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

upstream git hash: 1775db3f06b568179d273425900dd09125831dd5

Update #17490

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

Mainly to pull in the bug fix in the structtag pass, where filenames
could sometimes be wrong. The bug wasn't present in 1.11, so it was a
regression and needs fixing before 1.12 is out.

Fixes #29130.

Change-Id: Ie9d9bff84873f34d748ebd8f056b6bc2ac822a55
Reviewed-on: https://go-review.googlesource.com/c/156378
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>

The no-cgo validation hack lets in certificates from the root store that
are not marked as roots themselves, but are signed by a root; the cgo
path correctly excludes them. When TestSystemRoots compares cgo and
no-cgo results it tries to ignore them by ignoring certificates which
pass validation, but expired certificates were failing validation.

Letting through expired certs is harmless anyway because we will refuse
to build chains to them.

Fixes #29497

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

On macOS 10.11, but not 10.10 and 10.12, the C API returns 5 old root
CAs which are not in SystemRootCertificates.keychain (but seem to be in
X509Anchors and maybe SystemCACertificates.keychain, along with many
others that the C API does not return). They all are moribund 1024-bit
roots which are now gone from the Apple store.

Since we can't seem to find a way to make the no-cgo code see them,
ignore them rather than skipping the test.

Fixes #21416

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

The compiler appears to contain several squirrelly corner
cases where nodes are double walked, some where new nodes
are created from walked parts.  Rather than trust that we
had searched hard enough for the last one, change
exprSwitch.walk() to return immediately if it has already
been walked.  This appears to be the only case where
double-walking a node is actually harmful.

Fixes #29562.

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

A workaround has been submitted.

Updates #27993

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

These updates have been automatically generated using a modified
version of the updateac command with the following changes:

-	code to automatically update the AUTHORS file has been removed,
	since we're not updating that file automatically after Go 1.11
	(see CL 128877)
-	CLA checking code has been removed, since it was primarily needed
	for updating the AUTHORS file
-	instead of executing the misc/sortac binary, its code was embedded
	into the updateac command itself

The modified updateac command will be added to x/build repository soon,
and the misc/sortac command can be removed afterwards.

Updates #12042

Change-Id: Ibf73068698b14b1aad4df4490747b488508ff5fd
Reviewed-on: https://go-review.googlesource.com/c/156278Reviewed-by: Filippo Valsorda <filippo@golang.org>

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

Fixes #29439
Updates #28466

Change-Id: Ifa0779a089a969f99f1a47127e23565f31eec24f
Reviewed-on: https://go-review.googlesource.com/c/155929Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>

Fixes #29541

Change-Id: I006915b020b6e710298c32c05e3de77a7f9b54f3
GitHub-Last-Rev: c7a90a4bbe17fd1904c0942e8b343264fb85cba1
GitHub-Pull-Request: golang/go#29542
Reviewed-on: https://go-review.googlesource.com/c/156277
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Fixes #23899
Fixes #28458

Change-Id: Ie177f2d4c399445d8d5e1a327f2419c7866cb45e
Reviewed-on: https://go-review.googlesource.com/c/155697
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>

We still don't understand what's causing there to be remaining GC work
when we enter mark termination, but in order to move forward on this
issue, this CL implements a work-around for the problem.

If debugCachedWork is false, this CL does a second check for remaining
GC work as soon as it stops the world for mark termination. If it
finds any work, it starts the world again and re-enters concurrent
mark. This will increase STW time by a small amount proportional to
GOMAXPROCS, but fixes a serious correctness issue.

This works-around #27993.

Change-Id: Ia23b85dd6c792ee8d623428bd1a3115631e387b8
Reviewed-on: https://go-review.googlesource.com/c/156140
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Rick Hudson <rlh@golang.org>

This test case failed on the longtest builder. It relied on
runtime/internal/atomic not being compiled with the -l flag in the
cache. The test case now creates its own GOCACHE, similar to
build_cache_compile and a few others.

Also, mention the correct issue the test case verifies.

Fixes #29395

Change-Id: Id50e9dfc50db03fb11582d3dd6b69c3e1ed750eb
Reviewed-on: https://go-review.googlesource.com/c/156237
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

As a followon to CL 152537, modify the panic-printing traceback
to also handle mid-stack inlining correctly.

Also declare -fm functions (aka method functions) as wrappers, so that
they get elided during traceback. This fixes part 2 of #26839.

Fixes #28640
Fixes #24488
Update #26839

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

Use the length of the bitmap to decide how much to pass to the
write barrier, not the total length of the arguments.

The test needs enough arguments so that two distinct bitmaps
get interpreted as a single longer bitmap.

Update #29362

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

Fixes #29517

Change-Id: I7e741d82bb9f8e6ab39b6d9ab37ba6163176a097
GitHub-Last-Rev: 764d0bd9579cd90868c6a134cbb06dda584474d7
GitHub-Pull-Request: golang/go#29519
Reviewed-on: https://go-review.googlesource.com/c/156118Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Derived	from Naoki's reproducer.

Update #29362

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

After CL 31455, "go fun(n)" may put "n" to write barrier buffer
when there are no pointers in fun's arguments.

Fixes #29362

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