Fixes #11960.

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

The percolation of errors upward in the load process could
drop errors, meaning that a build tree could, depending on the
processing order, import the same directory as both "p/vendor/x"
and as "x". That's not supposed to be allowed. But then, worse,
the build would generate two jobs for building that directory,
which would use the same work space and overwrite each other's files,
leading to very strange failures.

Two fixes:

1. Fix the propagation of errors upward (prefer errors over success).
2. Check explicitly for duplicated packages before starting a build.

New test for #1.
Since #2 can't happen, tested #2 by hand after reverting fix for #1.

Fixes #11913.

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

On most systems, a pointer is the worst case alignment, so adding
a pointer field at the end of a struct guarantees there will be no
padding added after that field (to satisfy overall struct alignment
due to some more-aligned field also present).

In the runtime, the map implementation needs a quick way to
get to the overflow pointer, which is last in the bucket struct,
so it uses size - sizeof(pointer) as the offset.

NaCl/amd64p32 is the exception, as always.
The worst case alignment is 64 bits but pointers are 32 bits.
There's a long history that is not worth going into, but when
we moved the overflow pointer to the end of the struct,
we didn't get the padding computation right.
The compiler computed the regular struct size and then
on amd64p32 added another 32-bit field.
And the runtime assumed it could step back two 32-bit fields
(one 64-bit register size) to get to the overflow pointer.
But in fact if the struct needed 64-bit alignment, the computation
of the regular struct size would have added a 32-bit pad already,
and then the code unconditionally added a second 32-bit pad.
This placed the overflow pointer three words from the end, not two.
The last two were padding, and since the runtime was consistent
about using the second-to-last word as the overflow pointer,
no harm done in the sense of overwriting useful memory.
But writing the overflow pointer to a non-pointer word of memory
means that the GC can't see the overflow blocks, so it will
collect them prematurely. Then bad things happen.

Correct all this in a few steps:

1. Add an explicit check at the end of the bucket layout in the
compiler that the overflow field is last in the struct, never
followed by padding.

2. When padding is needed on nacl (not always, just when needed),
insert it before the overflow pointer, to preserve the "last in the struct"
property.

3. Let the compiler have the final word on the width of the struct,
by inserting an explicit padding field instead of overwriting the
results of the width computation it does.

4. For the same reason (tell the truth to the compiler), set the type
of the overflow field when we're trying to pretend its not a pointer
(in this case the runtime maintains a list of the overflow blocks
elsewhere).

5. Make the runtime use "last in the struct" as its location algorithm.

This fixes TestTraceStress on nacl/amd64p32.
The 'bad map state' and 'invalid free list' failures no longer occur.

Fixes #11838.

Change-Id: If918887f8f252d988db0a35159944d2b36512f92
Reviewed-on: https://go-review.googlesource.com/12971Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Austin Clements <austin@google.com>

Change-Id: Ic8ff6c28ec899cf5e01553b83110eb6262870995
Reviewed-on: https://go-review.googlesource.com/12918Reviewed-by: Russ Cox <rsc@golang.org>

Fixes some minor issues regarding quoted-string when parsing
the local-part.

Those strings should return an error:
- quoted-string without any content: `""@test.com`
- quoted-string containing tab: "\"\t\"@test.com"

Fixes #11293

Change-Id: Ied93eb6831915c9b1f8e727cea14168af21f8d3b
Reviewed-on: https://go-review.googlesource.com/12905Reviewed-by: Russ Cox <rsc@golang.org>

The code already fixed large non-stack offsets
but explicitly excluded stack references.
Perhaps you could get away with that before,
but current versions of nacl reject such stack
references. Rewrite them the same as the others.

For #11956 but probably not the last problem.

Change-Id: I0db4e3a1ed4f88ccddf0d30228982960091d9fb7
Reviewed-on: https://go-review.googlesource.com/13010Reviewed-by: Dave Cheney <dave@cheney.net>

For #11956.

