Issue #13248 was fixed by https://go-review.googlesource.com/#/c/16930/.
This is the corresponding test case (original offending program).

Change-Id: I7c99783db74a5422704409cea7e5073094beadd3
Reviewed-on: https://go-review.googlesource.com/16973Reviewed-by: Chris Manghane <cmang@golang.org>

Fixes #13274.
Fixes #13272.

Change-Id: Ie67a2c4671ee2b49831898fff7677cd65d780942
Reviewed-on: https://go-review.googlesource.com/16972Reviewed-by: Chris Manghane <cmang@golang.org>

Fixes #13266.

Change-Id: I31da922e0599989e52acf346374c2077b157ebb7
Reviewed-on: https://go-review.googlesource.com/16971Reviewed-by: Chris Manghane <cmang@golang.org>

Currently, if an allocation is large enough that arena_end + size
overflows (which is not hard to do on 32-bit), we go ahead and call
sysReserve with the impossible base and length and depend on this to
either directly fail because the kernel can't possibly fulfill the
requested mapping (causing mheap.sysAlloc to return nil) or to succeed
with a mapping at some other address which will then be rejected as
outside the arena.

In order to make this less subtle, less dependent on the kernel
getting all of this right, and to eliminate the hopeless system call,
add an explicit overflow check.

Updates #13143. This real issue has been fixed by 0de59c27, but this is
a belt-and-suspenders improvement on top of that. It was uncovered by
my symbolic modeling of that bug.

Change-Id: I85fa868a33286fdcc23cdd7cdf86b19abf1cb2d1
Reviewed-on: https://go-review.googlesource.com/16961
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Issue introduced by https://go-review.googlesource.com/#/c/16920/ .

TBR=rsc

Change-Id: I2a0e0c81f641f869568230837c566913f6538f37
Reviewed-on: https://go-review.googlesource.com/16990
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

mcache.tiny is in non-GC'd memory, but points to heap memory. As a
result, there may or may not be write barriers when writing to
mcache.tiny. Make it clearer that funny things are going on by making
mcache.tiny a uintptr instead of an unsafe.Pointer.

Change-Id: I732a5b7ea17162f196a9155154bbaff8d4d00eac
Reviewed-on: https://go-review.googlesource.com/16963
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

The tiny alloc cache is maintained in a pointer from non-GC'd memory
(mcache) to heap memory and hence must be handled carefully.

Currently we clear the tiny alloc cache during sweep termination and,
if it is assigned to a non-nil value during concurrent marking, we
depend on a write barrier to keep the new value alive. However, while
the compiler currently always generates this write barrier, we're
treading on thin ice because write barriers may not happen for writes
to non-heap memory (e.g., typedmemmove). Without this lucky write
barrier, the GC may free a current tiny block while it's still
reachable by the tiny allocator, leading to later memory corruption.

Change this code so that, rather than depending on the write barrier,
we simply clear the tiny cache during mark termination when we're
clearing all of the other mcaches. If the current tiny block is
reachable from regular pointers, it will be retained; if it isn't
reachable from regular pointers, it may be freed, but that's okay
because there won't be any pointers in non-GC'd memory to it.

Change-Id: I8230980d8612c35c2997b9705641a1f9f865f879
Reviewed-on: https://go-review.googlesource.com/16962
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

The user can inspect the record data to detect that the other side is
not using the TLS protocol.

This will be used by the net/http client (in a follow-on CL) to detect
when an HTTPS client is speaking to an HTTP server.

Updates #11111.

Change-Id: I872f78717aa8e8e98cebd8075436209a52039a73
Reviewed-on: https://go-review.googlesource.com/16078Reviewed-by: Adam Langley <agl@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

This simplifies covering all cases, reducing the number of branches
and making unrolling for simpler functions manageable.
This significantly improves performance of non-ASCII input.

This change will also allow addressing Issue #11733 in an efficient
manner.

