Also fixes a necessary TODO in the process.

Fixes #4126

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

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

The fixjmp step eliminates redundant chains of JMP
instructions that are produced by the compiler during
code generation.

It is already implemented in gc, and can be adapted to 6c/8c with
the exception that JMPs refer to destination by pc instead of by
pointer. The algorithm is modified to operate on Regs instead of Progs
for this reason. The pcs are already restored later by regopt.

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

Add missing file that should have been included in CL 6854063 / 5eac1a2d6fc3

R=remyoudompheng, minux.ma, rsc
CC=golang-dev
https://golang.org/cl/6891049

The 0-length part is fine, but some callers that write 0 bytes
also pass nil as the data pointer, and the Plan 9 kernel kills the
process with 'invalid address in sys call' in that case.

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

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

Fixes #2458.

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

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

Fixes #2510

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

Per the curl man page, the http_proxy configuration can be
of the form:

   [protocol://]<host>[:port]

And we had a test that <ip>:<port> worked, but if
the host began with a letter, url.Parse parsed the hostname
as the scheme instead, confusing ProxyFromEnvironment.

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

Used to say:

issue4251.go:12: inverted slice range
issue4251.go:12: constant -1 overflows uint64
issue4251.go:16: inverted slice range
issue4251.go:16: constant -1 overflows uint64
issue4251.go:20: inverted slice range
issue4251.go:20: constant -1 overflows uint64

With this patch, only gives the "inverted slice range" errors.

R=golang-dev, daniel.morsing
CC=golang-dev
https://golang.org/cl/6871058

Fixes #4396.

For fixed arrays larger than the unmapped page, agenr would general a nil check by loading the first word of the array. However there is no requirement for the first element of a byte array to be word aligned, so this check causes a trap on ARMv5 hardware (ARMv6 since relaxed that restriction, but it probably still comes at a cost).

Switching the check to MOVB ensures alignment is not an issue. This check is only invoked in a few places in the code where large fixed arrays are embedded into structs, compress/lzw is the biggest offender, and switching to MOVB has no observable performance penalty.

Thanks to Rémy and Daniel Morsing for helping me debug this on IRC last night.

R=remyoudompheng, minux.ma, rsc
CC=golang-dev
https://golang.org/cl/6854063

Fixes #4434.

This proposal replaces the previous CL 6855110. Due to issue 599, 64-bit atomic operations should probably be avoided, so use a sync.Mutex instead.

Benchmark comparisons against 025b9d070a85 on linux/386:

CL 6855110:

benchmark                        old ns/op    new ns/op    delta
BenchmarkTCPOneShot                 710024       727409   +2.45%
BenchmarkTCPOneShotTimeout          758178       768620   +1.38%
BenchmarkTCPPersistent              223464       228058   +2.06%
BenchmarkTCPPersistentTimeout       234494       242600   +3.46%

This proposal:

benchmark                        old ns/op    new ns/op    delta
BenchmarkTCPOneShot                 710024       718492   +1.19%
BenchmarkTCPOneShotTimeout          758178       748783   -1.24%
BenchmarkTCPPersistent              223464       227628   +1.86%
BenchmarkTCPPersistentTimeout       234494       238321   +1.63%

R=rsc, dvyukov, mikioh.mikioh, alex.brainman, bradfitz
CC=golang-dev, remyoudompheng
https://golang.org/cl/6866050

R=dave, mikioh.mikioh
CC=golang-dev
https://golang.org/cl/6873046

Fixes #4281

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

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

The current spec says that when calling make, if both len and
cap are constant, it is an error if len > cap.  The gc
compiler does not yet implement that, but when it does this
will need to change.  Changing it now for the benefit of
gccgo.

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

Using append simplifies the code and makes it work if
the initial capacity of the slice is smaller than the
number of items pushed.

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

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

Also: fix an incorrect link.

Fixes #4479.
Fixes #4456.

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

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

Fixes #4172

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

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

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

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

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

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

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

Also:
- 'for' statements with a range clause do not accept send-only
   channels
- '_, _ = range ch' is not equivalent to "_ = range ch" if ch
   is a channel (rewriting the latter to the former leads to
   an invalid range clause).

These clarifications document the status quo.

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

The debian/kFreeBSD project uses the FreeBSD kernel and the debian userspace. From our point of view, this is freebsd not linux as GOOS talks about the kernel syscall interface, not the userspace (although cgo alters that). As debian/kFreeBSD is experimental at this time, I do not think it is worth the effort of duplicating all the freebsd specific code so this is proposal represents a reasonable workaround.

Currently cgo is not supported, make.bash will detect this and disable cgo automatically during the build.

dfc@debian:~/go/src$ uname -a
GNU/kFreeBSD debian 8.1-1-686 #0 Sat Jul 21 17:02:04 UTC 2012 i686 i386 Intel(R) Core(TM) i5-2415M CPU @ 2.30GHz GNU/kFreeBSD
dfc@debian:~/go/src$ ../bin/go version
go version devel +d05272f402ec Sat Dec 01 15:15:14 2012 -0800

Tested with GOOS=freebsd GOARCH=386

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

Twice faster and twice less garbage.

R=golang-dev, dave, daniel.morsing, bradfitz
CC=golang-dev
https://golang.org/cl/6849128

The compiler was confused when inlining a T.Method(f()) call
where f returns multiple values: support for this was marked
as TODO.

Variadic calls are not supported but are not inlined either.
Add a test preventively for that case.

Fixes #4167.

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

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

Exactly how I find minute details like this is beyond me.

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

The first iteration always do `m[0], m[0] = m[0], m[0]`, because
`rand.Intn(1)` is 0.

fun note: IIRC in TAOCP version of this algorithm, `i` goes
backward (n-1->1), meaning that the "already" shuffled part of the
array is never altered betweens iterations, while in the current
implementation the "not-yet" shuffled part of the array is
conserved between iterations.

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

Worked in Go 1, broken in f440e65f93fe.

Fixes #4477

R=golang-dev, agl
CC=golang-dev
https://golang.org/cl/6865043

Contention profile in BenchmarkTCPOneShot (Core 2 Quad):

Before
Total: 80.285 seconds
44.743  55.7%  55.7%   44.743  55.7% runtime.chanrecv1
31.995  39.9%  95.6%   31.995  39.9% sync.(*Mutex).Lock
 3.547   4.4% 100.0%    3.547   4.4% runtime.chansend1

After
Total: 48.341 seconds
45.810  94.8%  94.8%   45.810  94.8% runtime.chanrecv1
 2.530   5.2% 100.0%    2.530   5.2% runtime.chansend1
 0.001   0.0% 100.0%    0.001   0.0% sync.(*Mutex).Lock

R=golang-dev, dave, mikioh.mikioh
CC=golang-dev
https://golang.org/cl/6845119

Also fixes comments on ResolveIPAddr.

Fixes #4476.

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

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

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