The testdata/e.txt input is repeated on the longer benchmarks, but the
length of that data is less than flate's window size, so the numbers are
essentially measuring the performance of a trivial compression. A follow-up
CL will add more data to testdata/e.txt.

Sample output on my laptop (linux, amd64):

BenchmarkDecodeDigitsSpeed1e4	    5000	    603153 ns/op	  16.58 MB/s
BenchmarkDecodeDigitsSpeed1e5	    1000	   1465602 ns/op	  68.23 MB/s
BenchmarkDecodeDigitsSpeed1e6	     200	   8036050 ns/op	 124.44 MB/s
BenchmarkDecodeDigitsDefault1e4	    5000	    581796 ns/op	  17.19 MB/s
BenchmarkDecodeDigitsDefault1e5	    2000	    846653 ns/op	 118.11 MB/s
BenchmarkDecodeDigitsDefault1e6	     500	   3385782 ns/op	 295.35 MB/s
BenchmarkDecodeDigitsCompress1e4	    5000	    581180 ns/op	  17.21 MB/s
BenchmarkDecodeDigitsCompress1e5	    2000	    846209 ns/op	 118.17 MB/s
BenchmarkDecodeDigitsCompress1e6	     500	   3386174 ns/op	 295.32 MB/s
BenchmarkDecodeTwainSpeed1e4	    5000	    643563 ns/op	  15.54 MB/s
BenchmarkDecodeTwainSpeed1e5	     500	   5418408 ns/op	  18.46 MB/s
BenchmarkDecodeTwainSpeed1e6	      50	  52277520 ns/op	  19.13 MB/s
BenchmarkDecodeTwainDefault1e4	    5000	    583551 ns/op	  17.14 MB/s
BenchmarkDecodeTwainDefault1e5	     500	   4443428 ns/op	  22.51 MB/s
BenchmarkDecodeTwainDefault1e6	      50	  41862080 ns/op	  23.89 MB/s
BenchmarkDecodeTwainCompress1e4	    5000	    583490 ns/op	  17.14 MB/s
BenchmarkDecodeTwainCompress1e5	     500	   4426356 ns/op	  22.59 MB/s
BenchmarkDecodeTwainCompress1e6	      50	  41657940 ns/op	  24.01 MB/s
BenchmarkEncodeDigitsSpeed1e4	    2000	   1230907 ns/op	   8.12 MB/s
BenchmarkEncodeDigitsSpeed1e5	    1000	   2319129 ns/op	  43.12 MB/s
BenchmarkEncodeDigitsSpeed1e6	     100	  12378950 ns/op	  80.78 MB/s
BenchmarkEncodeDigitsDefault1e4	    1000	   1597865 ns/op	   6.26 MB/s
BenchmarkEncodeDigitsDefault1e5	     500	   3163458 ns/op	  31.61 MB/s
BenchmarkEncodeDigitsDefault1e6	     100	  18770240 ns/op	  53.28 MB/s
BenchmarkEncodeDigitsCompress1e4	    1000	   1603461 ns/op	   6.24 MB/s
BenchmarkEncodeDigitsCompress1e5	     500	   3168766 ns/op	  31.56 MB/s
BenchmarkEncodeDigitsCompress1e6	     100	  18855830 ns/op	  53.03 MB/s
BenchmarkEncodeTwainSpeed1e4	    1000	   1338049 ns/op	   7.47 MB/s
BenchmarkEncodeTwainSpeed1e5	     500	   7341622 ns/op	  13.62 MB/s
BenchmarkEncodeTwainSpeed1e6	      50	  67484600 ns/op	  14.82 MB/s
BenchmarkEncodeTwainDefault1e4	    1000	   1778399 ns/op	   5.62 MB/s
BenchmarkEncodeTwainDefault1e5	     100	  23261810 ns/op	   4.30 MB/s
BenchmarkEncodeTwainDefault1e6	      10	 243533600 ns/op	   4.11 MB/s
BenchmarkEncodeTwainCompress1e4	    1000	   1795469 ns/op	   5.57 MB/s
BenchmarkEncodeTwainCompress1e5	      50	  29447140 ns/op	   3.40 MB/s
BenchmarkEncodeTwainCompress1e6	       5	 321686800 ns/op	   3.11 MB/s
ok  	compress/flate	89.246s

