The current implementation of "goroutine N cmd" assumes it can get
goroutine N's state from the goroutine's sched buffer. But this only
works if the goroutine is blocked. Extend find_goroutine so that, if
there is no saved scheduler state for a goorutine, it tries to find
the thread the goroutine is running on and use the thread's current
register state. We also extend find_goroutine to understand saved
syscall register state.

Fixes #13887.

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

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

TestBuildIDContainsArchModeEnv fails on arm64 because defaultGO386 has
different value from x86 (amd64/386). On arm64 defaultGO386 = '387' but
on x86 defaultGO386 = 'sse2'. The difference will make the test succeed
on x86 while fail on arm64 since it generates the same build ID.
Fix it by explicitly setting GO386 instead of using default value

Fixes #20608

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

Fixes #20597.

Change-Id: Iaa059277c02e80a2fbef59cf8bb3c58d2b90fda0
Reviewed-on: https://go-review.googlesource.com/45111Reviewed-by: David Symonds <dsymonds@golang.org>

Fixes #20541.

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

Fixes #19850

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

Remove note that sync.Cond, sync.Mutex, sync.RWMutex and atomic.Value
can be created as part of other data structures. Structs can be embedded
by default, and default should not be repeated.

Fixes #20471.

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

Prep work for issues mentioned below. No semantic or functionality change.

For #11945.
For #17446.

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

This change updates the vendored tzdata database to version 2017b
(released 2017-03-20).

The TestFirstZone test (which always uses the vendored database) is
updated to make it work with the new timezones database. (The Tokelau
abbreviation was changed from 'TKT' to the numeric abbreviation in
tzdata-2017a)

Fixes #19376

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

Fixes #20602.

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

The Tx methods Query and Exec uses context.Background()
even Tx was created by context.
This patch enables using Tx.ctx in all Tx methods
which do not has context arg.
Backward compatibility:
- If Tx has created without context, nothing changes.
- If Tx has created with context and non-context method is called:
  - If context is expired, the execution fails,
    but it can fail on Commit or Rollback as well,
    so in terms of whole transaction - nothing changes.
  - If context is not expired, nothing changes too.

Fixes #20098
Change-Id: I9570a2deaace5875bb4c5dcf7b3a084a6bcd0d00
Reviewed-on: https://go-review.googlesource.com/44956Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Change-Id: Ib5efe172c55ff624b6771c2f02c466e35ba6cc50
Reviewed-on: https://go-review.googlesource.com/45090Reviewed-by: Rob Pike <r@golang.org>

Updates #20587

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

Fixes #20601

Change-Id: I296d50dc5210a735a2a65d64bfef05d14c93057b
Reviewed-on: https://go-review.googlesource.com/45073
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Rhys Hiltner <rhys@justin.tv>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

We insert guard instructions after each "dangerous" instruction
to make NaCl's validator happy. This happens before asmout. If
in asmout an instruction is split to two dangerous instructions,
but only one guard instruction is inserted, the validation fails.
Therefore don't split instructions on NaCl.

Fixes #20595.

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

The new math/bits package has a section for itself, and should not be
mentioned in the 'Minor changes to the library' section of the release
notes.

Updates #20587

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

Updates #20587

Change-Id: I5df603505ae1d4b65687bec1e973a4ab318b34f1
Reviewed-on: https://go-review.googlesource.com/45014Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

Currently the extra Ms created for cgo callbacks have a corresponding
G that's kept in syscall state with only a call to goexit on its
stack. This leads to confusing output from runtime.NumGoroutines and
in tracebacks:

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
	.../src/runtime/asm_amd64.s:2197 +0x1

Fix this by putting this goroutine into state _Gdead when it's not in
use instead of _Gsyscall. To keep the goroutine counts correct, we
also add one to sched.ngsys while the goroutine is in _Gdead. The
effect of this is as if the goroutine simply doesn't exist when it's
not in use.

Fixes #16631.
Fixes #16714.

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

The test is inherently racy, and for me fails about 0.05% of the time.
So only fail the test if it fails ten times in a row.

Fixes #20594

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

As motivated by https://golang.org/design/18130-type-alias which says:

https://github.com/golang/proposal/blob/master/design/18130-type-alias.md#relationship-to-byte-and-rune

> The language specification already defines byte as an alias for
> uint8 and similarly rune as an alias for int32, using the word alias
> as an informal term. It is a goal that the new type declaration
> semantics not introduce a different meaning for alias. That is, it
> should be possible to describe the existing meanings of byte and
> uint8 by saying that they behave as if predefined by:
>
>     type byte = uint8
>     type rune = int32

So, do that. Seems to work.

Updates #18130

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

Update #20178

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

For cgo programs on linux-amd64 we call the C function mmap.
This supports programs such as the C memory sanitizer that need to
intercept all calls to mmap. It turns out that there are programs that
intercept both mmap and munmap, or that at least expect that if they
intercept mmap, they also intercept munmap. So, if we permit mmap
to be intercepted, also permit munmap to be intercepted.

No test, as it requires two odd things: a C program that intercepts
mmap and munmap, and a Go program that calls munmap.

Change-Id: Iec33f47d59f70dbb7463fd12d30728c24cd4face
Reviewed-on: https://go-review.googlesource.com/45016Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Austin Clements <austin@google.com>

