LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/108030044

LGTM=r
R=golang-codereviews, bradfitz, r
CC=golang-codereviews
https://golang.org/cl/109020043

Printf("%x", "abc") was "0x610x620x63"; is now "0x616263", which
is surely better.
Printf("% #x", "abc") is still "0x61 0x62 0x63".

Fixes #8080.

LGTM=bradfitz, gri
R=golang-codereviews, bradfitz, gri
CC=golang-codereviews
https://golang.org/cl/106990043

Fixes build.

LGTM=dave
R=golang-codereviews, dave
CC=golang-codereviews
https://golang.org/cl/105140047

Also added a test to verify os.Getppid() works across all platforms

LGTM=alex.brainman
R=golang-codereviews, alex.brainman, shreveal, iant
CC=golang-codereviews
https://golang.org/cl/102320044

Generated by addca.

R=gobot
CC=golang-codereviews
https://golang.org/cl/102410044

Reportedly in the Linux 3.16 kernel the VDSO will not have
section headers or a normal symbol table.

Too late for 1.3 but perhaps for 1.3.1, if there is one.

Fixes #8197.

LGTM=rsc
R=golang-codereviews, mattn.jp, rsc
CC=golang-codereviews
https://golang.org/cl/101260044

algorithm.

See https://golang.org/cl/105750045/ for an implementation of
TIFF's LZW.

LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/102940043

bufio.Scanner.Scan returns whether the scan succeeded, not whether it
is done, so the test was mistakenly breaking early.

LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/93670045

LGTM=minux
R=golang-codereviews, minux
CC=golang-codereviews
https://golang.org/cl/102340044

makes windows-amd64-race benchmarks slower

««« original CL description
testing: make benchmarking faster

Allow the number of benchmark iterations to grow faster for fast benchmarks, and don't round up twice.

Using the default benchtime, this CL reduces wall clock time to run benchmarks:

net/http        49s   -> 37s   (-24%)
runtime         8m31s -> 5m55s (-30%)
bytes           2m37s -> 1m29s (-43%)
encoding/json   29s   -> 21s   (-27%)
strings         1m16s -> 53s   (-30%)

LGTM=crawshaw
R=golang-codereviews, crawshaw
CC=golang-codereviews
https://golang.org/cl/101970047
»»»

TBR=josharian
CC=golang-codereviews
https://golang.org/cl/105950044

LGTM=rsc
R=golang-codereviews, rsc
CC=golang-codereviews
https://golang.org/cl/101270043

It appears that something about Go on Windows
cannot handle the fault cause by a jump to address 0.
The way Go represents and calls functions, this
never happened at all, until CL 105140044.

This CL changes the code added in CL 105140044
to make jump to 0 impossible once again.

Fixes #8047. (again, on Windows)

TBR=bradfitz
R=golang-codereviews, dave
CC=adg, golang-codereviews, iant, r
https://golang.org/cl/105120044

R=rsc
CC=golang-codereviews
https://golang.org/cl/105930043

LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/108950046

CC=golang-codereviews
https://golang.org/cl/103340046

'u' is not micro, µ (U+00B5) is.

LGTM=gri, bradfitz
R=golang-codereviews, bradfitz, gri
CC=golang-codereviews
https://golang.org/cl/105030046

Rob asked for this change to make maintaining go1.4.txt easier.
If you are not sure of a change, it is still okay to send for review.

LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/109880044

jmpdefer modifies PC, SP, and LR, and not atomically,
so walking past jmpdefer will often end up in a state
where the three are not a consistent execution snapshot.
This was causing warning messages a few frames later
when the traceback realized it was confused, but given
the right memory it could easily crash instead.

Update #8153

LGTM=minux, iant
R=golang-codereviews, minux, iant
CC=golang-codereviews, r
https://golang.org/cl/107970043

Fixes #8047.

LGTM=r, iant
R=golang-codereviews, r, iant
CC=dvyukov, golang-codereviews, khr
https://golang.org/cl/105140044

The test requires that timerproc runs, but busy loops and starves
the scheduler so that, with high probability, timerproc doesn't run.
Avoid the issue by expecting the test to succeed; if not, a major
outside timeout will kill it and let us know.

As you can see from the diffs, there have been several attempts to
fix this with chicanery, but none has worked. Don't bother trying
any more.

Fixes #8136.

