Not only by network, transport-layer intermediaries but by
virtualization stuff in a node, it is hard to identify the root cause of
weird faults without information of packet flows after disaster
happened.

This change adds Source field to OpError to be able to represent a
5-tuple of internet transport protocols for helping dealing with
complicated systems.

Also clarifies the usage of Source and Addr fields.

Updates #4856.

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

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

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

RFC 1035 3.3.14 allows a TXT record to contain one or more <character-string>s.
The current implementation returns a "no such host" error if there is more
than one <character-string> in the TXT record.

Fixes #10482

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

The TestAfterQueueing test is inherently flaky because it relies on
independent kernel threads being scheduled within the "delta" duration
of each other.  Normally, delta is 100ms but during "short" testing,
it's reduced to 20ms.

On at least OpenBSD, the CPU scheduler operates in 10ms time slices,
so high system load (e.g., from running multiple Go unit tests in
parallel, as happens during all.bash) can occasionally cause >20ms
scheduling delays and result in test flaking.  This manifests as issue
9903, which is the currently the most common OpenBSD flake.

To mitigate this delay, only reduce the delta duration to 20ms for the
first attempt during short testing.  If this fails and the test is
reattempted, subsequent attempts instead use a full 100ms delta.

Fixes #9903.

Change-Id: I11bdfa939e5be915f67ffad8a8aef6ed8772159a
Reviewed-on: https://go-review.googlesource.com/9510
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

For new compile-only builder.

Change-Id: Ic374c582fcada761386fc852fdbdba814b4ac9e2
Reviewed-on: https://go-review.googlesource.com/9438Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>

Update #10305

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

Sequence of operations:
- Go code does a systemstack call
- during the systemstack call, receive a signal
- signal requests a traceback of all goroutines

The orignal G is still marked as _Grunning, so the traceback code
refuses to print its stack.

Fix by allowing traceback of Gs whose caller is on the same M as G is.
G can't be modifying its stack if that is the case.

Fixes #10546

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

The problem is not actually specific to android/arm. Linux/ARM's
runtime.clone set the stack pointer to child_stk-4 before calling
the fn. And then when fn returns, it tries to write to 4(R13) to
provide argument for runtime.exit, which is just beyond the allocated
child stack, and thus it will corrupt the heap randomly or trigger
segfault if that memory happens to be unmapped.

While we're at here, shorten the test polling interval to 0.1s to
speed up the test (it was only checking at 1s interval, which means
the test takes at least 1s).

Fixes #10548.

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

Print it out much like godoc so there isn't a single block of text.
Print the symbol before its comment and indent the comment so
individual symbols separate visually.

Buffer the output.

Add a -c option to force case-sensitive matching.

Allow two arguments, like godoc, to help disambiguate cases
where path and symbol may be confused.

Improve the documentation printed by go help doc.

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

The heap statistics were only written if asked for a profile with debug > 0,
but that also prints a stack trace for each profile line, which is comparatively
much noisier. The statistics are short enough and separate enough
(they only appear at the end) and useful enough that we can print them
always.

This means that people using -test.memprofile in tests will get a memory
profile with statistics included now. Pprof won't care, but if people care to
look, the numbers will be there.

This avoids the need for hacks like using -memprofilerate=1 to find
the number of allocations.

Change-Id: I10a4f593403d0315aad11b37c6e554b734caa73f
Reviewed-on: https://go-review.googlesource.com/9491Reviewed-by: David Chase <drchase@google.com>

Removes the unused *bufio.Reader from the object controlling the
linker's primary output.

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

This doesn't test much with gccgo, but at least it builds now, and the
test does, unsurprisingly, pass.  A proper test would require adding
assembly files in GCC syntax for all platforms that gccgo supports,
which would be infeasible.

Also added copyright headers to the asm files.

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

Disable disassembly with external linking test on openbsd/arm, since this
platform does not currently support cgo/external linking.

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

When reading the object files for linking, liblink takes care of
generate the data for them.

This is a port of https://golang.org/cl/3101 to Go.

Change-Id: Ie3e2d6515bd7d253a8c1e25c70ef8fed064436d8
Signed-off-by: Shenghou Ma <minux@golang.org>
Reviewed-on: https://go-review.googlesource.com/8383Reviewed-by: Ian Lance Taylor <iant@golang.org>

There's no need to call/ret to the body implementation.
It can write the result to the right place.  Just jump to
it and have it return to our caller.

Old:
  call body implementation
  compute result
  put result in a register
  return
  write register to result location
  return