Fixes #20591

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

Updates #18354.

Change-Id: I76bc4a73d8dc99eeda14b395e451d75a65184191
Reviewed-on: https://go-review.googlesource.com/45013Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

Fixes #18331

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

Many TODOs remain.

Updates #20587

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

Go doesn't guarantee that the result of floating point operations will
be the same on different architectures. It was not stated in the
documentation, that can lead to confusion.

Fixes #18354

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

This allows reading from package storage systems that may not
preserve the .a suffix (used with -importcfg).

Fixes #20579 (combined with CLs earlier in stack).

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

Adds the ability to specify the file location of each imported package,
like in the -importcfg added to cmd/compile in a related CL.
In effect, -importcfg is a generalization of and supersedes -installsuffix
and -L. Of course, those flags will continue to be supported, for
compatibility with other tools.

Having this flag in Go 1.9 will let us try some experiments involving
package management without needing guinea pigs to build a custom
Go toolchain.

This flag also helps with #14271 at some later point.

For #20579.

Change-Id: Ie4c171bcd3aa2faa446ac340e36516f2f9853882
Reviewed-on: https://go-review.googlesource.com/44851
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Allows reading -importmap options from a file instead of putting
them all on the command line, and adds the ability to specify the
file location of specific packages. In effect, -importcfg is a generalization
of and supersedes -importmap, -importsuffix, and -I.
Of course, those flags will continue to be supported,
for compatibility with other tools.

Having this flag in Go 1.9 will let us try some experiments involving
package management without needing guinea pigs to build a
custom Go toolchain.

This flag also helps with #14271 at some later point.

For #20579.

Change-Id: If005dbc2b01d8fd16cbfd3687dfbe82499f4bc56
Reviewed-on: https://go-review.googlesource.com/44850
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Fixes #18991.

Change-Id: I46ded007b0c6a6e1173a55f3938007ab3a928dd9
Reviewed-on: https://go-review.googlesource.com/44858
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>

Apparently people get confused by the fact that

  Split("", ",")

returns []{""} instead of []{}.

This is actually just a consequence of the fact that if the separator
sep (2nd argument) is not found the string s (1st argument), then the
Split* functions return a length 1 slice with the string s in it.

Document the general case: if sep is not in s, what you get is a len 1
slice with s in it; unless both s and sep are "", in that case you get
an empty slice of length 0.

Fixes #19726

Change-Id: I64c8220b91acd1e5aa1cc1829199e0cd8c47c404
Reviewed-on: https://go-review.googlesource.com/44950Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>

Try to avoid a race between the main goroutine exiting and a panic
occurring. Don't try too hard, to avoid hanging.

Updates #3934
Fixes #20018

Change-Id: I57a02b6d795d2a61f1cadd137ce097145280ece7
Reviewed-on: https://go-review.googlesource.com/41052Reviewed-by: Austin Clements <austin@google.com>

Make sure that in complex division we reject divisors that would
underflow to zero when using the textbook complex-division method we
currently use.

This change does for go/types what golang.org/cl/42650 did for gc.

Fixes #20227

Change-Id: Iaa784ac5e60141f51c501eb0e3ce0e9c1c2993d0
Reviewed-on: https://go-review.googlesource.com/44590
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

C code expects CR2, CR3, and CR4 to be preserved across function calls.
Preserve the entire CR register across function calls in
_rt0_ppc64le_linux_lib and crosscall2. The standard ppc64le call frame
uses 8(R1) as the place to save CR; emulate that.

It's hard to write a reliable test for this as it requires writing C
code that sets CR2, CR3, or CR4 across a call to a Go function.

Change-Id: If39e771a5b574602b848227312e83598fe74eab7
Reviewed-on: https://go-review.googlesource.com/44733
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>

The MOVFL instruction (which external PPC64 docs call mtcrf) can take
either a CR register or a constant. It doesn't make sense to specify
both, as the CR register implies the constant value. Specifying either
a register or a constant is enforced by the implementation in the
asmout method (case 69).

However, the optab was providing a form that specified both a constant
and a CR register, and was not providing a form that specified only a
constant. This CL fixes the optab table to provide a form that takes
only a constant.

No test because I don't know where to write it. The next CL in this
series will use the new instruction format.

Change-Id: I8bb5d3ed60f483b54c341ce613931e126f7d7be6
Reviewed-on: https://go-review.googlesource.com/44732
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>

Programs built from N libraries required O(N²) time to do the
deduplication checks, even if there were never any duplicates.
In most programs N is small enough not to worry, but this may
affect large programs.

Noticed by inspection, not any specific bug report.

Fixes #20578.

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

Change-Id: I4c579d0d02f6c9cbef1dc2bc2c93cff614538dea
Reviewed-on: https://go-review.googlesource.com/44854
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Otherwise removing a .f file won't trigger a rebuild.
Noticed by inspection while working on the code.
I don't have a good way to write a test for this,
and I expect the code to change significantly in the next
release, but might as well get it right for Go 1.9.

Change-Id: I3f6f9f71b3a7d4f0be49a47419dac59899959e7c
Reviewed-on: https://go-review.googlesource.com/44855
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Close any Rows queried within a Tx when the Tx is closed. This prevents
the Tx from blocking on rollback if a Rows query has not been closed yet.

Fixes #20575

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