Change-Id: Ic9b57cafa197953cc7f435941e44d42b60b3ddf0
Reviewed-on: https://go-review.googlesource.com/13011Reviewed-by: Dave Cheney <dave@cheney.net>

Update #11943

Change-Id: I3e6592876bf16d2f9129995b723ecf69c069653d
Reviewed-on: https://go-review.googlesource.com/12913Reviewed-by: Russ Cox <rsc@golang.org>

Dangling pointer error. Unlikely to trigger in practice, but still.
Found by running GODEBUG=efence=1 GOGC=1 trace.test.

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

Etcd and kubernetes have hit this.
See  https://bugzilla.redhat.com/show_bug.cgi?id=1248071

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

In https://golang.org/cl/12080 we forbade installing cross-compiled
binaries into a subdirectory of $GOBIN, in order to fix
https://golang.org/issue/9769.  However, that fix was too aggressive,
in that it also forbade installing into a subdirectory of $GOPATH/bin.

This patch permits installing cross-compiled binaries into a
subdirectory $GOPATH/bin while continuing to forbid installing into a
subdirectory of $GOBIN.

Fixes #11778.

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

Fixes #11952.

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

The spec didn't specify several aspects of expression switches:

- The switch expression is evaluated exactly once.

- Switch expressions evaluating to an untyped value are converted
  to the respective default type before use.

- An (untyped) nil value is not permitted as expression switch
  value. (We could permit it relatively easily, but gc doesn't,
  and disallowing it is in symmetry with the rules for var decls
  without explicit type and untyped initializer expressions.)

- The comparison x == t between each case expression x and
  switch expression value t must be valid.

- (Some) duplicate constant case expressions are not permitted.

This change also clarifies the following issues:

 4524: mult. equal int const switch case values should be illegal
                                         -> spec issue fixed
 6398: switch w/ no value uses bool rather than untyped bool
                                         -> spec issue fixed
11578: allows duplicate switch cases     -> go/types bug
11667: int overflow in switch expression -> go/types bug
11668: use of untyped nil in switch      -> not a gc bug

Fixes #4524.
Fixes #6398.
Fixes #11668.

Change-Id: Iae4ab3e714575a5d11c92c9b8fbf027aa706b370
Reviewed-on: https://go-review.googlesource.com/12711Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

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

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

Fixes #11935

Change-Id: Ife00c246345f7d3f96aa95349a35e76671ca7160
Reviewed-on: https://go-review.googlesource.com/12769Reviewed-by: Dave Cheney <dave@cheney.net>
Reviewed-by: Russ Cox <rsc@golang.org>

This should fix the solaris/amd64 builder.

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

Fixes #11918

Replace calls to lchown(2) with fchownat(2) for linux/arm64 as the former is not suppored.

This change has also landed on the x/sys repo as CL 12837.

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

This documents the change made in https://golang.org/cl/12864 for
https://golang.org/issue/11925.

Update #11925.

Change-Id: Id09f2a489ea947a725ed12c9cf793e5daef07a06
Reviewed-on: https://go-review.googlesource.com/12866Reviewed-by: David Crawshaw <crawshaw@golang.org>

This only triggers on ARMv7+.
If there are important SMP ARMv6 machines we can reconsider.

Makes TestLFStress tests pass and sync/atomic tests not time out
on Apple iPad Mini 3.

Fixes #7977.
Fixes #10189.

Change-Id: Ie424dea3765176a377d39746be9aa8265d11bec4
Reviewed-on: https://go-review.googlesource.com/12950Reviewed-by: David Crawshaw <crawshaw@golang.org>

For #11949.

Change-Id: I4329604a24efc7f40cf5bf52fb3c9e30916b3cc2
Reviewed-on: https://go-review.googlesource.com/12931Reviewed-by: Alan Donovan <adonovan@google.com>

Fixes #11912.
Fixes #11937.

This reverts commit 1a99ba55.

