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

`godoc net/http` used to complain "/target contains more than one package: http, main"

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

also fix an annoying test that relies on $GOROOT be set.
Fixes #3690.

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

64bit atomics are broken on 32bit systems. This is issue 599.

linux/arm builders all broke with this change, I am concerned that the other 32bit builders are silently impacted.

««« original CL description
net: fix data races on deadline vars

Fixes #4434.

R=mikioh.mikioh, bradfitz, dvyukov, alex.brainman
CC=golang-dev
https://golang.org/cl/6855110
»»»

R=rsc, mikioh.mikioh, dvyukov, minux.ma
CC=golang-dev
https://golang.org/cl/6852105

Fixes #4434.

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

When a race happens inside of runtime (chan, slice, etc),
currently reports contain only user file:line.
If the line contains a complex expression,
it's difficult to figure out where the race exactly.
This change adds one more top frame with exact
runtime function (e.g. runtime.chansend, runtime.mapaccess).

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

W/o this change stack traces do not show from where sync.Once()
or atomic.XXX was called.
This change add funcenter/exit instrumentation to sync/sync.atomic
packages.

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

Some have their system setup in a particular way,
see http://golang.org/issue/4444#c3.

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

RFC 2616: "The 204 response MUST NOT include a message-body,
and thus is always terminated by the first empty line after
the header fields."

Previously we'd trigger chunked encoding by default on
responses, and then when finishing the request we'd write the
chunk trailers, which counted as a message-body.

Fixes #4454

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

Fixes #4450.

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

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

1) Built-ins are restricted like for expression statements.
   This documents the status quo.

2) Calls cannot be parenthesized. The spec is not clear. gccgo
   permits it already, gc doesn't. Be explicit in the spec.

 Fixes #4462.

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