RuneCountTenASCIIChars-8             13.7ns ± 4%  13.5ns ± 2%     ~     (p=0.116 n=7+8)
RuneCountTenJapaneseChars-8           153ns ± 3%    74ns ± 2%  -51.42%  (p=0.000 n=8+8)
RuneCountInStringTenASCIIChars-8     13.5ns ± 2%  12.5ns ± 3%   -7.13%  (p=0.000 n=8+7)
RuneCountInStringTenJapaneseChars-8   145ns ± 2%    68ns ± 2%  -53.21%  (p=0.000 n=8+8)
ValidTenASCIIChars-8                 14.1ns ± 3%  12.5ns ± 5%  -11.38%  (p=0.000 n=8+8)
ValidTenJapaneseChars-8               147ns ± 3%    71ns ± 4%  -51.72%  (p=0.000 n=8+8)
ValidStringTenASCIIChars-8           12.5ns ± 3%  12.3ns ± 3%     ~     (p=0.095 n=8+8)
ValidStringTenJapaneseChars-8         146ns ± 4%    70ns ± 2%  -51.62%  (p=0.000 n=8+7)
DecodeASCIIRune-8                    5.91ns ± 2%  4.83ns ± 3%  -18.28%  (p=0.001 n=7+7)
DecodeJapaneseRune-8                 12.2ns ± 7%   8.5ns ± 3%  -29.79%  (p=0.000 n=8+7)
FullASCIIRune-8                      5.95ns ± 3%  4.27ns ± 1%  -28.23%  (p=0.000 n=8+7)
FullJapaneseRune-8                   12.0ns ± 6%   4.3ns ± 3%  -64.39%  (p=0.000 n=8+8)

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

Fixes #11590.

Change-Id: I4144107334604a2cc98c7984df3b5d4cde3d30af
Reviewed-on: https://go-review.googlesource.com/16920Reviewed-by: Ian Lance Taylor <iant@golang.org>

Fixes #11699.

Change-Id: I01bf506d76260bcdf828bbde52791e328aa441a5
Reviewed-on: https://go-review.googlesource.com/16921Reviewed-by: Ian Lance Taylor <iant@golang.org>

Fixes #11359.

Change-Id: I0fdfa410939f7e42020cbb19d74a67e1cc3cd610
Reviewed-on: https://go-review.googlesource.com/16919Reviewed-by: Ian Lance Taylor <iant@golang.org>

Fixes #8999.

Change-Id: I1390605bdf908f59b596975ea51eb04bd03bbae0
Reviewed-on: https://go-review.googlesource.com/16918Reviewed-by: Ian Lance Taylor <iant@golang.org>

The change to the write barrier in https://golang.org/cl/16899 means
that the compiler now emits tests of the first field of a struct.  That
was using a register that was not used before.  This change fixes that
for amd64 by adding a special case for the first field of a struct.

Update #12416.

Change-Id: Ia57baa62cd741592fbeb9be82f1e846be73d6edd
Reviewed-on: https://go-review.googlesource.com/16933
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

If you set GODEBUG=cgocheck=2 the runtime package will use the write
barrier to detect cases where a Go program writes a Go pointer into
non-Go memory.  In conjunction with the existing cgo checks, and the
not-yet-implemented cgo check for exported functions, this should
reliably detect all cases (that do not import the unsafe package) in
which a Go pointer is incorrectly shared with C code.  This check is
optional because it turns on the write barrier at all times, which is
known to be expensive.

Update #12416.

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

The current mkdeps.bash just checks for dependencies for GOOS=windows
with the current GOARCH.  This is not always accurate as some package
imports only happen on specific GOOS/GOARCH combinations.  Check a
selected, easily changed, combination of GOOS/GOARCH values.

This generates a deps.go identical to the one in the repository today.

Fixes #13221.

Change-Id: I96d67d49c8c63641d578acedbb28be807607db65
Reviewed-on: https://go-review.googlesource.com/16882Reviewed-by: Michael Matloob <matloob@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Just like android/arm, android/arm64 refuses to execute non-PIE
binaries. In addition, starting from the M release (Marshmallow),
Android refuses to execute binaries with any text relocations
(this was just a warning in the L release). This makes "-shared"
necessary as well when building executables for Android.

Change-Id: Id8802de5be98ff472fc370f8d22ffbde316aaf1e
Reviewed-on: https://go-review.googlesource.com/16744Reviewed-by: Ian Lance Taylor <iant@golang.org>

