Add arm64 assembly implementation of runtime.cmpstring and bytes.Compare.

benchmark                                old ns/op     new ns/op     delta
BenchmarkCompareBytesEqual               98.0          27.5          -71.94%
BenchmarkCompareBytesToNil               9.38          10.0          +6.61%
BenchmarkCompareBytesEmpty               13.3          10.0          -24.81%
BenchmarkCompareBytesIdentical           98.0          27.5          -71.94%
BenchmarkCompareBytesSameLength          43.3          16.3          -62.36%
BenchmarkCompareBytesDifferentLength     43.4          16.3          -62.44%
BenchmarkCompareBytesBigUnaligned        6979680       1360979       -80.50%
BenchmarkCompareBytesBig                 6915995       1381979       -80.02%
BenchmarkCompareBytesBigIdentical        6781440       1327304       -80.43%

benchmark                             old MB/s     new MB/s     speedup
BenchmarkCompareBytesBigUnaligned     150.23       770.46       5.13x
BenchmarkCompareBytesBig              151.62       758.76       5.00x
BenchmarkCompareBytesBigIdentical     154.63       790.01       5.11x

* note, the machine we are benchmarking on has some issues. What is clear is
compared to a few days ago the old MB/s value has increased from ~115 to 150.
I'm less certain about the new MB/s number, which used to be close to 1Gb/s.

Change-Id: I4f31b2c7a06296e13912aacc958525632cb0450d
Reviewed-on: https://go-review.googlesource.com/8541Reviewed-by: Aram Hăvărneanu <aram@mgk.ro>
Reviewed-by: David Crawshaw <crawshaw@golang.org>

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

There was a logical race in Transport.RoundTrip where a roundtrip with
a pending response would race with the channel for the connection
closing. This usually happened for responses with connection: close
and no body.

We handled this race by reading the close channel, setting a timer
for 100ms and if no response was returned before then, we would then
return an error.

This put a lower bound on how fast a connection could fail. We couldn't
fail a request faster than 100ms.

Reordering the channel operations gets rid of the logical race. If
the readLoop causes the connection to be closed, it would have put
its response into the return channel already and we can fetch it with
a non-blocking receive.

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

      The API call will fail when Bitbucket repositories are private. In
that case, probe for the repository using vcsCmd.ping.

      Fixes #5375

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

Fixes #10353

See test/escape2.go:issue10353. Previously new(int) did not escape to heap,
and so heap-allcated closure was referencing a stack var. This breaks
the invariant that heap must not contain pointers to stack.

Look at the following program:

package main

func main() {
	foo(new(int))
	bar(new(int))
}

func foo(x *int) func() {
	return func() {
		println(*x)
	}
}

// Models what foo effectively does.
func bar(x *int) *C {
	return &C{x}
}

type C struct {
	x *int
}

Without this patch escape analysis works as follows:

$ go build -gcflags="-m -m -m -l" esc.go
escflood:1: dst ~r1 scope:foo[0]
escwalk: level:0 depth:0  func literal( l(9) f(1) esc(no) ld(1)) scope:foo[1]
/tmp/live2.go:9: func literal escapes to heap
escwalk: level:0 depth:1 	 x( l(8) class(PPARAM) f(1) esc(no) ld(1)) scope:foo[1]
/tmp/live2.go:8: leaking param: x to result ~r1

escflood:2: dst ~r1 scope:bar[0]
escwalk: level:0 depth:0  &C literal( l(15) esc(no) ld(1)) scope:bar[1]
/tmp/live2.go:15: &C literal escapes to heap
escwalk: level:-1 depth:1 	 &C literal( l(15)) scope:bar[0]
escwalk: level:-1 depth:2 		 x( l(14) class(PPARAM) f(1) esc(no) ld(1)) scope:bar[1]
/tmp/live2.go:14: leaking param: x

/tmp/live2.go:5: new(int) escapes to heap
/tmp/live2.go:4: main new(int) does not escape

new(int) does not escape while being captured by the closure.
With this patch escape analysis of foo and bar works similarly:

$ go build -gcflags="-m -m -m -l" esc.go
escflood:1: dst ~r1 scope:foo[0]
escwalk: level:0 depth:0  &(func literal)( l(9)) scope:foo[0]
escwalk: level:-1 depth:1 	 func literal( l(9) f(1) esc(no) ld(1)) scope:foo[1]
/tmp/live2.go:9: func literal escapes to heap
escwalk: level:-1 depth:2 		 x( l(8) class(PPARAM) f(1) esc(no) ld(1)) scope:foo[1]
/tmp/live2.go:8: leaking param: x

escflood:2: dst ~r1 scope:bar[0]
escwalk: level:0 depth:0  &C literal( l(15) esc(no) ld(1)) scope:bar[1]
/tmp/live2.go:15: &C literal escapes to heap
escwalk: level:-1 depth:1 	 &C literal( l(15)) scope:bar[0]
escwalk: level:-1 depth:2 		 x( l(14) class(PPARAM) f(1) esc(no) ld(1)) scope:bar[1]
/tmp/live2.go:14: leaking param: x

/tmp/live2.go:4: new(int) escapes to heap
/tmp/live2.go:5: new(int) escapes to heap

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

Mainly it is simple copy. But I had to change amd64
lastcontinuehandler return value from uint32 to int32.
I don't remember how it happened to be uint32, but new
int32 is matching better with Windows documentation (LONG).
I don't think it matters one way or the others.

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

This update makes maxBacktrackLen return 0 if
len(prog.Inst) > maxBacktrackProg. This prevents an attempt to
backtrack against a nil bitstate.

Fixes #10319

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

When making a request to an IPv6 address with a zone identifier, for
exmaple [fe80::1%en0], RFC 6874 says HTTP clients must remove the zone
identifier "%en0" before writing the request for security reason.

This change removes any IPv6 zone identifer attached to URI in the Host
header field in requests.

Fixes #9544.

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

Rename now uses MoveFileEx which was previously not available to
use because it is not supported on Windows 2000.

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

Add support for arm64 four operand conditional instructions.

Superceedes CL 8405.

Change-Id: I12da8f4822938feec400bbcc426eeaf884536135
Reviewed-on: https://go-review.googlesource.com/8638Reviewed-by: Aram Hăvărneanu <aram@mgk.ro>

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

Fixes #10389

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

In cl/8652 I broke darwin/arm and darwin/386 because I removed the *g
parameter, which they both expect and use. This CL adjusts both ports
to look for g0 in m, just as darwin/amd64 does.

Tested on darwin{386,arm,amd64}.

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

Also move dumpregs into defs_windows_*.go.

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

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

Found with https://github.com/opennota/check.

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

Change-Id: I6c3a62403941d357ffd9d0025289c2180139b0bd
Reviewed-on: https://go-review.googlesource.com/8664Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>

This is a practice run for darwin/arm.

Similar to the linux/amd64 shared library entry point. With several
pending linker changes I am successfully using this to implement
-buildmode=c-archive on darwin/amd64 with external linking.

The same entry point can be reused to implement -buildmode=c-shared
on darwin/amd64, however that will require further ld changes to
remove all text relocations.