New:
  load address of result location into a register
  jump to body implementation
  compute result
  write result to passed-in address
  return

It's a bit tricky on 386 because there is no free register
with which to pass the result location.  Free up a register
by keeping around blen-alen instead of both alen and blen.

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

Gdb is not able to backtrace our non-standard stack frames on RISC
architectures without frame pointer.

Change-Id: Id62a566ce2d743602ded2da22ff77b9ae34bc5ae
Signed-off-by: Shenghou Ma <minux@golang.org>
Reviewed-on: https://go-review.googlesource.com/9456Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

GIF's bounds.

Also change the implicit Config Width and Height to be the
Rectangle.Max, not the Dx and Dy, of the first frame's bounds. For the
case where the first frame's bounds is something like (5,5)-(8,8), the
overall width should be 8, not 3.

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

Also, please be informed that the Write method on both connected and
unconnected-mode sockets may return a positive number of bytes written
with timeout or use of closed network connection error.

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

This started out as trying to remove Bool2int calls, which it does a bit, but
mostly it ended up being removing the Link.Symmorestack array which seemed a
pointless bit of caching.

Change-Id: I91a51eb08cb4b08f3f9f093b575306499267b67a
Reviewed-on: https://go-review.googlesource.com/9239Reviewed-by: Minux Ma <minux@golang.org>
Run-TryBot: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

With 128KB stack reservation, on 32-bit Windows, the maximum number
threads is ~9000.

The original 65535-byte stack commit is causing problem on Windows
XP where it makes the stack reservation to be 1MB despite the fact
that the runtime specified 128KB.

While we're at here, also fix the extra spacings in the unable to
create more OS thread error message: println will insert a space
between each argument.

See #9457 for more information.

Change-Id: I3a82f7d9717d3d55211b6eb1c34b00b0eaad83ed
Reviewed-on: https://go-review.googlesource.com/2237Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Minux Ma <minux@golang.org>

In the followup changes, tests that require external facilities such as
DNS servers and RRs will move into external_test.go.

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

They have to read the boolean into a register first and then do
the comparison.

Fixes #10598.

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

To avoid confusion with the runtime concept of copying stack.

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

The previous CL implemented decoding, but not encoding.

Also return the global color map (if present) for DecodeConfig.

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

Technically you must initialize static pthread_mutex_t and
pthread_cond_t variables with the appropriate INITIALIZER macro.  In
practice the default initializers are zero anyhow, but it's still good
code hygiene.

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

Fixes #10366 (how to set custom headers)
Fixes #9836 (PATCH in PostForm)
Fixes #9276 (generating a server-side Request for testing)
Update #8991 (clarify Response.Write for now; export ReverseProxy's copy later?)

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

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

No code changes.

Fixes #8992

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

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

These were lost in the transition from 8a/6a to asm.
Also, in the process, discover more aliases. I'm betting the missing
ones were a casualty of the recent merge of 386 and amd64.

Update #10385.

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

Change-Id: Icf212fc7ea108ff22bb7fa9da137410d729d2569
Reviewed-on: https://go-review.googlesource.com/9413Reviewed-by: Adam Langley <agl@golang.org>

This change corrects the serialization of asn1.Flag values, so that
when set, they serialize to an empty value, and when unset, they are
omitted. It also adds a format parameter that allows calling code
to control whether time.Time values are serialized as UTCTime or
GeneralizedTime.

Change-Id: I6d97abf009ea317338dab30c80f35a2de7e07104
Reviewed-on: https://go-review.googlesource.com/5970Reviewed-by: Adam Langley <agl@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>

Previously, unknown critical extensions were a parse error. However, for
some cases one wishes to parse and use a certificate that may contain
these extensions. For example, when using a certificate in a TLS server:
it's the client's concern whether it understands the critical extensions
but the server still wishes to parse SNI values out of the certificate
etc.

This change moves the rejection of unknown critical extensions from
ParseCertificate to Certificate.Verify. The former will now record the
OIDs of unknown critical extensions in the Certificate and the latter
will fail to verify certificates with them. If a user of this package
wishes to handle any unknown critical extensions themselves, they can
extract the extensions from Certificate.Extensions, process them and
remove known OIDs from Certificate.UnknownCriticalExtensions.

See discussion at
https://groups.google.com/forum/#!msg/golang-nuts/IrzoZlwalTQ/qdK1k-ogeHIJ
and in the linked bug.

Fixes #10459

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