In mheap.sysAlloc, if an allocation at arena_used would exceed
arena_end (but wouldn't yet push us past arena_start+_MaxArean32), it
trie to extend the arena reservation by another 256 MB. It extends the
arena by calling sysReserve, which, on 32-bit, calls mmap without
MAP_FIXED, which means the address is just a hint and the kernel can
put the mapping wherever it wants. In particular, mmap may choose an
address below arena_start (the kernel also chose arena_start, so there
could be lots of space below it). Currently, we don't detect this case
and, if it happens, mheap.sysAlloc will corrupt arena_end and
arena_used then return the low pointer to mheap.grow, which will crash
when it attempts to index in to h_spans with an underflowed index.

Fix this by checking not only that that p+p_size isn't too high, but
that p isn't too low.

Fixes #13143.

Change-Id: I8d0f42bd1484460282a83c6f1a6f8f0df7fb2048
Reviewed-on: https://go-review.googlesource.com/16927
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

If the area returned by sysReserve in mheap.sysAlloc is outside the
usable arena, we sysFree it. We pass a fake stat pointer to sysFree
because we haven't added the allocation to any stat at that point.
However, we pass a 0 stat, so sysFree panics when it decrements the
stat because the fake stat underflows.

Fix this by setting the fake stat to the allocation size.

Updates #13143 (this is a prerequisite to fixing that bug).

Change-Id: I61a6c9be19ac1c95863cf6a8435e19790c8bfc9a
Reviewed-on: https://go-review.googlesource.com/16926Reviewed-by: Ian Lance Taylor <iant@golang.org>

Ranging over string is much slower than using DecodeRuneInString.
See golang.org/issue/13162.

Replacing ranging over a string with the implementation of the Bytes
counterpart results in the following performance improvements:

RuneCountInStringTenASCIIChars-8     43.0ns ± 1%  16.4ns ± 2%  -61.80%  (p=0.000 n=7+8)
RuneCountInStringTenJapaneseChars-8   161ns ± 2%   154ns ± 2%   -4.58%  (p=0.000 n=8+8)
ValidStringTenASCIIChars-8           52.2ns ± 1%  13.2ns ± 1%  -74.62%  (p=0.001 n=7+7)
ValidStringTenJapaneseChars-8         173ns ± 2%   153ns ± 2%  -11.78%  (p=0.000 n=7+8)

Update golang/go#13162

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

And enable PIE in the go tool.

Change-Id: Ibb60ccfe62518cde6e33080bbc78bfcbecff6a4e
Reviewed-on: https://go-review.googlesource.com/14000Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>

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

Change-Id: I6ca9406207e40c7c2c661075ccfe57b6600235cf
Reviewed-on: https://go-review.googlesource.com/13997Reviewed-by: Ian Lance Taylor <iant@golang.org>

Fixes #9894.

Change-Id: I9c7ce771df2e2d1c99a06f800dce63c4e1875993
Reviewed-on: https://go-review.googlesource.com/16924
Run-TryBot: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>

Fixes #13215

Change-Id: I126117d42e7c1e69cbc7fad0760e225b03ed15bd
Reviewed-on: https://go-review.googlesource.com/16852Reviewed-by: Keith Randall <khr@golang.org>

golang.org/cl/16346 changed the runtime on linux/386 to invoke the vsyscall
helper via a PIC sequence (CALL 0x10(GS)) when dynamically linking. But it's
actually quite easy to make that code sequence work all the time, so do that,
and remove the ugly machinery that passed the buildmode from the go tool to the
assembly.

This means enlarging m.tls so that we can safely access 0x10(GS) (GS is set to
&m.tls + 4, so 0x10(GS) accesses m_tls[5]).

Change-Id: I1345c34029b149cb5f25320bf19a3cdd73a056fa
Reviewed-on: https://go-review.googlesource.com/16796Reviewed-by: Ian Lance Taylor <iant@golang.org>

A nosplit comment was added to reflect.typelinks accidentally in
https://golang.org/cl/98510044.  There is only one caller of
reflect.typelinks, reflect.typesByString, and that function is not
nosplit.  There is no reason for reflect.typelinks to be nosplit.

Change-Id: I0fd3cc66fafcd92643e38e53fa586d6b2f868a0a
Reviewed-on: https://go-review.googlesource.com/16932
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>

This allows slices of custom types with byte as underlying type to be
decoded, fixing a regression introduced in CL 9371.

Fixes #12921.

Change-Id: I62a715eaeaaa912b6bc599e94f9981a9ba5cb242
Reviewed-on: https://go-review.googlesource.com/16303Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Following a recent change, file builtin.go is not up-to-date.
Generate it again by running go generate.

Fixes #13203

Change-Id: Ib91c5ccc93665c043da95c7d3783ce5d94e48466
Reviewed-on: https://go-review.googlesource.com/16821Reviewed-by: Ian Lance Taylor <iant@golang.org>

It is too slow with kernel FPU emulator.

Updates #12688.

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

Change the linker to use a copy of the C compiler support library,
libgcc.a, when doing internal linking.  This will be used to satisfy any
undefined symbols referenced by host objects.

Change the dist tool to copy the support library into a new directory
tree under GOROOT/pkg/libgcc.  This ensures that libgcc is available
even when building Go programs on a system that has no C compiler.  The
C compiler is required when building the Go installation in the first
place, but is not required thereafter.

Change the go tool to not link libgcc into cgo objects.

Correct the linker handling of a weak symbol in an ELF input object to
not always create a new symbol, but to use an existing symbol if there
is one; this is necessary on freebsd-amd64, where libgcc contains a weak
definition of compilerrt_abort_impl.

Fixes #9510.

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

benchmark          old ns/op     new ns/op     delta
BenchmarkTLS-4     8571          7938          -7.39%

benchmark          old MB/s     new MB/s     speedup
BenchmarkTLS-4     119.46       128.98       1.08x

benchmark          old allocs     new allocs     delta
BenchmarkTLS-4     8              0              -100.00%

benchmark          old bytes     new bytes     delta
BenchmarkTLS-4     128           0             -100.00%

On:

func BenchmarkTLS(b *testing.B) {
        b.ReportAllocs()
        b.SetBytes(1024)
        ts := httptest.NewTLSServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
                io.Copy(ioutil.Discard, r.Body)
        }))
        defer ts.Close()
        buf := make([]byte, 1024)
        for i := range buf {
                buf[i] = byte(i)
        }
        c, err := tls.Dial("tcp", ts.Listener.Addr().String(), &tls.Config{
                InsecureSkipVerify: true,
        })
        if err != nil {
                b.Fatal(err)
        }
        defer c.Close()
        clen := int64(b.N) * 1024
        if _, err := c.Write([]byte(
            "POST / HTTP/1.1\r\nHost: foo\r\nContent-Length: " +
            fmt.Sprint(clen) + "\r\n\r\n")); err != nil {
                b.Fatal(err)
        }
        b.ResetTimer()
        for i := 0; i < b.N; i++ {
                if _, err := c.Write(buf); err != nil {
                        b.Fatal(err)
                }
        }
}