One extra runtime change will follow this. According to the Go
execution modes document, -buildmode=c-archive should ignore the Go
main function. Right now it is being executed (and the process exits
if it doesn't block). I'm still searching for the right way to do
this.

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

The linker currently (on some platforms) takes a -shared flag, which means
approximately what -buildmode=c-shared means in the in the proposed "Go
Execution Modes" document. As part of implementing other modes, the term
"shared" becomes horribly overloaded, so this replaces -shared with a
-buildmode argument instead (which currently only handles -buildmode=c-shared
and the default -buildmode=exe -- no new behaviour here).

As the linker support for -shared was in 1.4 this retains it as an alias.

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

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

When decoding an invalid typeId the associated *decEngine was not
removed from decoderMap. If the decoder was run again on the same input
a nil *decEngine was found in the map and assumed to be initialized,
resulting in a panic.

Fixes #9649

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

There was no way to get to the error message before.

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

Fixes #10379.

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

Just an oversight. Plus the code had an unnecessary call to os.Exit
that now has a purpose.

Fixes #10372.

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

Change-Id: Ied1582d8aabee2eb346e1c23bfd7781e4a091264
Reviewed-on: https://go-review.googlesource.com/8621Reviewed-by: Robert Griesemer <gri@golang.org>

Disable importer-dependent tests on platforms for which the
respective builders don't have access to importable packages.

Fixes #10368.

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

Change-Id: Iaf2dba7d699a8d52f91ce10222ab0d1a0f1f21fc
Reviewed-on: https://go-review.googlesource.com/8625Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Minux Ma <minux@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

This CL is quite conservative in some ways.  It continues to define
symbols that have no real purpose (e.g. epclntab).  These could be
deleted if there is no concern that external tools might look for them.

It would also now be possible to make some changes to the pcln data but
I get the impression that would definitely require some thought and
discussion.

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

Previously if the connection pool was larger than maxBadConnRetries
and there were a lot of bad connections in the pool (for example if
the database server was restarted), a query might have failed with an
ErrBadConn unnecessarily.  Instead of trying to guess how many times
to retry, try maxBadConnRetries times and then force a fresh
connection to be used for the last attempt.  At the same time, lower
maxBadConnRetries to a smaller value now that it's not that important
to retry so many times from the free connection list.

Fixes #8834

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

Change function appendUint to appendInt with variable-width 0-padding.

This allows the decimal for the year to be generated without extra code
to handle the wider padding and directly handles negative numbers.

Removes the special casing for numbers with one and two digits.
The special case for 0 was unreachable.

The new version is slightly slower.

benchmark              old ns/op     new ns/op     delta
BenchmarkFormat        444           454           +2.25%
BenchmarkFormatNow     398           415           +4.27%

Change-Id: I4ddef96bf07ad35dca76053321d510441ec6d4f5
Reviewed-on: https://go-review.googlesource.com/2751Reviewed-by: Robert Griesemer <gri@golang.org>

Update #10203

When the portable componentgen was introduced in b9602632 it
produced broken code on arm64 and was deactivated. In the month since
it looks like the underlying issues have been fixed so componentgen
produces working binaries that are slightly smaller, ~3kb reduction in
size for godoc binary.

Benchmarks are underwhelming, but where visible, trending towards
an improvement (this is with Minux's peep optimiser CL).

benchmark                          old ns/op       new ns/op       delta
BenchmarkBinaryTree17              15336842000     15002766000     -2.18%
BenchmarkFannkuch11                10848984000     10896931000     +0.44%
BenchmarkFmtFprintfEmpty           203             188             -7.39%
BenchmarkFmtFprintfString          753             720             -4.38%
BenchmarkFmtFprintfInt             667             670             +0.45%
BenchmarkFmtFprintfIntInt          1103            1102            -0.09%
BenchmarkFmtFprintfPrefixedInt     981             969             -1.22%
BenchmarkFmtFprintfFloat           1396            1348            -3.44%
BenchmarkFmtManyArgs               4151            4102            -1.18%
BenchmarkGobDecode                 34202360        32933020        -3.71%
BenchmarkGobEncode                 27579180        27438820        -0.51%
BenchmarkGzip                      1296119000      1285096000      -0.85%
BenchmarkGunzip                    291099800       289727200       -0.47%
BenchmarkHTTPClientServer          169476          169803          +0.19%
BenchmarkJSONEncode                70313600        69973400        -0.48%
BenchmarkJSONDecode                227811800       232875200       +2.22%
BenchmarkMandelbrot200             12985600        12996430        +0.08%
BenchmarkGoParse                   14708930        14507320        -1.37%
BenchmarkRegexpMatchEasy0_32       464             460             -0.86%
BenchmarkRegexpMatchEasy0_1K       4516            4517            +0.02%
BenchmarkRegexpMatchEasy1_32       452             454             +0.44%
BenchmarkRegexpMatchEasy1_1K       4664            4669            +0.11%
BenchmarkRegexpMatchMedium_32      602             602             +0.00%
BenchmarkRegexpMatchMedium_1K      172939          172494          -0.26%
BenchmarkRegexpMatchHard_32        9733            9577            -1.60%
BenchmarkRegexpMatchHard_1K        301356          298143          -1.07%
BenchmarkRevcomp                   2754334000      2753874000      -0.02%
BenchmarkTemplate                  315664000       311810800       -1.22%
BenchmarkTimeParse                 1034            989             -4.35%
BenchmarkTimeFormat                1118            1137            +1.70%

benchmark                         old MB/s     new MB/s     speedup
BenchmarkGobDecode                22.44        23.31        1.04x
BenchmarkGobEncode                27.83        27.97        1.01x
BenchmarkGzip                     14.97        15.10        1.01x
BenchmarkGunzip                   66.66        66.98        1.00x
BenchmarkJSONEncode               27.60        27.73        1.00x
BenchmarkJSONDecode               8.52         8.33         0.98x
BenchmarkGoParse                  3.94         3.99         1.01x
BenchmarkRegexpMatchEasy0_32      68.92        69.47        1.01x
BenchmarkRegexpMatchEasy0_1K      226.71       226.65       1.00x
BenchmarkRegexpMatchEasy1_32      70.75        70.42        1.00x
BenchmarkRegexpMatchEasy1_1K      219.55       219.28       1.00x
BenchmarkRegexpMatchMedium_32     1.66         1.66         1.00x
BenchmarkRegexpMatchMedium_1K     5.92         5.94         1.00x
BenchmarkRegexpMatchHard_32       3.29         3.34         1.02x
BenchmarkRegexpMatchHard_1K       3.40         3.43         1.01x
BenchmarkRevcomp                  92.28        92.29        1.00x
BenchmarkTemplate                 6.15         6.22         1.01x

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

Add end to end tests for arm64 to support CL 8405.

There are several instruction forms commented out at the moment
they will be addressed in CL 8405 or later followups.

Change-Id: I6eeeb810c1e03cd49bb3c881bc46a29cdb817822
Reviewed-on: https://go-review.googlesource.com/8631Reviewed-by: Aram Hăvărneanu <aram@mgk.ro>
Reviewed-by: Rob Pike <r@golang.org>

The tests for go/types depend on reading gc export data from the
$GOROOT/pkg directory. This is the first use of these files as
testdata, so previously they were not copied to the android device.
Now they are used, copy them.

Fixes android/arm build.

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

The return type for bsdthread_register is int32. See
runtime/os_darwin.go.

This change also rewrites declaration comments for go functions to
use go syntax and fixes vet errors in sys_darwin_amd64.s.

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

"returns ... the first error" was misleading or at least confusing:
in case a Read results in an error with non-zero bytes read, and the
subsequent Write also results in an error, the error from Write is
returned, which is the second one (in the temporal dimension).

Fixes #9744

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

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

Fixes #10107.

Change-Id: I309e3df7608b9eef9339196fdc50dedf5f9439f6
Reviewed-on: https://go-review.googlesource.com/8453Reviewed-by: Aram Hăvărneanu <aram@mgk.ro>

Update #10373.

Change-Id: I309e3df7608b9eef9339196fdc50dedf5f9439f5
Reviewed-on: https://go-review.googlesource.com/8452Reviewed-by: Aram Hăvărneanu <aram@mgk.ro>
Reviewed-by: David Crawshaw <crawshaw@golang.org>

Change-Id: I309e3df7608b9eef9339196fdc50dedf5f9439f4
Reviewed-on: https://go-review.googlesource.com/8451Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Aram Hăvărneanu <aram@mgk.ro>

Change-Id: I309e3df7608b9eef9339196fdc50dedf5f9439f3
Reviewed-on: https://go-review.googlesource.com/8450Reviewed-by: Aram Hăvărneanu <aram@mgk.ro>