R=rsc, r
CC=golang-dev
https://golang.org/cl/6195055

I'm not sure where the BOM came from, originally.
http://www.gutenberg.org/files/74/74.txt doesn't have it, although
a fresh download of that URL gives me "\r\n"s instead of plain "\n"s,
and the extra line "Character set encoding: ASCII". Maybe Project
Gutenberg has changed their server configuration since we added that
file to the Go repo.

Anyway, this change is just manually excising the BOM from the start
of the file, leaving pure ASCII.

R=r, bradfitz
CC=golang-dev, krasin, rsc
https://golang.org/cl/6197061

Fixes #3589.

R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/6190044

R=r
CC=golang-dev
https://golang.org/cl/6202046

This adds restoring the window position so that the buffer doesn't jump around after the erase/copy.

R=sameer
CC=golang-dev
https://golang.org/cl/5981055

R=golang-dev, rsc
CC=golang-dev, jme, jmeurin
https://golang.org/cl/6192057

R=golang-dev, rsc
CC=golang-dev, jme
https://golang.org/cl/6197058

dictates a CJK rune is only part of a certain specified range if it
is explicitly defined in the Unicode Codepoint Database.
Fixed the code and some of the tests accordingly.

R=r
CC=golang-dev
https://golang.org/cl/6160044

Replace hard-coded version strings with unicode.Version.

R=r, r
CC=golang-dev
https://golang.org/cl/6163045

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/6196047

    This is a follow-up to CL 5978051.
    Use kernel cas64 helper if we can, fallback to LDREXD/STREXD if
    we are on ARMv6 or higher, and to lock-emulated cas64 if on ARMv5.
    A future CL will fix {Add,Load,Store}{Int,Uint}64 and issue 3331.

R=bradfitz, rsc
CC=golang-dev
https://golang.org/cl/6034048

Decode AT_RANDOM, AT_HWCAP, and AT_PLATFORM.
This CL only make use of AT_RANDOM, but future CLs will make use of the others.

R=dave, rsc
CC=golang-dev
https://golang.org/cl/5978051

Some newer Linux distributions (Ubuntu ARM at least) use a new multiarch
directory organization, where dynamic linker is no longer in the hardcoded
path in our linker.
For example, Ubuntu 12.04 ARM hardfloat places its dynamic linker at
/lib/arm-linux-gnueabihf/ld-linux.so.3

Ref: http://lackof.org/taggart/hacking/multiarch/

Also, to support Debian GNU/kFreeBSD as a FreeBSD variant, we need this capability, so it's part of issue 3533.

