Also document the special behavior of Alignof(s.f), and mention the
correspondence between Alignof and reflect.Type.{Align,FieldAlign}.

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

Fixes #9157

Change-Id: Iadf305a172a0ec53ae91e1b2db3f3351691a48ff
Reviewed-on: https://go-review.googlesource.com/18935Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>

It's possible for arena_start+MaxArena32 to wrap.
We do the right thing in the bounds check but not in the print.

For #13992 (to fix the print there, not the bug).

Change-Id: I4df845d0c03f0f35461b128e4f6765d3ccb71c6d
Reviewed-on: https://go-review.googlesource.com/18975
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Austin Clements <austin@google.com>

The previous CL is the real fix. This one is just insurance.

Fixes #14046 again.

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

It was just completely broken if you gave it the number
of records it asked for. Make it impossible for that particular
inconsistency to happen again.

Also make it exclude system goroutines, to match both
NumGoroutine and Stack.

Fixes #14046.

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

For Go 1.7 we can remove all the code.google.com code
(except maybe the shutdown warning).

See #10193.

Change-Id: I4b8182eb66494f0bf373b40ca5da6ae4738342be
Reviewed-on: https://go-review.googlesource.com/18974Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

This has been flaking on the new OpenBSD 5.8 builders lately:
https://storage.googleapis.com/go-build-log/808270e7/openbsd-amd64-gce58_61ce2663.log
(as one example)

Add more debug info when it fails.

Updates #14107

Change-Id: Ie30bc0c703d2e9ee993d1e232ffc5f2d17e65c97
Reviewed-on: https://go-review.googlesource.com/18938
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

