Now that getg is an intrinsic, more runtime functions
gets inlined (in particular, LockOSThread).
Runtime code gets race instrumented after inlining into
other packages. This can lead to false positives,
as race detector ignores all internal synchronization in runtime.
Inling of LockOSThread lead to false race reports on m contents.
See the issue for an example.

Fixes #10380

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

Currently, when allocation reaches the concurrent GC trigger size, we
start the concurrent collector by ready'ing its G. This simply puts it
on the end of the P's run queue, which means we may not actually start
GC for some time as the current G continues to run and then the P
drains other Gs already on its run queue. Since the mutator can
continue to allocate, the heap can potentially be much larger than we
intended by the time GC actually starts. Furthermore, how much larger
is difficult to predict since it depends on the scheduler.

Fix this by preempting the current G and switching directly to the
concurrent GC G as soon as we reach the trigger heap size.

On the garbage benchmark from the benchmarks subrepo with
GOMAXPROCS=4, this reduces the time from triggering the GC to the
beginning of sweep termination by 10 to 30 milliseconds, which reduces
allocation after the trigger by up to 10MB (a large fraction of the
64MB live heap the benchmark tries to maintain).

One other known source of delay before we "really" start GC is the
sweep finalization performed before sweep termination. This has
similar negative effects on heap size and predictability, but is an
orthogonal problem. This change adds a TODO for this.

Change-Id: I8bae98cb43685c1bf353ff55868e4647e3743c47
Reviewed-on: https://go-review.googlesource.com/8513Reviewed-by: Rick Hudson <rlh@golang.org>

These were appropriate for STW GC, since it interrupted the allocating
Goroutine, but don't apply to concurrent GC, which runs on its own
Goroutine. Forced GC is still STW, but it makes sense to attribute the
GC to the goroutine that called runtime.GC().

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

Currently, GC disables preemption between the traceGCStart and
traceGCDone, so it never moves Ps. Consequently, the trace verifier
attaches information about GC to its per-P state and will fail if GC
starts on one P and ends on another.

GC will soon be preemptible and may end on a different P than it
began. Hence, this change lifts this per-P verifier state to global
state.

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

exitsyscallfast checks for freezetheworld, but does so only by
checking if stopwait is positive. This can also happen during
stoptheworld, which is harmless, but confusing. Shortly, it will be
important that we get to the p.status cas even if stopwait is set.

Hence, make this test more specific so it only triggers with
freezetheworld and not other uses of stopwait.

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

Currently, the only way to know the Go type of an attribute of some
DWARF attribute class was to read the dwarf package code (or
experiment).  This makes it hard to go from the DWARF specification to
writing code that uses the dwarf package.

Fix this by adding a table to the documentation comment of the Field
type that gives the correspondence between DWARF attribute classes and
Go types.

Change-Id: I57c678a551fa1eb46f8207085d5a53d44985e3e7
Reviewed-on: https://go-review.googlesource.com/7280Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Nigel Tao <nigeltao@golang.org>

The existing code used ints for the (slow) decimal conversion and
assumed that they were 32bit wide.

This change uses uints and the appropriate width (32 or 64bit)
depending on platform.

The performance difference is in the noise for the usual (optimized)
case which does not use the slow path conversion:

benchmark                               old ns/op     new ns/op     delta
BenchmarkFormatFloatDecimal             298           299           +0.34%
BenchmarkFormatFloat                    388           392           +1.03%
BenchmarkFormatFloatExp                 365           364           -0.27%
BenchmarkFormatFloatNegExp              364           362           -0.55%
BenchmarkFormatFloatBig                 482           476           -1.24%
BenchmarkAppendFloatDecimal             100           102           +2.00%
BenchmarkAppendFloat                    199           201           +1.01%
BenchmarkAppendFloatExp                 174           175           +0.57%
BenchmarkAppendFloatNegExp              169           174           +2.96%
BenchmarkAppendFloatBig                 286           286           +0.00%
BenchmarkAppendFloat32Integer           99.9          102           +2.10%
BenchmarkAppendFloat32ExactFraction     161           164           +1.86%
BenchmarkAppendFloat32Point             199           201           +1.01%
BenchmarkAppendFloat32Exp               167           168           +0.60%
BenchmarkAppendFloat32NegExp            163           169           +3.68%
BenchmarkAppendFloat64Fixed1            137           134           -2.19%
BenchmarkAppendFloat64Fixed2            144           146           +1.39%
BenchmarkAppendFloat64Fixed3            138           140           +1.45%
BenchmarkAppendFloat64Fixed4            144           145           +0.69%

The performance difference is significant if the fast path conversion is
explicitly turned off (ftoa.go:101):