This CL add a new pragma (#pragma dynlinker "path") to cc.

R=iant, rsc
CC=golang-dev
https://golang.org/cl/6086043

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/6185047

1. In CL 5989057, I made a mistake in the last minute change.
"MOVW.W R4, -4(SP)" should really be "MOVW.W R4, -4(R13)",
as 5l will rewrite offset for SP.
2. misc/cgo/test/issue1560.go tests for parallel sleep of 1s,
but on ARM, the deadline is frequently missed, so change sleep
time to 2s on ARM.

R=golang-dev, dave, rsc
CC=golang-dev
https://golang.org/cl/6202043

benchmark                     old ns/op    new ns/op    delta
BenchmarkExp3Power0x10              732          734   +0.27%
BenchmarkExp3Power0x40              834          836   +0.24%
BenchmarkExp3Power0x100            1600         1579   -1.31%
BenchmarkExp3Power0x400            3478         3417   -1.75%
BenchmarkExp3Power0x1000          19388        19229   -0.82%
BenchmarkExp3Power0x4000         160274       156881   -2.12%
BenchmarkExp3Power0x10000       1552050      1372058  -11.60%
BenchmarkExp3Power0x40000      27328710     15216920  -44.32%
BenchmarkExp3Power0x100000    612349000    131407100  -78.54%
BenchmarkExp3Power0x400000  44073524000   1122195000  -97.45%

R=golang-dev, mtj, gri, rsc
CC=golang-dev, remy
https://golang.org/cl/6176043

This adds proper note handling for Plan 9,
and fixes the issue of properly killing go procs.
Without this change, the first go proc that dies
(using runtime·exit()) would kill all the running
go procs. Proper signal handling is needed.

R=golang-dev, ality, rminnich, rsc
CC=golang-dev, john, mirtchovski
https://golang.org/cl/5617048

Instead use a new type, "Note", whose underlying
type is just a string.  This change allows us to
remove the exported os.Plan9Note type.

R=bradfitz, seed, rsc
CC=golang-dev
https://golang.org/cl/6015046

        Last Part of CL 5601044 (cgo: Linux/ARM support)
        Fixes #1880.

R=golang-dev, dave, rsc
CC=golang-dev
https://golang.org/cl/5988057

        Part 4 of CL 5601044 (cgo: Linux/ARM support)

R=golang-dev, dave, rsc
CC=golang-dev
https://golang.org/cl/5989058

        Part 3 of CL 5601044 (cgo: Linux/ARM support)

R=golang-dev, dave, rsc
CC=golang-dev
https://golang.org/cl/5991066

        Part 2 of CL 5601044 (cgo: Linux/ARM support)

R=dave, rsc
CC=golang-dev
https://golang.org/cl/5989057

        Part 1 of CL 5601044 (cgo: Linux/ARM support)
        Limitation: doesn't support thumb library yet.

R=golang-dev, dave, rsc
CC=golang-dev
https://golang.org/cl/5991065

All current CLs have subject lines, so we don't need to check any more.

R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/6196044

Fixes #3450.

R=rsc, bradfitz
CC=golang-dev
https://golang.org/cl/6035050

Update #3316.

R=dave, kevlar, devon.odell, rsc, minux.ma
CC=golang-dev
https://golang.org/cl/6063053

Updates #3391.

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/6177045

crypto.Hash.New() changed to panicking when the hash function isn't
linked in, but crypto/x509 still expects it to return nil.

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/6175047

R=rsc
CC=golang-dev
https://golang.org/cl/6174049

R=golang-dev, bsiegert, rsc
CC=golang-dev
https://golang.org/cl/6158046

R=golang-dev, bradfitz, dave, rsc, lstoakes, rsc
CC=golang-dev
https://golang.org/cl/6180044

R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/6177043

This makes it possible to inline the prefetch of upcoming
memory addresses during garbage collection, instead of
needing to flush registers, make a function call, and
reload registers.  On garbage collection-heavy workloads,
this results in a 5% speedup.

Fixes #3493.

R=dvyukov, ken, r, dave
CC=golang-dev
https://golang.org/cl/5990066

The first bug was that tertiary ignorables had the same colElem as
implicit colElems, yielding unexpected results. The current encoding
ensures that a non-implicit colElem is never 0.  This fix uncovered
another bug of the trie that indexed incorrectly into the null block.
This was caused by an unfinished optimization that would avoid the
need to max out the most-significant bits of continuation bytes.
This bug was also present in the trie used in exp/norm and has been
fixed there as well. The appearence of the bug was rare, as the lower
blocks happened to be nearly nil.

R=r
CC=golang-dev
https://golang.org/cl/6127070

R=rsc
CC=golang-dev
https://golang.org/cl/6128051

+move zeroization out of the heap mutex

R=golang-dev, iant, rsc
CC=golang-dev
https://golang.org/cl/6094050

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/6136054

R=golang-dev, r, bradfitz, r
CC=golang-dev
https://golang.org/cl/6117062

R=rsc, iant, iant, seed
CC=golang-dev
https://golang.org/cl/5608059

R=dsymonds
CC=golang-dev
https://golang.org/cl/6158043