LGTM=rsc
R=rsc, josharian
CC=golang-codereviews
https://golang.org/cl/105140043

It should've been removed in https://golang.org/cl/9365044

Thanks to Jacek Masiulaniec for noticing.

LGTM=ruiu
R=ruiu
CC=golang-codereviews
https://golang.org/cl/109880043

Allow the number of benchmark iterations to grow faster for fast benchmarks, and don't round up twice.

Using the default benchtime, this CL reduces wall clock time to run benchmarks:

net/http        49s   -> 37s   (-24%)
runtime         8m31s -> 5m55s (-30%)
bytes           2m37s -> 1m29s (-43%)
encoding/json   29s   -> 21s   (-27%)
strings         1m16s -> 53s   (-30%)

LGTM=crawshaw
R=golang-codereviews, crawshaw
CC=golang-codereviews
https://golang.org/cl/101970047

	Contains a link to /lib/godoc/analysis/help.html
       which is not yet live.

LGTM=r
R=r, adg
CC=golang-codereviews
https://golang.org/cl/88560044

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/105890044

Optimize IP.String, IPMask.String and ParseIP.

benchmark                old ns/op    new ns/op    delta
BenchmarkParseIP              2216         1849  -16.56%
BenchmarkIPString             7828         2486  -68.24%
BenchmarkIPMaskString         3872          659  -82.98%

LGTM=mikioh.mikioh, dave, bradfitz
R=golang-codereviews, mikioh.mikioh, dave, bradfitz
CC=golang-codereviews
https://golang.org/cl/95750043

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/104080043

Fixes #8168.

TBR=bradfitz
R=golang-codereviews
CC=golang-codereviews
https://golang.org/cl/107950043

TBR=bradfitz
R=golang-codereviews
CC=golang-codereviews
https://golang.org/cl/104090044

Call copy with as large buffer as possible to reduce the
number of function calls.

benchmark                 old ns/op    new ns/op    delta
BenchmarkBytesRepeat            540          162  -70.00%
BenchmarkStringsRepeat          563          177  -68.56%

LGTM=josharian
R=golang-codereviews, josharian, dave, dvyukov
CC=golang-codereviews
https://golang.org/cl/90550043

Remove unnecessary blank line.

LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/105040045

Make sure stack copier doesn't barf on a nil defer.
Bug was fixed in https://golang.org/cl/101800043
This change just adds a test.

Fixes #8047

LGTM=dvyukov, rsc
R=dvyukov, rsc
CC=golang-codereviews
https://golang.org/cl/108840043

LGTM=adonovan
R=rsc, adonovan
CC=golang-codereviews
https://golang.org/cl/104050045

Previously, an input string was stripped of newline
characters at the beginning of DecodeString and then passed
to Decode. Decode again tried to strip newline characters.
That's waste of time.

benchmark                 old MB/s     new MB/s  speedup
BenchmarkDecodeString        38.37        65.20    1.70x

LGTM=dave, bradfitz
R=golang-codereviews, dave, bradfitz
CC=golang-codereviews
https://golang.org/cl/91770051

There is a hierarchy of location defined by loop depth:

        -1 = the heap
        0 = function results
        1 = local variables (and parameters)
        2 = local variable declared inside a loop
        3 = local variable declared inside a loop inside a loop
        etc

In general if an address from loopdepth n is assigned to
something in loop depth m < n, that indicates an extended
lifetime of some form that requires a heap allocation.

Function results can be local variables too, though, and so
they don't actually fit into the hierarchy very well.
Treat the address of a function result as level 1 so that
if it is written back into a result, the address is treated
as escaping.

Fixes #8185.

LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/108870044

Pending CL 101750048.
For submission after the 1.3 release.

Fixes #8065.

LGTM=adonovan
R=adonovan
CC=golang-codereviews
https://golang.org/cl/93550043

Provide Nextafter64 as alias to Nextafter.
For submission after the 1.3 release.

Fixes #8117.

LGTM=adonovan
R=adonovan
CC=golang-codereviews
https://golang.org/cl/101750048

The analysis for &x was using the loop depth on x set
during x's declaration. A type switch creates a list of
implicit declarations that were not getting initialized
with loop depths.

Fixes #8176.

LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/108860043

LGTM=rsc
R=dave, rsc
CC=golang-codereviews
https://golang.org/cl/105030043

Fixes #8180

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/105040043