runtime: fix a minor typo in comments

Change-Id: I13a8aacd1b8243c992b539ab6bf7b5dff2a1393a
Reviewed-on: https://go-review.googlesource.com/1757
Reviewed-by: Minux Ma <minux@golang.org>
runtime/cgo: guard against redefinition of PTHREAD_KEYS_MAX

Fixes #9374.

Change-Id: Ic53757eba98fc43bcd24e25e03876fef917b4da1
Reviewed-on: https://go-review.googlesource.com/1751
Reviewed-by: David Crawshaw <crawshaw@golang.org>
cmd/gc: resolve static addresses of the form &x.f at link time

When we do y = &x for global variables x and y, y gets initialized
at link time.  Do the same for y = &x.f if x is a struct and y=&x[5]
if x is an array.

fixes #9217
fixes #9355

Change-Id: Iea3c0ce2ce1b309e2b760e345608fd95460b5713
Reviewed-on: https://go-review.googlesource.com/1691
Reviewed-by: Minux Ma <minux@golang.org>
cmd/ld: set ELF ABI version for ppc64x

On ppc64, there are three ELF ABI versions an ELF file can request.
Previously, we used 0, which means "unspecified".  On our test
machines, this meant to use the default (v1 for big endian and v2 for
little endian), but apparently some systems can pick the wrong ABI if
neither is requested.  Leaving this as 0 also confuses libbfd, which
confuses gdb, objdump, etc.

Fix these problems by specifying ABI v1 for big endian and v2 for
little endian.

Change-Id: I4d3d5478f37f11baab3681a07daff3da55802322
Reviewed-on: https://go-review.googlesource.com/1800
Reviewed-by: Minux Ma <minux@golang.org>
liblink: fail for too-large register offset constants

Previously, liblink would silently truncate register offset constants
to 32 bits.  For example,

    MOVD $0x200000004(R2),R3

would assemble to

    addis   r31,r2,0
    addi    r3,r31,4

To fix this, limit C_LACON to 32 bit (signed) offsets and introduce a
new C_DACON operand type for larger register offsets.  We don't
implement this currently, but at least liblink will now give an error
if it encounters an address like this.

Change-Id: I8e87def8cc4cc5b75498b0fb543ac7666cf2964e
Reviewed-on: https://go-review.googlesource.com/1758
Reviewed-by: Minux Ma <minux@golang.org>
cmd/ld: add fallthrough comment

Change-Id: Ia6739c164575751a63cc0d4d41d1f6887fbbaee3
Reviewed-on: https://go-review.googlesource.com/1803
Reviewed-by: Minux Ma <minux@golang.org>
test/fixedbugs/issue9355: fix build on windows and skip on nacl

Change-Id: If367cc1e8c2d744569513bc71da6e6c454c74e9a
Signed-off-by: Shenghou Ma <minux@golang.org>
Reviewed-on: https://go-review.googlesource.com/1802
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
compress/bzip2: s/repeat_power/repeatPower/

Change-Id: I64c8c247acd5d134b2f17ed7aab0a035d7710679
Reviewed-on: https://go-review.googlesource.com/1804
Reviewed-by: Minux Ma <minux@golang.org>
runtime: use go generate for zcallback_windows.go

replacement for CL 180640043

Change-Id: I8ff36645cfcbbda338faf7b29cbfdb95c47d5ec4
Reviewed-on: https://go-review.googlesource.com/1765
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
doc: start go1.5.txt

Change-Id: I0f9cf081cb280f0a805ee7f5178a5cbed0d4ad88
Reviewed-on: https://go-review.googlesource.com/1842
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
runtime: simplify cpuprof hash calculation

"x*41" computes the same value as "x*31 + x*7 + x*3" and (when
compiled by gc) requires just one multiply instruction instead of
three.

Alternatively, the expression could be written as "(x<<2+x)<<3 + x" to
use shifts instead of multiplies (which is how GCC optimizes "x*41").
But gc currently emits suboptimal instructions for this expression
anyway (e.g., separate SHL+ADD instructions rather than LEA on
386/amd64). Also, if such an optimization was worthwhile, it would
seem better to implement it as part of gc's strength reduction logic.

