Gccgo creates a struct to hold the arguments for the deferred
function.  In this example the struct holds a type defined in a
different package.  The bug was that gccgo tried to create an equality
function for this struct, and it implemented that function by calling
the equality function for the type defined in the other package.
Since that type is not exported, the reference to the equality
function failed at link time.  Normally it is impossible for a struct
to directly contain a member that is an unexported type from another
package, but in this specific case it was possible.  Fixed in gccgo
with https://codereview.appspot.com/183500043 .

Change-Id: I8ec3a33631225b9ac2a4ac060cb4d10b4635e60b
Reviewed-on: https://go-review.googlesource.com/1690Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>

Previously, this code generated bogus section indexes for dynamic
symbols.  It turns out this didn't matter, since we only emit these
when generating an executable and in an executable it only matters
whether a symbol is defined or undefined, but it leads to perplexing
code full of mysterious constants.

Unfortunately, this happens too early to put in real section indexes,
so just use section index 1 to distinguish the symbol from an
undefined symbol.

Change-Id: I0e514604bf31f21683598ebd3e020b66acf767ef
Reviewed-on: https://go-review.googlesource.com/1720Reviewed-by: Russ Cox <rsc@golang.org>

This will be used by ppc64 to add call stubs to the .text section.
ARM needs a similar pass to generate veneers for arm->thumb
transitions.

Change-Id: Iaee74036e60643a56fab15b564718f359c5910eb
Reviewed-on: https://go-review.googlesource.com/2004Reviewed-by: Russ Cox <rsc@golang.org>

Disabled by default, but invaluable when you need it.

Change-Id: If4a75d11d14f70b6840d339aaec4b940dc406493
Reviewed-on: https://go-review.googlesource.com/2012Reviewed-by: Russ Cox <rsc@golang.org>

* bug248, bug345, bug369, and bug429 were ported from bash commands to run scripts. bug369 remains disabled.
* bug395 is a test for issue 1909, which is still open. It is marked as skip now and will be usable with compile with run.go when issue 1909 is fixed.

Fixes #4139

Updates #1909

Change-Id: Ibb5fbfb5cf72ddc285829245318eeacd3fb5a636
Reviewed-on: https://go-review.googlesource.com/1774Reviewed-by: Russ Cox <rsc@golang.org>

Change-Id: Ie5a36dbcd809fc165f4198d47641d5a95878460c
Reviewed-on: https://go-review.googlesource.com/2000Reviewed-by: Russ Cox <rsc@golang.org>

For arm and powerpc, as well as x86 without aes instructions.
Contains a mixture of ideas from cityhash and xxhash.

Compared to our old fallback on ARM, it's ~no slower on
small objects and up to ~50% faster on large objects.  More
importantly, it is a much better hash function and thus has
less chance of bad behavior.

Fixes #8737

benchmark                         old ns/op     new ns/op     delta
BenchmarkHash5                    173           181           +4.62%
BenchmarkHash16                   252           212           -15.87%
BenchmarkHash64                   575           419           -27.13%
BenchmarkHash1024                 7173          3995          -44.31%
BenchmarkHash65536                516940        313173        -39.42%
BenchmarkHashStringSpeed          300           279           -7.00%
BenchmarkHashBytesSpeed           478           424           -11.30%
BenchmarkHashInt32Speed           217           207           -4.61%
BenchmarkHashInt64Speed           262           231           -11.83%
BenchmarkHashStringArraySpeed     609           631           +3.61%

Change-Id: I0a9335028f32b10ad484966e3019987973afd3eb
Reviewed-on: https://go-review.googlesource.com/1360Reviewed-by: Russ Cox <rsc@golang.org>

Pointers to zero-sized values may end up pointing to the next
object in memory, and possibly off the end of a span.  This
can cause memory leaks and/or confuse the garbage collector.

By putting the overflow pointer at the end of the bucket, we
make sure that pointers to any zero-sized keys or values don't
accidentally point to the next object in memory.

fixes #9384

Change-Id: I5d434df176984cb0210b4d0195dd106d6eb28f73
Reviewed-on: https://go-review.googlesource.com/1869Reviewed-by: Russ Cox <rsc@golang.org>

Change-Id: I3b81f2e9eb29ee6349d758b68fe7951b34f15a81
Reviewed-on: https://go-review.googlesource.com/1974Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: Icba46194bcbfd86b512eef2599242c715ad4e7d3
Reviewed-on: https://go-review.googlesource.com/2041Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

Fixes #9409

Change-Id: I2404cd8bf3ebb07f4b6a2b3e1d58ab69b9f1e8d8
Reviewed-on: https://go-review.googlesource.com/2040Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

Handles the case where the parent is pid 1 (common in docker
containers).

Attempted and failed to write a test for this.

Fixes #9263.

Change-Id: I5c6036446c99e66259a4fab1660b6a594f875020
Reviewed-on: https://go-review.googlesource.com/1372Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

Move the symMerge recursion stopping condition
from the beginning of symMerge to the callers.

This halves the number of calls to symMerge
while running 'go test sort'.

benchmark                   old ns/op      new ns/op      delta
BenchmarkStable1e6          8358117060     7954143849     -4.83%
BenchmarkStable1e4          40116117       38583285       -3.82%
BenchmarkStableInt1K        119150         115182         -3.33%
BenchmarkStableInt64K       9799845        9515475        -2.90%
BenchmarkStableString1K     388901         393516         +1.19%
BenchmarkStable1e2          124917         123618         -1.04%

Change-Id: I7ba2ca277f213b076fe6830e1139edb47ac53800
Reviewed-on: https://go-review.googlesource.com/1820Reviewed-by: Robert Griesemer <gri@golang.org>

