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

It comes up often enough that it's time to provide
the utility of a standard package.

R=r, mirtchovski, adg, rsc, n13m3y3r, ality, go.peter.90, lstoakes, iant, jan.mercl, bsiegert, robert.hencke, rogpeppe, befelemepeseveze, kevlar
CC=golang-dev
https://golang.org/cl/4557047

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

R=golang-dev, adg
CC=golang-dev
https://golang.org/cl/4605041

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

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

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

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

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

With the ReadFrom change in the sendfile CL, it became
possible to illegally send a response to a HEAD request if you
did it via io.Copy.

Fixes #1939

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

gcc-4.6 considers mktemp to be racey

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

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

Need to load math.a so that sqrtGoC is available.
Also was missing prototype.

R=ken2
CC=golang-dev
https://golang.org/cl/4517148

R=lvd
CC=golang-dev
https://golang.org/cl/4591063

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

Thumb code and ARM pre-V4 code is unused,
unmaintained, and almost certainly wrong by now.
Every time I try to change 5l I have to sort out
what's dead code and what's not.

30% of lines of code in this directory deleted.

R=ken2
CC=golang-dev
https://golang.org/cl/4601049

After allocparams and walk, remove unused auto variables
and re-layout the remaining in reverse alignment order.

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

5a: add SQRTF and SQRTD
5l: add ASQRTF and ASQRTD

Use ARMv7 VFP VSQRT instruction to speed up math.Sqrt

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

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

check memory overlap

R=rsc, r, ken, edsrzf
CC=golang-dev
https://golang.org/cl/4602047

R=ken2
CC=golang-dev
https://golang.org/cl/4572052

Formality rejected.

R=jeff
CC=golang-dev
https://golang.org/cl/4591057

Fixes #1912.

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

Supports ISO-8859-1 and UTF-8.

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

This happens to speed up the decoder benchmarks by 50% on my computer
(GOARCH=amd64 GOOS=linux), but I don't have a good intuition as to why.
For example, just adding an unused [4096]byte field to the decoder
struct doesn't significantly change the numbers.

Before:

lzw.BenchmarkDecoder1e4	    5000	    488057 ns/op	  20.49 MB/s
lzw.BenchmarkDecoder1e5	     500	   4613638 ns/op	  21.67 MB/s
lzw.BenchmarkDecoder1e6	      50	  45672260 ns/op	  21.90 MB/s
lzw.BenchmarkEncoder1e4	    5000	    353563 ns/op	  28.28 MB/s
lzw.BenchmarkEncoder1e5	     500	   3431618 ns/op	  29.14 MB/s
lzw.BenchmarkEncoder1e6	      50	  34009640 ns/op	  29.40 MB/s

After:

lzw.BenchmarkDecoder1e4	    5000	    339725 ns/op	  29.44 MB/s
lzw.BenchmarkDecoder1e5	     500	   3166894 ns/op	  31.58 MB/s
lzw.BenchmarkDecoder1e6	      50	  31317260 ns/op	  31.93 MB/s
lzw.BenchmarkEncoder1e4	    5000	    354909 ns/op	  28.18 MB/s
lzw.BenchmarkEncoder1e5	     500	   3432710 ns/op	  29.13 MB/s
lzw.BenchmarkEncoder1e6	      50	  34010500 ns/op	  29.40 MB/s

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

Via Russ Ross' bug report on golang-nuts, it was not possible
to send an HTTP request with a zero length body with either a
Content-Length (it was stripped) or chunking (it wasn't set).

This means Go couldn't upload 0-length objects to Amazon S3.
(which aren't as silly as they might sound, as S3 objects can
have key/values associated with them, set in the headers)

Amazon further doesn't supported chunked uploads. (not Go's
problem, but we should be able to let users set an explicit
Content-Length, even if it's zero.)

To fix the ambiguity of an explicit zero Content-Length and
the Request struct's default zero value, users need to
explicit set TransferEncoding to []string{"identity"} to force
the Request.Write to include a Content-Length: 0.  identity is
in RFC 2616 but is ignored pretty much everywhere.  We don't
even then serialize it on the wire, since it's kinda useless,
except as an internal sentinel value.

The "identity" value is then documented, but most users can
ignore that because NewRequest now sets that.

And adds more tests.

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

This replaces most the map[string][]string usage with
a new Values type name, with the usual methods.

It also changes client.PostForm to take a Values, rather
than a map[string]string, closing a TODO in the code.

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

(TODO: should replace this with a Go program, eventually)

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

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

- Added some additional examples.
- 6g appears to implement this semantics already.

Fixes #658.

R=rsc, r, iant, ken
CC=golang-dev
https://golang.org/cl/4538119

Apply analogous changes in godoc/spec.go.

Fixes #1829.

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

Fixes #1926.

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

R=mirtchovski, ality, taruti, rsc
CC=golang-dev
https://golang.org/cl/4386046

This change was adapted from gccgo's libgo/runtime/mem.c at
Ian Taylor's suggestion.  It fixes all.bash failing with
"address space conflict: map() =" on amd64 Linux with kernel
version 2.6.32.8-grsec-2.1.14-modsign-xeon-64.
With this change, SysMap will use MAP_FIXED to allocate its desired
address space, after first calling mincore to check that there is
nothing else mapped there.

R=iant, dave, n13m3y3r, rsc
CC=golang-dev
https://golang.org/cl/4438091

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

Also remove an obsolete TODO while I'm here.

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

Tested on clang 2.9/amd64

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

Three optimizations: First, special-case power of two bases
that partion a Word(), bases 2, 4, 16, and 256. These can
be moved directly from internal Word() storage to the output
without multiprecision operations. Next, same approach for
the other power-of-two bases, 8, 32, 64, and 128. These
don't fill a Word() evenly, so special handling is needed
for those cases where input spans the high-bits of one Word
and the low bis of the next one.  Finally, implement the
general case for others bases in 2 <= base <= 256 using
superbases, the largest power of base representable in a
Word(). For base ten, this is 9 digits and a superbase of
10^9 for 32-bit Words and 19 digits and 10^19 for 64-bit
compiles. This way we do just 1/9th or 1/19th of the expensive
multiprecision divisions, unpacking superdigits using fast
native machine arithmetic. The resulting code runs 7x to
800x the speed of the previous approach, depending on the
length of the number to be converted--longer is relatively
faster.

Also, extended the tests and benchmarks for string to nat
(scan()) and nat to string (string()) functions. A further
enhancement awaits the next CL to make general cases about
7x faster for long cases.

R=gri
CC=golang-dev
https://golang.org/cl/4595041

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

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