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

The putpclcdelta function set the DWARF line number PC to
s->value + pcline->pc, which is correct, but the code then set
the local variable pc to epc, which can be a different value.
This caused the next delta in the DWARF table to be wrong.

Fixes #8098.

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

Fixes #8156.

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

align=middle is invalid; use align=center

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

A runtime.Goexit during a panic-invoked deferred call
left the panic stack intact even though all the stack frames
are gone when the goroutine is torn down.
The next goroutine to reuse that struct will have a
bogus panic stack and can cause the traceback routines
to walk into garbage.

Most likely to happen during tests, because t.Fatal might
be called during a deferred func and uses runtime.Goexit.

This "not enough cleared in Goexit" failure mode has
happened to us multiple times now. Clear all the pointers
that don't make sense to keep, not just gp->panic.

Fixes #8158.

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

I am not sure what the rounding here was
trying to do, but it was skipping the first
pointer on native client.

The code above the rounding already checks
that xoffset is widthptr-aligned, so the rnd
was a no-op everywhere but on Native Client.
And on Native Client it was wrong.

Perhaps it was supposed to be rounding down,
not up, but zerorange handles the extra 32 bits
correctly, so the rnd does not seem to be necessary
at all.

This wouldn't be worth doing for Go 1.3 except
that it can affect code on the playground.

Fixes #8155.

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

LGTM=r
R=r, 0xjnml, bradfitz, iant
CC=golang-codereviews
https://golang.org/cl/103070046

Fixes #8148.

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