intDataSize ignores unsigned integers, forcing reads/writes to miss the fast path.

Fixes #8956

Change-Id: Ie79b565b037db3c469aa1dc6d0a8a5a9252d5f0a
Reviewed-on: https://go-review.googlesource.com/1777Reviewed-by: Russ Cox <rsc@golang.org>

Change-Id: I15269722ca3d2654a9dd7a3f8a89ad375dc9bee0
Reviewed-on: https://go-review.googlesource.com/1759Reviewed-by: Russ Cox <rsc@golang.org>

Fixes #9407

Change-Id: I765e8009c7ee22473ac8c2d81c7f6c8ec9866c51
Reviewed-on: https://go-review.googlesource.com/1980Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

Change-Id: Iea08b8f4e74a8cd4b4d317273046457c8db956a1
Reviewed-on: https://go-review.googlesource.com/1640Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

This was a copy-paste error from 9l.  Besides incorrectly referring to
cnames9, 6l doesn't even use a->class, so simply remove this.

Fixes #9320

Change-Id: I0e3440c9dae1c3408eb795b3645f9f1dd8f50aed
Reviewed-on: https://go-review.googlesource.com/1516Reviewed-by: Russ Cox <rsc@golang.org>

Fixes #9418

Change-Id: I044fa1d26d972f012f00388a84c4d0f143cf4f63
Reviewed-on: https://go-review.googlesource.com/1970Reviewed-by: Robert Griesemer <gri@golang.org>

Change-Id: I04d2e83f86f021464190f0b0fe0e450cb4662ad9
Reviewed-on: https://go-review.googlesource.com/1971Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

Some applications use unpadded base64 format, omitting the trailing
'=' padding characters from the standard base64 format, either to
minimize size or (more justifiably) to avoid use of the '=' character.
Unpadded flavors are standard and documented in section 3.2 of RFC 4648.

To support these unpadded flavors, this change adds two predefined
encoding variables, RawStdEncoding and RawURLEncoding, for unpadded
encodings using the standard and URL character set, respectively.
The change also adds a function WithPadding() to customize the padding
character or disable padding in a custom Encoding.

Finally, I noticed that the existing base64 test-suite was only
exercising the StdEncoding, and not referencing URLEncoding at all.
This change adds test-suite functionality to exercise all four encodings
(the two existing ones and the two new unpadded flavors),
although it still doesn't run *every* test on all four encodings.

Naming: I used the "Raw" prefix because it's more concise than "Unpadded"
and seemed just as expressive, but I have no strong preferences here.
Another short alternative prefix would be "Min" ("minimal" encoding).

Change-Id: Ic0423e02589b39a6b2bb7d0763bd073fd244f469
Reviewed-on: https://go-review.googlesource.com/1511Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Couldn't handle a hex string terminated by anything
other than spaces. Easy to fix.

Fixes #9124.

Change-Id: I18f89a0bd99a105c9110e1ede641873bf9daf3af
Reviewed-on: https://go-review.googlesource.com/1538Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Fixes #9188

Change-Id: Ifbf5d9fa78a4f4ceb7f92d42494fe37fa7878c45
Reviewed-on: https://go-review.googlesource.com/1930Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Check for Set error when a boolean flag isn't explicitly given a value.

Fixes #9345

Change-Id: I97a1289f8cf27567d1a726ebe5ef167c800f357c
Reviewed-on: https://go-review.googlesource.com/1897Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

benchmark           old MB/s     new MB/s     speedup
BenchmarkEncode     243.20       279.89       1.15x

benchmark           old allocs     new allocs     delta
BenchmarkEncode     1370           4              -99.71%

Change-Id: I3920bcc04b6dd89efa5da89db5594d4434426d74
Reviewed-on: https://go-review.googlesource.com/1924Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Make golint a bit happier

Change-Id: I8a14342f3e492e92bf5efa611f9ef91176624031
Reviewed-on: https://go-review.googlesource.com/1891Reviewed-by: Minux Ma <minux@golang.org>

Given a file of size N, a request for "Range: bytes=N-*" should
return a 416 [1].  Currently, it returns a 206 and a body of 0
bytes, with the illegal Content-Range of "bytes N-(N-1)/N" [2].

[1]: RFC 7233, sec 2.1: "If a valid byte-range-set includes at least one
byte-range-spec with a first-byte-pos that is less than the current
length of the representation, [...]".  sec 3.1: "If all of the
preconditions are true, the server supports the Range header field for
the target resource, and the specified range(s) are invalid or
unsatisfiable, the server SHOULD send a 416 (Range Not Satisfiable)
response."

[2]: RFC 7233, sec 4.2: "A Content-Range field value is invalid if it
contains a byte-range-resp that has a last-byte-pos value less than its
first-byte-pos value, [...]"

Fixes #8988

Change-Id: If3e1134e7815f5d361efea01873b29aafe3de817
Reviewed-on: https://go-review.googlesource.com/1862Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

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/1590Reviewed-by: Anthony Martin <ality@pbrane.org>
Reviewed-by: David du Colombier <0intro@gmail.com>
Reviewed-by: Aram Hăvărneanu <aram@mgk.ro>

Fixes #9177

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

Co-hacking with Dave Cheney.

Fixes #9405

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

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/1904Reviewed-by: Minux Ma <minux@golang.org>

Change-Id: I6be5f610af5c56131a9d887569919372bab1d02c
Reviewed-on: https://go-review.googlesource.com/1903Reviewed-by: Minux Ma <minux@golang.org>

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/1901Reviewed-by: Minux Ma <minux@golang.org>

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/1902Reviewed-by: Minux Ma <minux@golang.org>

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/1821Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

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

"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/1830Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

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

replacement for CL 180640043

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

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