benchmark                               old ns/op     new ns/op     delta
BenchmarkFormatFloatDecimal             459           427           -6.97%
BenchmarkFormatFloat                    1560          1180          -24.36%
BenchmarkFormatFloatExp                 5501          3128          -43.14%
BenchmarkFormatFloatNegExp              24085         14360         -40.38%
BenchmarkFormatFloatBig                 1409          1081          -23.28%
BenchmarkAppendFloatDecimal             248           226           -8.87%
BenchmarkAppendFloat                    1315          982           -25.32%
BenchmarkAppendFloatExp                 5274          2869          -45.60%
BenchmarkAppendFloatNegExp              23905         14054         -41.21%
BenchmarkAppendFloatBig                 1194          860           -27.97%
BenchmarkAppendFloat32Integer           167           175           +4.79%
BenchmarkAppendFloat32ExactFraction     182           184           +1.10%
BenchmarkAppendFloat32Point             556           564           +1.44%
BenchmarkAppendFloat32Exp               1134          918           -19.05%
BenchmarkAppendFloat32NegExp            2679          1801          -32.77%
BenchmarkAppendFloat64Fixed1            274           238           -13.14%
BenchmarkAppendFloat64Fixed2            494           368           -25.51%
BenchmarkAppendFloat64Fixed3            1833          1008          -45.01%
BenchmarkAppendFloat64Fixed4            6133          3596          -41.37%

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

Fix tracing of syscall exit after:
https://go-review.googlesource.com/#/c/7504/

Change-Id: Idcde2aa826d2b9a05d0a90a80242b6bfa78846ab
Reviewed-on: https://go-review.googlesource.com/8728Reviewed-by: Rick Hudson <rlh@golang.org>
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fixes #10378

This is clumsy, but currently cover tool fails as:

$ go test -run=none -cover syscall
syscall_linux_amd64.go:15: can only use //go:noescape with external func implementations
FAIL	syscall [build failed]

This happens because cover tool mishandles //go: comments.
r and gri said that fixing cover is infeasible due to go/ast limitations.

So at least fix the offending code so that coverage works.
This come up in context of coverage-guided fuzzing which works best
with program-wide coverage.

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

The flag updates error annotations in test files from actual compiler output.
This is useful when doing compiler changes that add/remove/change lots of errors,
or when adding lots of new tests.
Also I noticed at least 2 cases where annotation were sub-optimal:
1. The annotation was "leaking param p" when the actual error is
"leaking param p to result ~r1".
2. The annotation was "leaking param m" when the actual errors
are "leaking param m" and "leaking param mv1".

For now it works only for errorcheck mode.

Also, apply the update to escape and liveness tests.
Some files have gccgo-specific errors of the form "gc error|gccgo error",
so it is risky to run update on all files. Gccgo-specific error
does not necessary contain '|', it can be just truncated.

Change-Id: Iaaae767f859dcb8321a8cb4970b2b70969e8a345
Reviewed-on: https://go-review.googlesource.com/5310
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Remove the "netaddr" type, which ambiguously represented either one
address, or a list of addresses. Instead, use "addrList" wherever
multiple addresses are supported.

The "first" method returns the first address matching some condition
(e.g. "is it IPv4?"), primarily to support legacy code that can't handle
multiple addresses.

The "partition" method splits an addrList into two categories, as
defined by some strategy function. This is useful for implementing
Happy Eyeballs, and similar two-channel algorithms.

Finally, internetAddrList (formerly resolveInternetAddr) no longer
mangles the ordering defined by getaddrinfo. In the future, this may
be used by a sequential Dial implementation.

Updates #8453, #8455.

Change-Id: I7375f4c34481580ab40e31d33002a4073a0474f3
Reviewed-on: https://go-review.googlesource.com/8360Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Update #9855

In preparation for introducing direct use of a zero register on
platforms that support it, take the opportunity to clean up
Componentgen a bit.

Change-Id: I120ce1ffcca8c4f7603bfe76bfa1aedd27ebb4d2
Reviewed-on: https://go-review.googlesource.com/8691
Run-TryBot: Dave Cheney <dave@cheney.net>
Reviewed-by: Minux Ma <minux@golang.org>

'themoduledata' doesn't really make sense now we support multiple moduledata
objects.

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

If GOBIN is not empty the build moves the go executable
to a new path. When this test runs it fails to find the
go cmd in the GOROOT.

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

This changes all the places that consult themoduledata to consult a
linked list of moduledata objects, as will be necessary for
-linkshared to work.

Obviously, as there is as yet no way of adding moduledata objects to
this list, all this change achieves right now is wasting a few
instructions here and there.

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

Modelled somewhat on the -race support.

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

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

Broken by CL 8541.

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

Currently, the initial heap size reported in the gctrace line is the
heap_live right before sweep termination. However, we triggered GC
when heap_live reached next_gc, and there may have been significant
allocation between that point and the beginning of sweep
termination. Ideally these would be essentially the same, but
currently there's scheduler delay when readying the GC goroutine as
well as delay from background sweep finalization.

We should fix this delay, but in the mean time, to give the user a
better idea of how much the heap grew during the whole of garbage
collection, report the trigger rather than what the heap size happened
to be after the garbage collector finished rolling out of bed. This
will also be more useful for heap growth plots.

Change-Id: I08476b9fbcfb2de90592405e9c9f434dfb9eb1f8
Reviewed-on: https://go-review.googlesource.com/8512Reviewed-by: Rick Hudson <rlh@golang.org>

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

According to Go execution modes, a Go program compiled with
-buildmode=c-archive has a main function, but it is ignored on run.
This gives the runtime the information it needs not to run the main.

I have this working with pending linker changes on darwin/amd64.

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

Print("") was printing a header but no line.

Fixes #9665.

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

Also unify the tests where possible to make it easy to add more.

Fixes #10273.

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

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>