Currently p.gcBgMarkWorker is a *g. Change it to a guintptr. This
eliminates a write barrier during the subtle mark worker parking dance
(which isn't known to be causing problems, but may).

Change-Id: Ibf12c05ac910820448059e69a68e5b882c993ed8
Reviewed-on: https://go-review.googlesource.com/18970
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

traceEvent records system call events after a G has already entered
_Gsyscall, which means the garbage collector could be installing stack
barriers in the G's stack during the traceEvent. If traceEvent
attempts to capture the user stack during this, it may observe a
inconsistent stack barriers and panic. Fix this by acquiring the stack
lock around the stack walk in traceEvent.

Fixes #14101.

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

Currently mark workers attach to their designated Ps before parking,
either during initialization or after performing a phase transition.
However, in both of these cases, it's possible that the mark worker is
running on a different P than the one it attaches to. This is a
problem, because as soon as the worker attaches to a P, that P's
scheduler can execute the worker. If the worker hasn't yet parked on
the P it's actually running on, this means the worker G will be
running in two places at once. The most visible consequence of this is
that once the first instance of the worker does park, it will clear
g.m and the second instance will crash shortly when it tries to use
g.m.

Fix this by moving the attach to the gopark callback. At this point,
the G is genuinely stopped and the callback is running on the system
stack, so it's safe for another P's scheduler to pick up the worker G.

Fixes #13363. Fixes #13978.

Change-Id: If2f7c4a4174f9511f6227e14a27c56fb842d1cc8
Reviewed-on: https://go-review.googlesource.com/18761Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Austin Clements <austin@google.com>

The current code delays the literal pool until the very last moment,
but based on the assumption that span-dependent jumps are as
short as possible. If they need to be enlarged in a later round, that
very last moment may be too late. Flush a little early to prevent that.

Fixes #13579.

Change-Id: I759b5db5c43a977bf2b940872870cbbc436ad141
Reviewed-on: https://go-review.googlesource.com/18972Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dave Cheney <dave@cheney.net>
Run-TryBot: Russ Cox <rsc@golang.org>

Clarify that Compressor and Decompressor callbacks must support being invoked
concurrently, but that the writer or reader returned need not be.

Updates #8359

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

This debugging print crept into an earlier CL of mine.

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

In some cases the documentation for functions in this package was
lacking from the beginning and, in order cases, the documentation didn't
keep pace as the package grew.

This change somewhat addresses that.

Updates #13711.

Change-Id: I25b2bb1fcd4658c5417671e23cf8e644d08cb9ab
Reviewed-on: https://go-review.googlesource.com/18486Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>

Fixes #13954

Change-Id: I4c01e9bb3fb08e8b9fa14d4c59b7ea824ba3f0c9
Reviewed-on: https://go-review.googlesource.com/18937Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

Currently we run profiling tests for around 200ms in short mode.
However, even on platforms with good profiling, these tests are
inherently flaky, especially on loaded systems like the builders.

To mitigate this, modify the profiling test harness so that if a test
fails in a way that could indicate there just weren't enough samples,
it retries with a longer duration.

This requires some adjustment to the profile checker to distinguish
"fatal" and "retryable" errors. In particular, we no longer consider
it a fatal error to get a profile with zero samples (which we
previously treated as a parse error). We replace this with a retryable
check that the total number of samples is reasonable.

Fixes #13943. Fixes #13871. Fixes #13223.

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

Updates x/net/http2 to git rev eb066e3 for https://golang.org/cl/18932

Fixes #13925
Fixes #14061

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

Fixes #14103

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

Fixes #14020

Change-Id: I454c2613912a7efcb464c6e6f3ac2e0ec89fb719
Reviewed-on: https://go-review.googlesource.com/18750Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Chris Broadfoot <cbro@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

People who want to use -buildmode=c-archive in unusual cross-compilation
setups will need something like this.  It could also be done via (yet
another) environment variable but I use -extar by analogy with the
existing -extld.

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

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

Fixes #13938.

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

Windows: putting spaces where they don't belong since Windows NT 3.1.

Fixes #14002.

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

Add example of how to use the aes package to
implement AES encryption and decryption
within an application.

Per feedback, use more secure AES-GCM implementation as an
example in crypto/cipher instead of AES directly.

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

Fixes #14099.

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

Was part of #13822 but not in the first message, so I missed it.

Fixes #13822 again.

Change-Id: I775004fa8d47b6af293124605521ec396573e267
Reviewed-on: https://go-review.googlesource.com/18900
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

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

Use of the alternate signal stack on darwin/{arm,arm64} is reportedly
buggy, and the runtime function sigaltstack does nothing.  So don't
check the sigaltstack result to decide how to handle the signal stack.

Fixes #14070.

Change-Id: Ie97ede8895fad721e3acc79225f2cafcbe1f3a81
Reviewed-on: https://go-review.googlesource.com/18940
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>

Fixes #14084

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

Also don't nil out the Request or Response Body on error. Just leave
it in its previous broken state. The docs now say it's undefined, but
it always was.

Fixes #14036

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

Updates x/net/http2 to git rev 2e9cee70 for https://golang.org/cl/18801

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

When using c-archive/c-shared, the signal handler for SIGPROF will not
be installed, which means that runtime/pprof.StartCPUProfile won't work.
There is no really good solution here, as the main program may want to
do its own profiling.  For now, just document that runtime/pprof doesn't
work as expected, but that it will work if you use Notify to install the
Go signal handler.

Fixes #14043.

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

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

Thanks to Régis Leroy for noticing.

Change-Id: I5ca2402efddab4e63d884a9d315fc1394e514cb7
Reviewed-on: https://go-review.googlesource.com/18871Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

On NetBSD and DragonFly a newly created thread inherits the signal stack
of the creating thread.  That means that in a cgo program a C thread
created using pthread_create will get the signal stack of the creating
thread, most likely a Go thread.  This will then lead to chaos if two
signals occur simultaneously.

We can't fix the general case.  But we can fix the case of a C thread
that calls a Go function, by installing a new signal stack and then
dropping it when we return to C.  That will break the case of a C thread
that calls sigaltstack and then calls Go, because we will drop the C
thread's alternate signal stack as we return from Go.  Still, this is
the 1.5 behavior.  And what else can we do?

Fixes #14051.
Fixes #14052.
Fixes #14067.

Change-Id: Iee286ca50b50ec712a4d929c7121c35e2383a7b9
Reviewed-on: https://go-review.googlesource.com/18835Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
Reviewed-by: Russ Cox <rsc@golang.org>

Pass -c to generate an object.  Pass GOPKGPATH as a symbol, not a
string.  Pass -xassembler-with-cpp so that the preprocessor is run.

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

Add test for assembly errors, to verify fix.
Make sure invalid instruction errors are printed just once
(was printing them once per span iteration, so typically twice).

Fixes #13282.

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

Apparently the darwin/386 builder does not enable cgo.
This failure turned up running

	GOARCH=386 GOHOSTARCH=386 ./all.bash

on my Mac.

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

Fixes #13757.

Change-Id: I1b52593df8df0e98ce7342767eb34eccecc11761
Reviewed-on: https://go-review.googlesource.com/18854
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Requested off-list.
Trivial to add and more importantly trivial to test.

ANDNL
ANDNQ
BEXTRL
BEXTRQ
BZHIL
BZHIQ
MULXL
MULXQ
PDEPL
PDEPQ
PEXTL
PEXTQ
SARXL
SARXQ
SHRXL
SHRXQ

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