The old one was inferior.

Fixes #10695.

Change-Id: Ia7fb88c9ceb1b10197b77a54f729865385288d98
Reviewed-on: https://go-review.googlesource.com/9709Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

When a parse error occurred, the lexing goroutine would lay idle.
It's not likely a problem but if the program is for some reason
accepting badly formed data repeatedly, it's wasteful.

The solution is easy: Just drain the input on error. We know this
will succeed because the input is always a string and is therefore
guaranteed finite.

With debugging prints in the package tests I've shown this is effective,
shutting down 79 goroutines that would otherwise linger, out of 123 total.

Fixes #10574.

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

Freezetheworld still has stuff to do when gomaxprocs=1.
In particular, signals can come in on other Ms (like the GC M, say)
and the single user M is still running.

Fixes #10546

Change-Id: I2f07f17d1c81e93cf905df2cb087112d436ca7e7
Reviewed-on: https://go-review.googlesource.com/9551Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

These a series of changes fix inconsistent errors on the package net
APIs. Now almost all the APIs return OpError as a common error type
except Lookup, Resolve and Parse APIs. The Lookup, Resolve and Parse
APIs return more specific errors such as DNSError, AddrError or
ParseError.

An OpError may contain nested error information. For example, Dial may
return an OpError containing a DNSError, AddrError, unexposed type/value
or other package's type/value like the following:
	OpError{/* dial info */, Err: &DNSError{}}
	OpError{/* dial info */, Err: &AddrError{}}
	OpError{/* dial info */, Err: <unexposed type or value>}
	OpError{/* dial info */, Err: <other package's type or value>}

and Read and Write may return an OpError containing other OpError when
an application uses io.Copy or similar:
	OpError{/* for io.Reader */, Err: &OpError{/* for io.Writer */}}

When an endpoint is created for connection-oriented byte-stream
protocols, Read may return an io.EOF when the connection is closed by
remote endpoint.

Fixes #4856.

A series of changes:
- net: fix inconsistent error values on Dial, Listen partially
  https://go.googlesource.com/go/+/89b7c66d0d14462fd7893be4290bdfe5f9063ae1
- net: fix inconsistent error values on Read
  https://go.googlesource.com/go/+/ec1144423f45e010c72363fe59291d43214b6e31
- net: fix inconsistent error values on Write
  https://go.googlesource.com/go/+/11b5f98bf0d5eb8854f735cc332c912725070214
- net: fix inconsistent error values on Close
  https://go.googlesource.com/go/+/310db63c5bc121e7bfccb494c01a6b91a257e7fc
- net: fix inconsistent error values on Accept
  https://go.googlesource.com/go/+/4540e162b1aefda8157372764ad3d290a414ef1d
- net: fix inconsistent error values on File
  https://go.googlesource.com/go/+/885111365ba0a74421059bfbd18f4c57c1e70332
- net: fix inconsistent error values on setters
  https://go.googlesource.com/go/+/2173a27903897c481b0a0daf3ca3e0a0685701db
- net: fix inconsistent error values on Interface
  https://go.googlesource.com/go/+/456cf0f22c93e1a6654980f4a48a564555f6c8a2
- net: fix inconsistent error values on Lookup
  https://go.googlesource.com/go/+/0fc582e87942b2e52bed751b6c56660ba99e9a7d
- net: add Source field to OpError
  https://go.googlesource.com/go/+/afd2d2b6df3ebfe99faf347030f15adfdf422fa0

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

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

When emulating ARM FSQRT instruction, the sqrt function itself
should not use any floating point arithmetics, otherwise it will
clobber the user software FP registers.

Fortunately, the sqrt function only uses floating point instructions
to test for corner cases, so it's easy to make that function does
all it job using pure integer arithmetic only. I've verified that
after this change, runtime.stepflt and runtime.sqrt doesn't contain
any call to _sfloat. (Perhaps we should add //go:nosfloat to make
the compiler enforce this?)

Fixes #10641.

Change-Id: Ida4742c49000fae4fea4649f28afde630ce4c576
Signed-off-by: Shenghou Ma <minux@golang.org>
Reviewed-on: https://go-review.googlesource.com/9570Reviewed-by: Dave Cheney <dave@cheney.net>
Reviewed-by: Keith Randall <khr@golang.org>

The spec at http://www.w3.org/Graphics/GIF/spec-gif89a.txt always says
"color table" and not "color map".

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

OSQRT currently produces incorrect results when used on arm with softfloat.
Disable it on GOARM=5 until the actual problem is found and fixed.

Updates #10641

Change-Id: Ia6f6879fbbb05cb24399c2feee93c1be21113e73
Reviewed-on: https://go-review.googlesource.com/9524Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Dave Cheney <dave@cheney.net>

Whenever we introduce a new GOARCH, older Go releases won't
recognize them and this causes trouble for both our users and
us (we need to add unnecessary build tags).

Go 1.5 has introduced three new GOARCHes so far: arm64 ppc64
ppc64le, we can take the time to introduce GOARCHes for all
common architectures that Go might support in the future to
avoid the problem.

Fixes #10165.

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

Fixes #10638

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

Update #10652

This proposal deletes cmd/internal/ld.Biobuf and replaces all uses with
cmd/internal/obj.Biobuf. As cmd/internal/ld already imported cmd/internal/obj
there are no additional dependencies created.

Notes:

- ld.Boffset included more checks, so it was merged into obj.Boffset
- obj.Bflush was removed in 8d16253c, so replaced all calls to
  ld.Bflush, with obj.Biobuf.Flush.
- Almost all of this change was prepared with sed.

Change-Id: I814854d52f5729a5a40c523c8188e465246b88da
Reviewed-on: https://go-review.googlesource.com/9660Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Dave Cheney <dave@cheney.net>

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

Write should return ErrWriteAfterClose instead
of ErrWriteTooLong when called after Close.

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

This adds a field to the runtime type structure that records the size
of the prefix of objects of that type containing pointers. Any data
after this offset is scalar data.

This is necessary for shrinking the type bitmaps to 1 bit and will
help the garbage collector efficiently estimate the amount of heap
that needs to be scanned.

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

Move the one instance of type structure decoding in the linker that
doesn't live decodesym.go in to decodesym.go.

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

Fixes #10674.

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

shouldtriggergc is slightly expensive due to the call overhead
and the use of an atomic. This CL reduces the number of time
one checks if a GC should be done from one at each allocation
to once when a span is allocated. Since shouldtriggergc is an
important abstraction simply hand inlining it, along with its
atomic instruction would lose the abstraction.

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

At the end of lexInsideAction(), we return lexInsideAction: this is the default
behaviour when we are still parsing an action. But some switch branches return
lexInsideAction too.

So let's ensure code consistency by always reaching the end of the
lexInsideAction function when needed.

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

We shouldn't sort the slots array, as it is used each time the
test is run.  Tests after the first should continue to use the
unsorted ordering.

Note that this doesn't fix the flaky test.  Just a bug I saw
while investigating.

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

global color table.

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

The script was renamed in b3000b6f.

Change-Id: I45ecafff7400e4bff14f31906278609abf2bcb9f
Reviewed-on: https://go-review.googlesource.com/9667Reviewed-by: Andrew Gerrand <adg@golang.org>

Updates #8229.

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

Noopt builds get a larger stack guard.  This test must take that into account.

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

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

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

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

Ideal constants in the template package are a little different from Go.
This is a case that slipped through the cracks: A huge integer number
was accepted as a floating-point number, but this loses precision
and is confusing. Also, the code in the template package (as opposed
to the parse package) wasn't expecting it.

Root this out at the source: If an integer doesn't fit an int64 or uint64,
complain right away.

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

Followup to CL 9505

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

The siz argument to both runtime.newproc and runtime.deferproc is
int32, not uintptr. This problem won't manifest on little-endian
systems because that stack slot is uintptr sized anyway. However,
on big-endian systems, it will make a difference.

Change-Id: I2351d1ec81839abe25375cff95e327b80764c2b5
Reviewed-on: https://go-review.googlesource.com/9647
Run-TryBot: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

The current parser ignores obvious errors such as:
{{0.1.E}}
{{true.any}}
{{"hello".wrong}}
{{nil.E}}

The common problem is that a chain is built from
a literal value. It then panics at execution time.

Furthermore, a double dot triggers the same behavior:
{{..E}}

Addresses a TODO left in Tree.operand to catch these
errors at parsing time.

Note that identifiers can include a '.', and pipelines
could return an object which a field can be derived
from (like a variable), so they are excluded from the check.

Fixes #10615

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

There are three problems:
1. There is no CR at the end of the message.
2. The message is unconditionally printed.
3. The message is printed to stdout.

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

Fixes #9232.

Change-Id: I11a7fb7691d9e7473620db1b7fa29fec359c73d3
Reviewed-on: https://go-review.googlesource.com/9642Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>

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

This change applies CL 9365 to the copy of Biobuf in cmd/internal/obj.

In the process I discovered that some of the methods that should have been
checking the unget buffer before reading were not and it was probably just
dumb luck that we handn't hit these issues before; Bungetc is only used in
one place in cmd/internal/gc and only an unlikely code path.

Change-Id: Ifa0c5c08442e9fe951a5078c6e9ec77a8a4dc2ff
Reviewed-on: https://go-review.googlesource.com/9529Reviewed-by: Daniel Morsing <daniel.morsing@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dave Cheney <dave@cheney.net>
Run-TryBot: Dave Cheney <dave@cheney.net>

The test was measuring something, assuming other goroutines had
already scheduled.

Fixes #10427

Change-Id: I2a4d3906f9d4b5ea44b57d972e303bbe2b0b1cde
Reviewed-on: https://go-review.googlesource.com/9561Reviewed-by: David Crawshaw <crawshaw@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>

An unmatched {{else}} should trigger a parsing error.

The top level parser is able to issue an error in case
of unmatched {{end}}. It does it a posteriori (i.e. after having
parsed the action).

Extend this behavior to also check for unmatched {{else}}

Fixes #10611

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

The usage messages for the flags in gc and ld are using the old
flag argument syntax:
   "arg: description using arg"

Update them to the Go 1.5 flag package's syntax:
   "description using arg"

Fixes #10505

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

This adds a detailed debug dump of the state of the GC controller and
a GODEBUG flag to enable it.

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

(1) Count pointer-free objects found during scanning roots
as marked bytes, by not zeroing the mark total after scanning roots.

(2) Don't count the bytes for the roots themselves, by not adding
them to the mark total in scanblock (the zeroing removed by (1)
was aimed at that add but hitting more).

Combined, (1) and (2) fix the calculation of the marked heap size.
This makes the GC trigger much less often in the Go 1 benchmarks,
which have a global []byte pointing at 256 MB of data.
That 256 MB allocation was not being included in the heap size
in the current code, but was included in Go 1.4.
This is the source of much of the relative slowdown in that directory.

(3) Count the bytes for the roots as scanned work, by not zeroing
the scan total after scanning roots. There is no strict justification
for this, and it probably doesn't matter much either way,
but it was always combined with another buggy zeroing
(removed in (1)), so guilty by association.

Austin noticed this.

name                                    old mean                new mean        delta
BenchmarkBinaryTree17              13.1s × (0.97,1.03)      5.9s × (0.97,1.05)  -55.19% (p=0.000)
BenchmarkFannkuch11                4.35s × (0.99,1.01)     4.37s × (1.00,1.01)  +0.47% (p=0.032)
BenchmarkFmtFprintfEmpty          84.6ns × (0.95,1.14)    85.7ns × (0.94,1.05)  ~ (p=0.521)
BenchmarkFmtFprintfString          320ns × (0.95,1.06)     283ns × (0.99,1.02)  -11.48% (p=0.000)
BenchmarkFmtFprintfInt             311ns × (0.98,1.03)     288ns × (0.99,1.02)  -7.26% (p=0.000)
BenchmarkFmtFprintfIntInt          554ns × (0.96,1.05)     478ns × (0.99,1.02)  -13.70% (p=0.000)
BenchmarkFmtFprintfPrefixedInt     434ns × (0.96,1.06)     393ns × (0.98,1.04)  -9.60% (p=0.000)
BenchmarkFmtFprintfFloat           620ns × (0.99,1.03)     584ns × (0.99,1.01)  -5.73% (p=0.000)
BenchmarkFmtManyArgs              2.19µs × (0.98,1.03)    1.94µs × (0.99,1.01)  -11.62% (p=0.000)
BenchmarkGobDecode                21.2ms × (0.97,1.06)    15.2ms × (0.99,1.01)  -28.17% (p=0.000)
BenchmarkGobEncode                18.1ms × (0.94,1.06)    11.8ms × (0.99,1.01)  -35.00% (p=0.000)
BenchmarkGzip                      650ms × (0.98,1.01)     649ms × (0.99,1.02)  ~ (p=0.802)
BenchmarkGunzip                    143ms × (1.00,1.01)     143ms × (1.00,1.01)  ~ (p=0.438)
BenchmarkHTTPClientServer          110µs × (0.98,1.04)     101µs × (0.98,1.02)  -8.79% (p=0.000)
BenchmarkJSONEncode               40.3ms × (0.97,1.03)    31.8ms × (0.98,1.03)  -20.92% (p=0.000)
BenchmarkJSONDecode                119ms × (0.97,1.02)     108ms × (0.99,1.02)  -9.15% (p=0.000)
BenchmarkMandelbrot200            6.03ms × (1.00,1.01)    6.03ms × (0.99,1.01)  ~ (p=0.750)
BenchmarkGoParse                  8.58ms × (0.89,1.10)    6.80ms × (1.00,1.00)  -20.71% (p=0.000)
BenchmarkRegexpMatchEasy0_32       162ns × (1.00,1.01)     162ns × (0.99,1.02)  ~ (p=0.131)
BenchmarkRegexpMatchEasy0_1K       540ns × (0.99,1.02)     559ns × (0.99,1.02)  +3.58% (p=0.000)
BenchmarkRegexpMatchEasy1_32       139ns × (0.98,1.04)     139ns × (1.00,1.00)  ~ (p=0.466)
BenchmarkRegexpMatchEasy1_1K       889ns × (0.99,1.01)     885ns × (0.99,1.01)  -0.50% (p=0.022)
BenchmarkRegexpMatchMedium_32      252ns × (0.99,1.02)     252ns × (0.99,1.01)  ~ (p=0.469)
BenchmarkRegexpMatchMedium_1K     72.9µs × (0.99,1.01)    73.6µs × (0.99,1.03)  ~ (p=0.168)
BenchmarkRegexpMatchHard_32       3.87µs × (1.00,1.01)    3.86µs × (1.00,1.00)  ~ (p=0.055)
BenchmarkRegexpMatchHard_1K        118µs × (0.99,1.01)     117µs × (0.99,1.00)  ~ (p=0.133)
BenchmarkRevcomp                   995ms × (0.94,1.10)     949ms × (0.99,1.01)  -4.64% (p=0.000)
BenchmarkTemplate                  141ms × (0.97,1.02)     127ms × (0.99,1.01)  -10.00% (p=0.000)
BenchmarkTimeParse                 641ns × (0.99,1.01)     623ns × (0.99,1.01)  -2.79% (p=0.000)
BenchmarkTimeFormat                729ns × (0.98,1.03)     679ns × (0.99,1.00)  -6.93% (p=0.000)

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

The bitmaps were 2 bits per pointer because we needed to distinguish
scalar, pointer, multiword, and we used the leftover value to distinguish
uninitialized from scalar, even though the garbage collector (GC) didn't care.

Now that there are no multiword structures from the GC's point of view,
cut the bitmaps down to 1 bit per pointer, recording just live pointer vs not.

The GC assumes the same layout for stack frames and for the maps
describing the global data and bss sections, so change them all in one CL.

The code still refers to 4-bit heap bitmaps and 2-bit "type bitmaps", since
the 2-bit representation lives (at least for now) in some of the reflect data.

Because these stack frame bitmaps are stored directly in the rodata in
the binary, this CL reduces the size of the 6g binary by about 1.1%.

Performance change is basically a wash, but using less memory,
and smaller binaries, and enables other bitmap reductions.

name                                      old mean                new mean        delta
BenchmarkBinaryTree17                13.2s × (0.97,1.03)     13.0s × (0.99,1.01)  -0.93% (p=0.005)
BenchmarkBinaryTree17-2              9.69s × (0.96,1.05)     9.51s × (0.96,1.03)  -1.86% (p=0.001)
BenchmarkBinaryTree17-4              10.1s × (0.97,1.05)     10.0s × (0.96,1.05)  ~ (p=0.141)
BenchmarkFannkuch11                  4.35s × (0.99,1.01)     4.43s × (0.98,1.04)  +1.75% (p=0.001)
BenchmarkFannkuch11-2                4.31s × (0.99,1.03)     4.32s × (1.00,1.00)  ~ (p=0.095)
BenchmarkFannkuch11-4                4.32s × (0.99,1.02)     4.38s × (0.98,1.04)  +1.38% (p=0.008)
BenchmarkFmtFprintfEmpty            83.5ns × (0.97,1.10)    87.3ns × (0.92,1.11)  +4.55% (p=0.014)
BenchmarkFmtFprintfEmpty-2          81.8ns × (0.98,1.04)    82.5ns × (0.97,1.08)  ~ (p=0.364)
BenchmarkFmtFprintfEmpty-4          80.9ns × (0.99,1.01)    82.6ns × (0.97,1.08)  +2.12% (p=0.010)
BenchmarkFmtFprintfString            320ns × (0.95,1.04)     322ns × (0.97,1.05)  ~ (p=0.368)
BenchmarkFmtFprintfString-2          303ns × (0.97,1.04)     304ns × (0.97,1.04)  ~ (p=0.484)
BenchmarkFmtFprintfString-4          305ns × (0.97,1.05)     306ns × (0.98,1.05)  ~ (p=0.543)
BenchmarkFmtFprintfInt               311ns × (0.98,1.03)     319ns × (0.97,1.03)  +2.63% (p=0.000)
BenchmarkFmtFprintfInt-2             297ns × (0.98,1.04)     301ns × (0.97,1.04)  +1.19% (p=0.023)
BenchmarkFmtFprintfInt-4             302ns × (0.98,1.02)     304ns × (0.97,1.03)  ~ (p=0.126)
BenchmarkFmtFprintfIntInt            554ns × (0.96,1.05)     554ns × (0.97,1.03)  ~ (p=0.975)
BenchmarkFmtFprintfIntInt-2          520ns × (0.98,1.03)     517ns × (0.98,1.02)  ~ (p=0.153)
BenchmarkFmtFprintfIntInt-4          524ns × (0.98,1.02)     525ns × (0.98,1.03)  ~ (p=0.597)
BenchmarkFmtFprintfPrefixedInt       433ns × (0.97,1.06)     434ns × (0.97,1.06)  ~ (p=0.804)
BenchmarkFmtFprintfPrefixedInt-2     413ns × (0.98,1.04)     413ns × (0.98,1.03)  ~ (p=0.881)
BenchmarkFmtFprintfPrefixedInt-4     420ns × (0.97,1.03)     421ns × (0.97,1.03)  ~ (p=0.561)
BenchmarkFmtFprintfFloat             620ns × (0.99,1.03)     636ns × (0.97,1.03)  +2.57% (p=0.000)
BenchmarkFmtFprintfFloat-2           601ns × (0.98,1.02)     617ns × (0.98,1.03)  +2.58% (p=0.000)
BenchmarkFmtFprintfFloat-4           613ns × (0.98,1.03)     626ns × (0.98,1.02)  +2.15% (p=0.000)
BenchmarkFmtManyArgs                2.19µs × (0.96,1.04)    2.23µs × (0.97,1.02)  +1.65% (p=0.000)
BenchmarkFmtManyArgs-2              2.08µs × (0.98,1.03)    2.10µs × (0.99,1.02)  +0.79% (p=0.019)
BenchmarkFmtManyArgs-4              2.10µs × (0.98,1.02)    2.13µs × (0.98,1.02)  +1.72% (p=0.000)
BenchmarkGobDecode                  21.3ms × (0.97,1.05)    21.1ms × (0.97,1.04)  -1.36% (p=0.025)
BenchmarkGobDecode-2                20.0ms × (0.97,1.03)    19.2ms × (0.97,1.03)  -4.00% (p=0.000)
BenchmarkGobDecode-4                19.5ms × (0.99,1.02)    19.0ms × (0.99,1.01)  -2.39% (p=0.000)
BenchmarkGobEncode                  18.3ms × (0.95,1.07)    18.1ms × (0.96,1.08)  ~ (p=0.305)
BenchmarkGobEncode-2                16.8ms × (0.97,1.02)    16.4ms × (0.98,1.02)  -2.79% (p=0.000)
BenchmarkGobEncode-4                15.4ms × (0.98,1.02)    15.4ms × (0.98,1.02)  ~ (p=0.465)
BenchmarkGzip                        650ms × (0.98,1.03)     655ms × (0.97,1.04)  ~ (p=0.075)
BenchmarkGzip-2                      652ms × (0.98,1.03)     655ms × (0.98,1.02)  ~ (p=0.337)
BenchmarkGzip-4                      656ms × (0.98,1.04)     653ms × (0.98,1.03)  ~ (p=0.291)
BenchmarkGunzip                      143ms × (1.00,1.01)     143ms × (1.00,1.01)  ~ (p=0.507)
BenchmarkGunzip-2                    143ms × (1.00,1.01)     143ms × (1.00,1.01)  ~ (p=0.313)
BenchmarkGunzip-4                    143ms × (1.00,1.01)     143ms × (1.00,1.01)  ~ (p=0.312)
BenchmarkHTTPClientServer            110µs × (0.98,1.03)     109µs × (0.99,1.02)  -1.40% (p=0.000)
BenchmarkHTTPClientServer-2          154µs × (0.90,1.08)     149µs × (0.90,1.08)  -3.43% (p=0.007)
BenchmarkHTTPClientServer-4          138µs × (0.97,1.04)     138µs × (0.96,1.04)  ~ (p=0.670)
BenchmarkJSONEncode                 40.2ms × (0.98,1.02)    40.2ms × (0.98,1.05)  ~ (p=0.828)
BenchmarkJSONEncode-2               35.1ms × (0.99,1.02)    35.2ms × (0.98,1.03)  ~ (p=0.392)
BenchmarkJSONEncode-4               35.3ms × (0.98,1.03)    35.3ms × (0.98,1.02)  ~ (p=0.813)
BenchmarkJSONDecode                  119ms × (0.97,1.02)     117ms × (0.98,1.02)  -1.80% (p=0.000)
BenchmarkJSONDecode-2                115ms × (0.99,1.02)     114ms × (0.98,1.02)  -1.18% (p=0.000)
BenchmarkJSONDecode-4                116ms × (0.98,1.02)     114ms × (0.98,1.02)  -1.43% (p=0.000)
BenchmarkMandelbrot200              6.03ms × (1.00,1.01)    6.03ms × (1.00,1.01)  ~ (p=0.985)
BenchmarkMandelbrot200-2            6.03ms × (1.00,1.01)    6.02ms × (1.00,1.01)  ~ (p=0.320)
BenchmarkMandelbrot200-4            6.03ms × (1.00,1.01)    6.03ms × (1.00,1.01)  ~ (p=0.799)
BenchmarkGoParse                    8.63ms × (0.89,1.10)    8.58ms × (0.93,1.09)  ~ (p=0.667)
BenchmarkGoParse-2                  8.20ms × (0.97,1.04)    8.37ms × (0.97,1.04)  +1.96% (p=0.001)
BenchmarkGoParse-4                  8.00ms × (0.98,1.02)    8.14ms × (0.99,1.02)  +1.75% (p=0.000)
BenchmarkRegexpMatchEasy0_32         162ns × (1.00,1.01)     164ns × (0.98,1.04)  +1.35% (p=0.011)
BenchmarkRegexpMatchEasy0_32-2       161ns × (1.00,1.01)     161ns × (1.00,1.00)  ~ (p=0.185)
BenchmarkRegexpMatchEasy0_32-4       161ns × (1.00,1.00)     161ns × (1.00,1.00)  -0.19% (p=0.001)
BenchmarkRegexpMatchEasy0_1K         540ns × (0.99,1.02)     566ns × (0.98,1.04)  +4.98% (p=0.000)
BenchmarkRegexpMatchEasy0_1K-2       540ns × (0.99,1.01)     557ns × (0.99,1.01)  +3.21% (p=0.000)
BenchmarkRegexpMatchEasy0_1K-4       541ns × (0.99,1.01)     559ns × (0.99,1.01)  +3.26% (p=0.000)
BenchmarkRegexpMatchEasy1_32         139ns × (0.98,1.04)     139ns × (0.99,1.03)  ~ (p=0.979)
BenchmarkRegexpMatchEasy1_32-2       139ns × (0.99,1.04)     139ns × (0.99,1.02)  ~ (p=0.777)
BenchmarkRegexpMatchEasy1_32-4       139ns × (0.98,1.04)     139ns × (0.99,1.04)  ~ (p=0.771)
BenchmarkRegexpMatchEasy1_1K         890ns × (0.99,1.03)     885ns × (1.00,1.01)  -0.50% (p=0.004)
BenchmarkRegexpMatchEasy1_1K-2       888ns × (0.99,1.01)     885ns × (0.99,1.01)  -0.37% (p=0.004)
BenchmarkRegexpMatchEasy1_1K-4       890ns × (0.99,1.02)     884ns × (1.00,1.00)  -0.70% (p=0.000)
BenchmarkRegexpMatchMedium_32        252ns × (0.99,1.01)     251ns × (0.99,1.01)  ~ (p=0.081)
BenchmarkRegexpMatchMedium_32-2      254ns × (0.99,1.04)     252ns × (0.99,1.01)  -0.78% (p=0.027)
BenchmarkRegexpMatchMedium_32-4      253ns × (0.99,1.04)     252ns × (0.99,1.01)  -0.70% (p=0.022)
BenchmarkRegexpMatchMedium_1K       72.9µs × (0.99,1.01)    72.7µs × (1.00,1.00)  ~ (p=0.064)
BenchmarkRegexpMatchMedium_1K-2     74.1µs × (0.98,1.05)    72.9µs × (1.00,1.01)  -1.61% (p=0.001)
BenchmarkRegexpMatchMedium_1K-4     73.6µs × (0.99,1.05)    72.8µs × (1.00,1.00)  -1.13% (p=0.007)
BenchmarkRegexpMatchHard_32         3.88µs × (0.99,1.03)    3.92µs × (0.98,1.05)  ~ (p=0.143)
BenchmarkRegexpMatchHard_32-2       3.89µs × (0.99,1.03)    3.93µs × (0.98,1.09)  ~ (p=0.278)
BenchmarkRegexpMatchHard_32-4       3.90µs × (0.99,1.05)    3.93µs × (0.98,1.05)  ~ (p=0.252)
BenchmarkRegexpMatchHard_1K          118µs × (0.99,1.01)     117µs × (0.99,1.02)  -0.54% (p=0.003)
BenchmarkRegexpMatchHard_1K-2        118µs × (0.99,1.01)     118µs × (0.99,1.03)  ~ (p=0.581)
BenchmarkRegexpMatchHard_1K-4        118µs × (0.99,1.02)     117µs × (0.99,1.01)  -0.54% (p=0.002)
BenchmarkRevcomp                     991ms × (0.95,1.10)     989ms × (0.94,1.08)  ~ (p=0.879)
BenchmarkRevcomp-2                   978ms × (0.95,1.11)     962ms × (0.96,1.08)  ~ (p=0.257)
BenchmarkRevcomp-4                   979ms × (0.96,1.07)     974ms × (0.96,1.11)  ~ (p=0.678)
BenchmarkTemplate                    141ms × (0.99,1.02)     145ms × (0.99,1.02)  +2.75% (p=0.000)
BenchmarkTemplate-2                  135ms × (0.98,1.02)     138ms × (0.99,1.02)  +2.34% (p=0.000)
BenchmarkTemplate-4                  136ms × (0.98,1.02)     140ms × (0.99,1.02)  +2.71% (p=0.000)
BenchmarkTimeParse                   640ns × (0.99,1.01)     622ns × (0.99,1.01)  -2.88% (p=0.000)
BenchmarkTimeParse-2                 640ns × (0.99,1.01)     622ns × (1.00,1.00)  -2.81% (p=0.000)
BenchmarkTimeParse-4                 640ns × (1.00,1.01)     622ns × (0.99,1.01)  -2.82% (p=0.000)
BenchmarkTimeFormat                  730ns × (0.98,1.02)     731ns × (0.98,1.03)  ~ (p=0.767)
BenchmarkTimeFormat-2                709ns × (0.99,1.02)     707ns × (0.99,1.02)  ~ (p=0.347)
BenchmarkTimeFormat-4                717ns × (0.98,1.01)     718ns × (0.98,1.02)  ~ (p=0.793)

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