Change-Id: I7156b793229d723bbc9a52aa9ed6111291335277
Reviewed-on: https://go-review.googlesource.com/1830
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
doc: fix typo in gccgo contribute

Change-Id: Ib9699fc9c45f61e9d75e9d9ae69167f039a66dfc
Reviewed-on: https://go-review.googlesource.com/1890
Reviewed-by: Minux Ma <minux@golang.org>
sort: deduplicate inner loop of Stable

benchmark                   old ns/op      new ns/op      delta
BenchmarkStableInt1K        117212         116287         -0.79%
BenchmarkStableInt64K       9632002        9587872        -0.46%
BenchmarkStable1e4          40044309       39865644       -0.45%
BenchmarkStable1e2          126985         126456         -0.42%
BenchmarkStableString1K     389774         391052         +0.33%
BenchmarkStable1e6          8183202516     8157693442     -0.31%

Change-Id: I14e518ad49ecce3d1fc2b056e1acd5e5a2de8144
Reviewed-on: https://go-review.googlesource.com/1821
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
testing: style change: omit unnecessary new

This was brought to my attention because a user thought that because
the file was named "example.go" it served as an example of good coding
practice.  It's not an example, of course, but may as well use a more
idiomatic style anyhow.

Change-Id: I7aa720f603f09f7d597fb7536dbf46ef09144e28
Reviewed-on: https://go-review.googlesource.com/1902
Reviewed-by: Minux Ma <minux@golang.org>
cmd/cgo: don't #include cgo_export.h in gccgo _cgo_main.c

Instead of relying on the asm names declared in the gccgo version of
cgo_export.h, just emit a dummy symbol with the right asm name.  This
is enough to let the _cgo_main link succeed, which is all that matters
here.

Fixes #9294.

Change-Id: I803990705b6b226ed0adf17dc57b58a9f501b213
Reviewed-on: https://go-review.googlesource.com/1901
Reviewed-by: Minux Ma <minux@golang.org>
misc/cgo/test/backdoor: add gc build tag for thunk.s

Change-Id: I6be5f610af5c56131a9d887569919372bab1d02c
Reviewed-on: https://go-review.googlesource.com/1903
Reviewed-by: Minux Ma <minux@golang.org>
misc/cgo/test: skip test7978 when using gccgo

Gccgo can only get a backtrace for the currently running thread, which
means that it can only get a backtrace for goroutines currently running
Go code.  When a goroutine is running C code, gccgo has no way to stop
it and get the backtrace.  This test is all about getting a backtrace
of goroutines running C code, so it can't work for gccgo.

Change-Id: I2dff4403841fb544da7396562ab1193875fc14c3
Reviewed-on: https://go-review.googlesource.com/1904
Reviewed-by: Minux Ma <minux@golang.org>
net/http: make Client.Timeout return net.Error errors indicating timeout

Co-hacking with Dave Cheney.

Fixes #9405

Change-Id: I14fc3b6a47dcdb5e514e93d062b804bb24e89f47
Reviewed-on: https://go-review.googlesource.com/1875
Reviewed-by: Dave Cheney <dave@cheney.net>
image/draw: fix crash in clip

Fixes #9177

Change-Id: I1c7e57f0f0a9b00fb3ddc7fa4844ac53ea6df46f
Reviewed-on: https://go-review.googlesource.com/1876
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
runtime: fix brk_ signature for plan9

with uintptr, the check for < 0 will never succeed in mem_plan9.go's
sbrk() because the brk_ syscall returns -1 on failure. fixes the plan9/amd64 build.

this failed on plan9/amd64 because of the attempt to allocate 136GB in mallocinit(),
which failed. it was just by chance that on plan9/386 allocations never failed.

Change-Id: Ia3059cf5eb752e20d9e60c9619e591b80e8fb03c
Reviewed-on: https://go-review.googlesource.com/1590
Reviewed-by: Anthony Martin <ality@pbrane.org>
Reviewed-by: David du Colombier <0intro@gmail.com>
Reviewed-by: Aram Hăvărneanu <aram@mgk.ro>