scanobject with ptrmask!=nil is only ever called with the base
pointer of a heap object. Currently, scanobject calls
heapBitsForObject, which goes to a great deal of trouble to check
that the pointer points into the heap and to find the base of the
object it points to, both of which are completely unnecessary in
this case.

Replace this call to heapBitsForObject with much simpler logic to
fetch the span and compute the heap bits.

Benchmark results with five runs:

name                                    old mean                new mean        delta
BenchmarkBinaryTree17              9.21s × (0.95,1.02)     8.55s × (0.91,1.03)  -7.16% (p=0.022)
BenchmarkFannkuch11                2.65s × (1.00,1.00)     2.62s × (1.00,1.00)  -1.10% (p=0.000)
BenchmarkFmtFprintfEmpty          73.2ns × (0.99,1.01)    71.7ns × (1.00,1.01)  -1.99% (p=0.004)
BenchmarkFmtFprintfString          302ns × (0.99,1.00)     292ns × (0.98,1.02)  -3.31% (p=0.020)
BenchmarkFmtFprintfInt             281ns × (0.98,1.01)     279ns × (0.96,1.02)  ~ (p=0.596)
BenchmarkFmtFprintfIntInt          482ns × (0.98,1.01)     488ns × (0.95,1.02)  ~ (p=0.419)
BenchmarkFmtFprintfPrefixedInt     382ns × (0.99,1.01)     365ns × (0.96,1.02)  -4.35% (p=0.015)
BenchmarkFmtFprintfFloat           475ns × (0.99,1.01)     472ns × (1.00,1.00)  ~ (p=0.108)
BenchmarkFmtManyArgs              1.89µs × (1.00,1.01)    1.90µs × (0.94,1.02)  ~ (p=0.883)
BenchmarkGobDecode                22.4ms × (0.99,1.01)    21.9ms × (0.92,1.04)  ~ (p=0.332)
BenchmarkGobEncode                24.7ms × (0.98,1.02)    23.9ms × (0.87,1.07)  ~ (p=0.407)
BenchmarkGzip                      397ms × (0.99,1.01)     398ms × (0.99,1.01)  ~ (p=0.718)
BenchmarkGunzip                   96.7ms × (1.00,1.00)    96.9ms × (1.00,1.00)  ~ (p=0.230)
BenchmarkHTTPClientServer         71.5µs × (0.98,1.01)    68.5µs × (0.92,1.06)  ~ (p=0.243)
BenchmarkJSONEncode               46.1ms × (0.98,1.01)    44.9ms × (0.98,1.03)  -2.51% (p=0.040)
BenchmarkJSONDecode               86.1ms × (0.99,1.01)    86.5ms × (0.99,1.01)  ~ (p=0.343)
BenchmarkMandelbrot200            4.12ms × (1.00,1.00)    4.13ms × (1.00,1.00)  +0.23% (p=0.000)
BenchmarkGoParse                  5.89ms × (0.96,1.03)    5.82ms × (0.96,1.04)  ~ (p=0.522)
BenchmarkRegexpMatchEasy0_32       141ns × (0.99,1.01)     142ns × (1.00,1.00)  ~ (p=0.178)
BenchmarkRegexpMatchEasy0_1K       408ns × (1.00,1.00)     392ns × (0.99,1.00)  -3.83% (p=0.000)
BenchmarkRegexpMatchEasy1_32       122ns × (1.00,1.00)     122ns × (1.00,1.00)  ~ (p=0.178)
BenchmarkRegexpMatchEasy1_1K       626ns × (1.00,1.01)     624ns × (0.99,1.00)  ~ (p=0.122)
BenchmarkRegexpMatchMedium_32      202ns × (0.99,1.00)     205ns × (0.99,1.01)  +1.58% (p=0.001)
BenchmarkRegexpMatchMedium_1K     54.4µs × (1.00,1.00)    55.5µs × (1.00,1.00)  +1.86% (p=0.000)
BenchmarkRegexpMatchHard_32       2.68µs × (1.00,1.00)    2.71µs × (1.00,1.00)  +0.97% (p=0.002)
BenchmarkRegexpMatchHard_1K       79.8µs × (1.00,1.01)    80.5µs × (1.00,1.01)  +0.94% (p=0.003)
BenchmarkRevcomp                   590ms × (0.99,1.01)     585ms × (1.00,1.00)  ~ (p=0.066)
BenchmarkTemplate                  111ms × (0.97,1.02)     112ms × (0.99,1.01)  ~ (p=0.201)
BenchmarkTimeParse                 392ns × (1.00,1.00)     385ns × (1.00,1.00)  -1.69% (p=0.000)
BenchmarkTimeFormat                449ns × (0.98,1.01)     448ns × (0.99,1.01)  ~ (p=0.550)

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

