Commit d7e0ad4b removed the next_gc manipulation from mSpan_Sweep, but
left in the traceNextGC() for recording the updated next_gc
value. Remove this now unnecessary call.

Change-Id: I28e0de071661199be9810d7bdcc81ce50b5a58ae
Reviewed-on: https://go-review.googlesource.com/8894Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Rick Hudson <rlh@golang.org>

Fixes #10451

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

See also golang-dev discussion:
https://groups.google.com/d/msg/golang-dev/Nk9gnTINlTg/SV8rBt-2__kJ

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

Even if requested, there is no .go file for unsafe - it comes from the
compiler - so referencing its cover variables will break the compilation
in a command like
	go test -coverpkg=all fmt

Fixes #10408.

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

Fixes #10441

Compiler crashed as:

panic: runtime error: invalid memory address or nil pointer dereference
goroutine 1 [running]:
cmd/internal/gc.haspointers(0x0, 0xffffffffffffffff)
    src/cmd/internal/gc/reflect.go:623 +0x1f
cmd/internal/gc.escwalk(0x20c82dc00, 0xffffffffffffffff, 0x20c82dda0, 0x20c835520)
    src/cmd/internal/gc/esc.go:1291 +0x14aa
cmd/internal/gc.escwalk(0x20c82dc00, 0xffffffffffffffff, 0x20c82dda0, 0x20beac340)
    src/cmd/internal/gc/esc.go:1386 +0x836

while evaluating haspointers of the fake OADDR node here:

	leaks = level <= 0 && dst.Escloopdepth < src.Escloopdepth || level < 0 && dst == &e.funcParam && haspointers(src.Type)

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

With the new buildmodes c-archive and c-shared, it is possible for a
cgo call to come in early in the lifecycle of a Go program. Calls
before the runtime has been initialized are caught by
_cgo_wait_runtime_init_done. However a call can come in after the
runtime has initialized, but before the program's package init
functions have finished running.

To avoid this cgocallback checks m.ncgo to see if we are on a thread
running Go. If not, we may be a foreign thread and it blocks until
main_init is complete.

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

Avoids shadowing the builtin channel close function.

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

call unreadByteStuffedByte.

If ensureNBits was due to an io.EOF that was translated to
jpeg.errShortHuffmanData, then we may have read no bytes, so there is no
byte-stuffed-byte to unread.

Fixes #10387

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

Change-Id: Ie5fe5cf3e2926ba4f91271bd47f3f998c26e003e
Reviewed-on: https://go-review.googlesource.com/8914Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

The memory model has been clarified since. This is legal and doesn't
need justification.

Change-Id: I60f9938503f86f52bb568ca1a99ac721ee72cee5
Reviewed-on: https://go-review.googlesource.com/8913Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>

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

Already supported platforms are linux/amd64 and android/arm.

Running -buildmode=c-shared on linux/arm is equivalent to:
  -ldflags "-shared" -asmflags "-shared"

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

Change-Id: Ic35dff4c9a7fc6716ef9d5553a7b1769bed9be01
Reviewed-on: https://go-review.googlesource.com/8892Reviewed-by: Minux Ma <minux@golang.org>

On darwin, /tmp and /var directories are usually linked to /private.

% cd $TMPDIR; pwd -L
/var/.../T
% pwd -P
/private/var/.../T

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

Follows http://golang.org/cl/8454, a similar CL for arm architectures.
This CL involves android-specific changes, namely, synthesizing
argv/auxv, as android doesn't provide those to the init functions.

This code is based on crawshaw@ android code in golang.org/x/mobile.

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

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

The documentation is clear that formats like %02x applied to a
byte slice are per-element, so the result should be nothing if the
slice is empty. It's not, because the top-level padding routine is called.
It shouldn't be: the loop does the padding for us.

Fixes #10430.

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

Update #10417.

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

Fixes #10092

This change makes it possible to use gccgo 5 as the GOROOT_BOOTSTRAP
compiler.

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

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

The -lldb flag makes it easy to use go run and end up in a debugging
session on darwin/arm.

Change-Id: I556f93e950086a7dff4839f301b9c55f7579f87b
Reviewed-on: https://go-review.googlesource.com/8024Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>

Adds the runtime initialization flow for arm akin to amd64.
In particular,we use the library initialization entry point to:
    - create a new OS thread and run the "regular" runtime init stack on
      that thread
    - return immediately from the main (i.e., loader) thread
    - at the first CGO invocation, we wait for the runtime initialization
      to complete.

Verified to work on a Raspberry Pi and an Android phone.