Change-Id: I206e7e2118b97148f9751b740d8470895634d3f5
Reviewed-on: https://go-review.googlesource.com/16828Reviewed-by: Adam Langley <agl@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fixes #13248.

TBR: iant

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

Fixes #11380.

Change-Id: I0a284ad2a46826ce82486479ea4e79f0f470292f
Reviewed-on: https://go-review.googlesource.com/16635Reviewed-by: Ian Lance Taylor <iant@golang.org>

Comment changes only.

Change-Id: Ib365b3cd16af9995cb0a2cce48fbe35d73899438
Reviewed-on: https://go-review.googlesource.com/16898
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Chris Manghane <cmang@golang.org>

Factored out functionality of dotname (was inlined in 3 places).

Change-Id: Ica782737c8decbb757465830b25ba87faa9115a4
Reviewed-on: https://go-review.googlesource.com/16897
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Chris Manghane <cmang@golang.org>

Inlined fntype, othertype, recvchantype, ptrtype into ntype
and simplified callers. Minor cleanups elsewhere (better names).

Change-Id: I54924969996641a802de00c078b4cd0eabfda8c1
Reviewed-on: https://go-review.googlesource.com/16894
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Chris Manghane <cmang@golang.org>

Inlined non_dcl_stmt in stmt since it was called only from there.

Change-Id: I616c41332cfd86bbf3493d0ce7b1256384215220
Reviewed-on: https://go-review.googlesource.com/16893
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Chris Manghane <cmang@golang.org>

- better error messages
- better error recovery by advancing to "follow" token after error
- make sure that we make progress after all errors
- minor cleanups

Change-Id: Ie43b8b02799618d70dc8fc227fab3e4e9e0d8e3a
Reviewed-on: https://go-review.googlesource.com/16892
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Chris Manghane <cmang@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

These now live in runtime/internal/sys.

Change-Id: I270597142516512bfc1395419e51d8083ba1663f
Reviewed-on: https://go-review.googlesource.com/16891
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>