Change-Id: I32b76053fdabc59f28ca5bedf1b15c0baa8afae1
Reviewed-on: https://go-review.googlesource.com/12893Reviewed-by: Didier Spezia <didier.06@gmail.com>
Reviewed-by: David Crawshaw <crawshaw@golang.org>

Was not allocating space for the frame above sigpanic,
nor was it pushing the LR into the right place.
Because traceback past sigpanic only needs the
LR for faulting leaves, this was not noticed too much.
But it did break the sync/atomic nil deref tests.

Change-Id: Icba53fffa193423aab744c37f21ee893ce2ee3ac
Reviewed-on: https://go-review.googlesource.com/12926Reviewed-by: David Crawshaw <crawshaw@golang.org>

ODOTTYPE should be treated a whole lot like ODOT,
but it was missing completely from the switch in
escwalk and thus escape status did not propagate
to fields.

Since interfaces are required to trigger this bug,
the test was added to escape_iface.go.

Fixes #11931.

Change-Id: Id0383981cc4b1a160f6ad447192a112eed084538
Reviewed-on: https://go-review.googlesource.com/12921
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>

There is absolutely no information about how this was failing.
If we reenable the test then at least we can get a build log from
darwin/arm.

There are not even freebsd/arm or netbsd/arm builders,
so not too worried about those. (That is another problem.)

Change-Id: I0e739a4dd2897adbe110aa400d720d8fa02ae65f
Reviewed-on: https://go-review.googlesource.com/12920Reviewed-by: Russ Cox <rsc@golang.org>

Instead of pushing the denominator argument on the stack,
the denominator is now passed in m.

This fixes a variety of bugs related to trying to take stack traces
backwards from the middle of the software div/mod routines.
Some of those bugs have been kludged around in the past,
but others have not. Instead of trying to patch up after breaking
the stack, this CL stops breaking the stack.

This is an update of https://golang.org/cl/19810043,
which was rolled back in https://golang.org/cl/20350043.

The problem in the original CL was that there were divisions
at bad times, when m was not available. These were divisions
by constant denominators, either in C code or in assembly.
The Go compiler knows how to generate division by multiplication
for constant denominators, but the C compiler did not.
There is no longer any C code, so that's taken care of.
There was one problematic DIV in runtime.usleep (assembly)
but https://golang.org/cl/12898 took care of that one.
So now this approach is safe.

Reject DIV/MOD in NOSPLIT functions to keep them from
coming back.

Fixes #6681.
Fixes #6699.
Fixes #10486.

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

In order to fix issue #9401 the compiler was changed to add a padding
byte to any non-empty Go struct that ends in a zero-sized field.  That
causes the Go version of such a C struct to have a different size than
the C struct, which can considerable confusion.  Change cgo so that it
discards any such zero-sized fields, so that the Go and C structs are
the same size.

This is a change from previous releases, in that it used to be
possible to refer to a zero-sized trailing field (by taking its
address), and with this change it no longer is.  That is unfortunate,
but something has to change.  It seems better to visibly break
programs that do this rather than to silently break programs that rely
on the struct sizes being the same.

Update #9401.
Fixes #11925.

Change-Id: I3fba3f02f11265b3c41d68616f79dedb05b81225
Reviewed-on: https://go-review.googlesource.com/12864Reviewed-by: Russ Cox <rsc@golang.org>

We want to adjust the DIV calling convention to use m,
and usleep can be called without an m, so switch to a
multiplication by the reciprocal (and test).

Step toward a fix for #6699 and #10486.

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

If a function is large enough to need to flush the constant pool
mid-function, the line number assignment code was forcing the
line numbers not just for the constant pool but for all the instructions
that follow it. This made the line number information completely
wrong for all but the beginning of large functions on arm.

Same problem in code copied into arm64.

This broke runtime/trace's TestTraceSymbolize.

Fixes arm build.

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

This allows running a cross-compile like
	GOOS=darwin GOARCH=arm go build std
to check that everything builds.

Otherwise there is a redefinition error because both
root_nocgo_darwin.go and root_darwin_armx.go
supply initSystemRoots.

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