The underlying *bufio.Reader does everything that's needed here.

Change-Id: If0712a5b4d3142ae4bceaa2efe287eaf2b91e54e
Reviewed-on: https://go-review.googlesource.com/9365Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

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

This reverts commit 81c2233b.

Change-Id: Ie7024f04dba6352ae79ba68d4da5c0c25844cd8c
Reviewed-on: https://go-review.googlesource.com/9397Reviewed-by: Dave Cheney <dave@cheney.net>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Emitting it here instead of rewriting the tree earlier sets us up
to generate an inline check, like we do for single pointers.
But even without the inline check, generating at this level lets
us generate significantly more efficient code, probably due to
having fewer temporaries and less complex high-level code
for the compiler to churn through.

Revcomp is worse, almost certainly due to register pressure.

name                                       old                     new          delta
BenchmarkBinaryTree17              18.0s × (0.99,1.01)     18.0s × (0.99,1.01)  ~
BenchmarkFannkuch11                4.43s × (1.00,1.00)     4.36s × (1.00,1.00)  -1.44%
BenchmarkFmtFprintfEmpty           114ns × (0.95,1.05)      86ns × (0.97,1.06)  -24.12%
BenchmarkFmtFprintfString          468ns × (0.99,1.01)     420ns × (0.99,1.02)  -10.16%
BenchmarkFmtFprintfInt             433ns × (1.00,1.01)     386ns × (0.99,1.02)  -10.74%
BenchmarkFmtFprintfIntInt          748ns × (0.99,1.01)     647ns × (0.99,1.01)  -13.56%
BenchmarkFmtFprintfPrefixedInt     547ns × (0.99,1.01)     499ns × (0.99,1.02)  -8.78%
BenchmarkFmtFprintfFloat           756ns × (1.00,1.01)     689ns × (1.00,1.00)  -8.86%
BenchmarkFmtManyArgs              2.79µs × (1.00,1.01)    2.53µs × (1.00,1.00)  -9.30%
BenchmarkGobDecode                39.6ms × (0.99,1.00)    39.2ms × (0.98,1.01)  -1.07%
BenchmarkGobEncode                37.6ms × (1.00,1.01)    37.5ms × (0.99,1.01)  ~
BenchmarkGzip                      663ms × (0.99,1.02)     660ms × (0.98,1.01)  ~
BenchmarkGunzip                    142ms × (1.00,1.00)     143ms × (1.00,1.00)  ~
BenchmarkHTTPClientServer          132µs × (0.99,1.01)     133µs × (0.99,1.02)  ~
BenchmarkJSONEncode               56.2ms × (0.99,1.01)    54.0ms × (0.98,1.01)  -3.97%
BenchmarkJSONDecode                138ms × (1.00,1.00)     134ms × (0.99,1.02)  -2.70%
BenchmarkMandelbrot200            6.03ms × (1.00,1.01)    6.00ms × (1.00,1.01)  ~
BenchmarkGoParse                  9.82ms × (0.93,1.10)   10.35ms × (0.88,1.11)  ~
BenchmarkRegexpMatchEasy0_32       207ns × (1.00,1.00)     163ns × (0.99,1.01)  -21.26%
BenchmarkRegexpMatchEasy0_1K       581ns × (1.00,1.01)     566ns × (0.99,1.00)  -2.50%
BenchmarkRegexpMatchEasy1_32       185ns × (0.99,1.01)     138ns × (1.00,1.01)  -25.41%
BenchmarkRegexpMatchEasy1_1K       975ns × (1.00,1.01)     892ns × (1.00,1.00)  -8.51%
BenchmarkRegexpMatchMedium_32      328ns × (0.99,1.00)     252ns × (1.00,1.00)  -23.17%
BenchmarkRegexpMatchMedium_1K     88.6µs × (1.00,1.01)    73.0µs × (1.00,1.01)  -17.66%
BenchmarkRegexpMatchHard_32       4.69µs × (0.95,1.03)    3.85µs × (1.00,1.01)  -17.91%
BenchmarkRegexpMatchHard_1K        133µs × (1.00,1.01)     117µs × (1.00,1.00)  -12.34%
BenchmarkRevcomp                   902ms × (0.99,1.05)    1001ms × (0.94,1.01)  +11.04%
BenchmarkTemplate                  174ms × (0.99,1.01)     160ms × (0.99,1.01)  -7.70%
BenchmarkTimeParse                 639ns × (1.00,1.00)     622ns × (1.00,1.00)  -2.66%
BenchmarkTimeFormat                736ns × (1.00,1.01)     736ns × (1.00,1.02)  ~

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