Change-Id: I32f39228ae30a03ce9569287f234b305790fecf6
Reviewed-on: https://go-review.googlesource.com/8455Reviewed-by: David Crawshaw <crawshaw@golang.org>
Run-TryBot: Srdjan Petrovic <spetrovic@google.com>

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

Related to issue #10410

For some reason, any non-trivial code in _cgo_wait_runtime_init_done
(even fprintf()) will crash that call.

If anybody has any guess why this is happening, please let me know!

For now, I'm clearing the functions for ppc64, as it's currently not used.

Change-Id: I1b11383aaf4f9f9a16f1fd6606842cfeedc9f0b3
Reviewed-on: https://go-review.googlesource.com/8766Reviewed-by: David Crawshaw <crawshaw@golang.org>
Run-TryBot: Srdjan Petrovic <spetrovic@google.com>

This is friendlier for manual runs and personal devices.
Builders will pass -restart.

Fixes #10333.

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

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

Change-Id: Ia9ff9c0d381fad43fc5d3e5972dd6e66503733a5
Reviewed-on: https://go-review.googlesource.com/8815Reviewed-by: Minux Ma <minux@golang.org>

Just like darwin/arm.

Change-Id: Ibaba67980db6e05aa71568199b2dac2fcaa86fd6
Reviewed-on: https://go-review.googlesource.com/8824Reviewed-by: Minux Ma <minux@golang.org>

Just like darwin/arm.

Change-Id: I5ed26975670d4189a46b585a56c66c199905d168
Reviewed-on: https://go-review.googlesource.com/8823Reviewed-by: Minux Ma <minux@golang.org>

Just like darwin/arm.

Change-Id: Ic75927bd6457d37cda7dd8279fd9b4cd52edc1d1
Reviewed-on: https://go-review.googlesource.com/8813Reviewed-by: Minux Ma <minux@golang.org>

Just like darwin/arm, the test devices can only install and execute
a single app at a time.

Change-Id: I74e6130ef83537c465b4585a366d02953fd907bf
Reviewed-on: https://go-review.googlesource.com/8827Reviewed-by: Minux Ma <minux@golang.org>

Like other arm64 platforms, darwin/arm64 has a different physical
page size to logical page size so it is running into issue 9993. I
hope it can be fixed for Go 1.5, but for now it is demonstrating the
same bug as the other skipped os+arch combinations.

Change-Id: Iedaf9afe56d6954bb4391b6e843d81742a75a00c
Reviewed-on: https://go-review.googlesource.com/8814Reviewed-by: Minux Ma <minux@golang.org>

Just like darwin/arm.

Change-Id: Ib0438021bfe9eb105222b93e5bb375c282cc7b8c
Reviewed-on: https://go-review.googlesource.com/8822Reviewed-by: Minux Ma <minux@golang.org>

Just like darwin/arm.

Change-Id: Ic5c6c0b2fdbb89f4579677e120a8f2dbf300e5b9
Reviewed-on: https://go-review.googlesource.com/8820Reviewed-by: Minux Ma <minux@golang.org>

Just like darwin/arm.

Change-Id: I1a9f51c572c14b78d35ea62f52927f2bdc46e4c0
Reviewed-on: https://go-review.googlesource.com/8821Reviewed-by: Minux Ma <minux@golang.org>

Just like darwin/arm.

Change-Id: Ia8c912e91259a5073aa3ab2b6509a18aa9a1fce7
Reviewed-on: https://go-review.googlesource.com/8818Reviewed-by: Minux Ma <minux@golang.org>

Just like darwin/arm.

Change-Id: I4b0ab4a104f2c8a821ca8b5fa8d266e51883709f
Reviewed-on: https://go-review.googlesource.com/8816Reviewed-by: Minux Ma <minux@golang.org>

Just like darwin/arm.

Change-Id: Ie4998d24b2d891a9f6c8047ec40cd3fdf80622cd
Reviewed-on: https://go-review.googlesource.com/8812Reviewed-by: Minux Ma <minux@golang.org>

Just like darwin/arm.

Change-Id: Ib9a32bb0aed5f08b27de11a93aaf273cacdf5779
Reviewed-on: https://go-review.googlesource.com/8819Reviewed-by: Minux Ma <minux@golang.org>

Previously, running

  $ go get -u -v golang.org/x/tools/cmd/godoc

would results in dozens of HTTP requests for

  https://golang.org/x/tools?go-get=1

once per package under x/tools.

Now it caches the results. We still end up doing one HTTP request for
all the packages under x/tools, but this reduces the total number of
HTTP requests in ~half.

This also moves the singleflight package back into an internal
package. singleflight was originally elsewhere as a package, then got
copied into "net" (without its tests). But now that we have internal,
put it in its own package, and restore its test.

Fixes #9249

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