The test expects the dial to take 1.0 seconds
on Windows and allows it to go to 1.095 seconds.
That's far too optimistic.
Recent failures are reporting roughly 1.2 seconds.
Let it have 1.5.

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

Urge users of math/rand to consider using crypto/rand when doing
security-sensitive work.

Related to issue #11871. While we haven't reached consensus on how
to make the package inherently safer, everyone agrees that the docs
for math/rand can be improved.

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

For the android/arm builder.

Change-Id: Iad4881689223cd6479870da9541524a8cc458cce
Reviewed-on: https://go-review.googlesource.com/12859Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: David Crawshaw <crawshaw@golang.org>

Fixes arm64 builder crash.

The bug is possible on all architectures; you just have to get lucky
and hit a preemption or a stack growth on entry to assertE2I2.
The test stacks the deck.

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

It says to disable until #7564 is fixed. It was fixed in April 2014.

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

Also make invalidptr control the recently added GC pointer check,
as documented.

Change-Id: Iccfdf49480219d12be8b33b8f03d8312d8ceabed
Reviewed-on: https://go-review.googlesource.com/12857
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

Change-Id: Ie43986d016e5a9fb17ca1393263932bbb56e81ff
Reviewed-on: https://go-review.googlesource.com/12836Reviewed-by: Russ Cox <rsc@golang.org>

The skips added in CL 12579, based on incorrect time stamps,
should be sufficient to identify and exclude all the time-related
flakiness on these systems.

If there is other flakiness, we want to find out.

For #10512.

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

Nearly all the flaky failures we've seen in trace tests have been
due to the use of time stamps to determine relative event ordering.
This is tricky for many reasons, including:
 - different cores might not have exactly synchronized clocks
 - VMs are worse than real hardware
 - non-x86 chips have different timer resolution than x86 chips
 - on fast systems two events can end up with the same time stamp

Stop trying to make time reliable. It's clearly not going to be for Go 1.5.
Instead, record an explicit event sequence number for ordering.
Using our own counter solves all of the above problems.

The trace still contains time stamps, of course. The sequence number
is just used for ordering.

Should alleviate #10554 somewhat. Then tickDiv can be chosen to
be a useful time unit instead of having to be exact for ordering.

Separating ordering and time stamps lets the trace parser diagnose
systems where the time stamp order and actual order do not match
for one reason or another. This CL adds that check to the end of
trace.Parse, after all other sequence order-based checking.
If that error is found, we skip the test instead of failing it.
Putting the check in trace.Parse means that cmd/trace will pick
up the same check, refusing to display a trace where the time stamps
do not match actual ordering.

Using net/http's BenchmarkClientServerParallel4 on various CPU counts,
not tracing vs tracing:

name                      old time/op    new time/op    delta
ClientServerParallel4       50.4µs ± 4%    80.2µs ± 4%  +59.06%        (p=0.000 n=10+10)
ClientServerParallel4-2     33.1µs ± 7%    57.8µs ± 5%  +74.53%        (p=0.000 n=10+10)
ClientServerParallel4-4     18.5µs ± 4%    32.6µs ± 3%  +75.77%        (p=0.000 n=10+10)
ClientServerParallel4-6     12.9µs ± 5%    24.4µs ± 2%  +89.33%        (p=0.000 n=10+10)
ClientServerParallel4-8     11.4µs ± 6%    21.0µs ± 3%  +83.40%        (p=0.000 n=10+10)
ClientServerParallel4-12    14.4µs ± 4%    23.8µs ± 4%  +65.67%        (p=0.000 n=10+10)

Fixes #10512.

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

Otherwise the GC may see uninitialized memory there,
which might be old pointers that are retained, or it might
trigger the invalid pointer check.

Fixes #11907.

Change-Id: I67e306384a68468eef45da1a8eb5c9df216a77c0
Reviewed-on: https://go-review.googlesource.com/12852Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Austin Clements <austin@google.com>