I believe the benchmarks that get slower are under register pressure,
and not making the call unconditionally makes the pressure worse,
and the register allocator doesn't do a great job. But part of the point
of this sequence is to get the write barriers out of the way so I can work
on the register allocator, so that's okay.

name                                       old                     new          delta
BenchmarkBinaryTree17              17.9s × (1.00,1.01)     18.0s × (0.99,1.01)  ~
BenchmarkFannkuch11                4.43s × (1.00,1.00)     4.43s × (1.00,1.00)  ~
BenchmarkFmtFprintfEmpty           110ns × (1.00,1.06)     114ns × (0.95,1.05)  ~
BenchmarkFmtFprintfString          487ns × (0.99,1.00)     468ns × (0.99,1.01)  -4.00%
BenchmarkFmtFprintfInt             450ns × (0.99,1.00)     433ns × (1.00,1.01)  -3.88%
BenchmarkFmtFprintfIntInt          762ns × (1.00,1.00)     748ns × (0.99,1.01)  -1.84%
BenchmarkFmtFprintfPrefixedInt     584ns × (0.99,1.01)     547ns × (0.99,1.01)  -6.26%
BenchmarkFmtFprintfFloat           738ns × (1.00,1.00)     756ns × (1.00,1.01)  +2.37%
BenchmarkFmtManyArgs              2.80µs × (1.00,1.01)    2.79µs × (1.00,1.01)  ~
BenchmarkGobDecode                39.0ms × (0.99,1.00)    39.6ms × (0.99,1.00)  +1.54%
BenchmarkGobEncode                37.8ms × (0.98,1.01)    37.6ms × (1.00,1.01)  ~
BenchmarkGzip                      661ms × (0.99,1.01)     663ms × (0.99,1.02)  ~
BenchmarkGunzip                    142ms × (1.00,1.00)     142ms × (1.00,1.00)  ~
BenchmarkHTTPClientServer          132µs × (0.99,1.01)     132µs × (0.99,1.01)  ~
BenchmarkJSONEncode               56.3ms × (0.99,1.01)    56.2ms × (0.99,1.01)  ~
BenchmarkJSONDecode                138ms × (0.99,1.01)     138ms × (1.00,1.00)  ~
BenchmarkMandelbrot200            6.01ms × (1.00,1.00)    6.03ms × (1.00,1.01)  +0.23%
BenchmarkGoParse                  10.2ms × (0.87,1.05)     9.8ms × (0.93,1.10)  ~
BenchmarkRegexpMatchEasy0_32       208ns × (1.00,1.00)     207ns × (1.00,1.00)  ~
BenchmarkRegexpMatchEasy0_1K       588ns × (1.00,1.00)     581ns × (1.00,1.01)  -1.27%
BenchmarkRegexpMatchEasy1_32       182ns × (0.99,1.01)     185ns × (0.99,1.01)  +1.65%
BenchmarkRegexpMatchEasy1_1K       986ns × (1.00,1.01)     975ns × (1.00,1.01)  -1.17%
BenchmarkRegexpMatchMedium_32      323ns × (1.00,1.01)     328ns × (0.99,1.00)  +1.55%
BenchmarkRegexpMatchMedium_1K     89.9µs × (1.00,1.00)    88.6µs × (1.00,1.01)  -1.38%
BenchmarkRegexpMatchHard_32       4.72µs × (0.95,1.01)    4.69µs × (0.95,1.03)  ~
BenchmarkRegexpMatchHard_1K        133µs × (1.00,1.01)     133µs × (1.00,1.01)  ~
BenchmarkRevcomp                   900ms × (1.00,1.05)     902ms × (0.99,1.05)  ~
BenchmarkTemplate                  168ms × (0.99,1.01)     174ms × (0.99,1.01)  +3.30%
BenchmarkTimeParse                 637ns × (1.00,1.00)     639ns × (1.00,1.00)  +0.31%
BenchmarkTimeFormat                738ns × (1.00,1.00)     736ns × (1.00,1.01)  ~

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