This is a redo of CL 41076 backported to the 1.8 release branch.
There were major conflicts, so I had to basically rewrite it again
from scratch.  The way Progs are allocated changed.  Liveness analysis
and Prog generation got reordered.  Liveness analysis changed from
running on gc.BasicBlock to ssa.Block.  All that makes the logic quite
a bit different.

Please review carefully.

From CL 41076:

At VARKILLs, zero a variable if it is ambiguously live.
After the VARKILL anything this variable references
might be collected. If it were to become live again later,
the GC will see references to already-collected objects.

We don't know a variable is ambiguously live until very
late in compilation (after lowering, register allocation, ...),
so it is hard to generate the code in an arch-independent way.
We also have to be careful not to clobber any registers.
Fortunately, this almost never happens so performance is ~irrelevant.

There are only 2 instances where this triggers in the stdlib.

Fixes #20029

Change-Id: Ibb757eec58ee07f40df5e561b19d315684dc4bda
Reviewed-on: https://go-review.googlesource.com/43998
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

Commit 4dcba023 replaced select with pselect6 on linux/amd64 and
linux/arm, but it turns out the Android emulator uses linux/386. This
makes the equivalent change there, too.

Fixes #20409 more.

Change-Id: If542d6ade06309aab8758d5f5f6edec201ca7670
Reviewed-on: https://go-review.googlesource.com/44011
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit ecad34a40ea390ddf5ba2da8f3c3f2c5f15297c8)
Reviewed-on: https://go-review.googlesource.com/44002
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Chris Broadfoot <cbro@golang.org>

Android O black-lists the select system call because its libc, Bionic,
does not use this system call. Replace our use of select with pselect6
(which is allowed) on the platforms that support targeting Android.
linux/arm64 already uses pselect6 because there is no select on arm64,
so only linux/amd64 and linux/arm need changing. pselect6 has been
available since Linux 2.6.16, which is before Go's minimum
requirement.

Fixes #20409.

Change-Id: Ic526b5b259a9e01d2f145a1f4d2e76e8c49ce809
Reviewed-on: https://go-review.googlesource.com/43641
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit 4dcba023)
Reviewed-on: https://go-review.googlesource.com/44001
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Chris Broadfoot <cbro@golang.org>

Fixes #20097

Change-Id: I3c9626ccc8cd0c46a7081ea8650b2ff07a5d4fcd
Reviewed-on: https://go-review.googlesource.com/41505
Run-TryBot: Todd Neal <todd@tneal.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-on: https://go-review.googlesource.com/43997
Run-TryBot: Chris Broadfoot <cbro@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

[release-branch.go1.8] net/http: update bundled http2 for gracefulShutdownCh lock contention slowdown

This updates the bundled x/net/http2 repo to git rev 186fd3fc (from
the net repo's release-branch.go1.8) for:

    [release-branch.go1.8] http2: fix lock contention slowdown due to gracefulShutdownCh
    https://golang.org/cl/43459

Fixes #20302

Change-Id: Ia01a44c6749292de9c16ca330bdebe1e52458b18
Reviewed-on: https://go-review.googlesource.com/43996
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Chris Broadfoot <cbro@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

On s390x unsigned integer comparisons with immediates require the immediate
to be an unsigned 32-bit integer. The rule was checking that the immediate
was a signed 32-bit integer.

This CL also adds a test for comparisons that could be turned into compare
with immediate or equivalent instructions (depending on architecture and
optimizations applied).

Cherry-pick of CL 40433 and CL 40873.

Fixes #19940.

Reviewed-on: https://go-review.googlesource.com/40931Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

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

Backport of CL 38072

Fixes #14705

Reviewed-on: https://go-review.googlesource.com/42500
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

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

Cherry-pick of CL 43870.

If mheap.sysAlloc doesn't have room in the heap arena for an
allocation, it will attempt to map more address space with sysReserve.
sysReserve is given a hint, but can return any unused address range.
Currently, mheap.sysAlloc incorrectly assumes the returned region will
never fall between arena_start and arena_used. If it does,
mheap.sysAlloc will blindly accept the new region as the new
arena_used and arena_end, causing these to decrease and make it so any
Go heap above the new arena_used is no longer considered part of the
Go heap. This assumption *used to be* safe because we had all memory
between arena_start and arena_used mapped, but when we switched to an
arena_start of 0 on 32-bit, it became no longer safe.

Most likely, we've only recently seen this bug occur because we
usually start arena_used just above the binary, which is low in the
address space. Hence, the kernel is very unlikely to give us a region
before arena_used.

Since mheap.sysAlloc is a linear allocator, there's not much we can do
to handle this well. Hence, we fix this problem by simply rejecting
the new region if it isn't after arena_end. In this case, we'll take
the fall-back path and mmap a small region at any address just for the
requested memory.

Fixes #20259.

Change-Id: Ib72e8cd621545002d595c7cade1e817cfe3e5b1e
Reviewed-on: https://go-review.googlesource.com/43954
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Chris Broadfoot <cbro@golang.org>

Cherry-pick of CL 43294.

Tuple ops are weird. They are essentially a pair of ops,
one which consumes a mem and one which generates a mem (the Select1).
The schedule pass didn't handle these quite right.

Fix the scheduler to include both parts of the paired op in
the store chain. That makes sure that loads are correctly ordered
with respect to the first of the pair.

Add a check for the ssacheck builder, that there is only one
live store at a time. I thought we already had such a check, but
apparently not...

Fixes #20335

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

Cherry-pick of CL 43311.

runtime.gchelper depends on the non-atomic load of work.ndone
happening strictly before the atomic add of work.nwait. Until very
recently (commit 978af9c2, fixing #20334), the compiler reordered
these operations. This created a race since work.ndone can change as
soon as work.nwait is equal to work.ndone. If that happened, more than
one gchelper could attempt to wake up the work.alldone note, causing a
"double wakeup" panic.

This was fixed in the compiler, but to make this code less subtle,
make the load of work.ndone atomic. This clearly forces the order of
these operations, ensuring the race doesn't happen.

Fixes #19305 (though really 978af9c2 fixed it).

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

Applies https://golang.org/cl/42139 to the go1.8 release branch.

Also correct two minor issues detected with go vet.

Fixes #20217

Change-Id: I2c41af9497493598fbcfc140439b4e25b9bb7e72
Reviewed-on: https://go-review.googlesource.com/42532
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Chris Broadfoot <cbro@golang.org>

Cherry-pick of CL 43310.

This adds debugging information when we panic with "heapBitsForSpan:
base out of range".

Updates #20259.

Change-Id: I0dc1a106aa9e9531051c7d08867ace5ef230eb3f
Reviewed-on: https://go-review.googlesource.com/43410
Run-TryBot: Austin Clements <austin@google.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

It was removed in CL 27325.

Fixes #20431

Change-Id: I6842851444186e19029d040f61fdf4f87a3103a6
Reviewed-on: https://go-review.googlesource.com/43771Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit deebd8fe273df2de2d590ee41ae1155c521219e9)
Reviewed-on: https://go-review.googlesource.com/43772Reviewed-by: Chris Broadfoot <cbro@golang.org>

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

Change-Id: I2ed2e8c4890a65288cf3066ebe3c1d9a16fb4c05
Reviewed-on: https://go-review.googlesource.com/43990Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-on: https://go-review.googlesource.com/43993Reviewed-by: Chris Broadfoot <cbro@golang.org>

Patch from Vlad Krasnov and confirmed to be under CLA.

Fixes #20040.

Change-Id: Ieb8436c4dcb6669a1620f1e0d257efd047b1b87c
Reviewed-on: https://go-review.googlesource.com/41070
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 9294fa27)
Reviewed-on: https://go-review.googlesource.com/43770
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Chris Broadfoot <cbro@golang.org>

Change-Id: I9282c1907204ec5c6363de84faec222a38300c9f
Reviewed-on: https://go-review.googlesource.com/39919Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-on: https://go-review.googlesource.com/39921Reviewed-by: Chris Broadfoot <cbro@golang.org>

This was fixed in CL 37598 but the test was (rightly) dropped
because it modified $GOROOT. Here's a variant that does not.

For #19151.

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

Manual port of CL 37598 (submitted for Go 1.9) to Go 1.8.1.

Fixes #19133.
Fixes #19151.

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

The uintptr-typed Data field in reflect.SliceHeader and
reflect.StringHeader needs special treatment because it is
really a pointer.  Add the special treatment in walk for
bug #19168 to escape analysis.

Includes extra debugging that was helpful.

Fixes #19743.

Change-Id: I6dab5002f0d436c3b2a7cdc0156e4fc48a43d6fe
Reviewed-on: https://go-review.googlesource.com/39616
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>

Fixes #19168.

(*state).insertWBstore needed to be tweaked for backporting so that
store reflect.{Slice,String}Header.Data stores still fallthrough and
end the SSA block. This wasn't necessary at master because of CL
36834.

Change-Id: I3f4fcc0b189c53819ac29ef8de86fdad76a17488
Reviewed-on: https://go-review.googlesource.com/39615
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Austin Clements <austin@google.com>

While we're here, fix a Skip/Skipf error I noticed.

Fixes #19796.

(This fixes failures on the release branch introduced by cherry-pick
CL 39605.)

Change-Id: I59b1f5b5ea727fc314acfee8445b3de0b5af1e46
Reviewed-on: https://go-review.googlesource.com/39612
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

TestDWARF has been added in CL 38855. This test is
failing on Plan 9 because executables don't have
a DWARF symbol table.

Fixes #19793.

(This fixes Plan 9 failures on the release branch introduced by
cherry-pick CL 39605.)

Change-Id: I7fc547a7c877b58cc4ff6b4eb5b14852e8b4668b
Reviewed-on: https://go-review.googlesource.com/39611
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Consider this struct, which expects an attribute A and a child C both ints:

    type X struct {
        XMLName xml.Name `xml:"X"`
        A       int      `xml:",attr"`
        C       int
    }

Go 1.2 through Go 1.7 were consistent: attributes unchecked,
children strictly checked:

    $ go1.7 run /tmp/x.go
    <X></X>              ok
    <X A=""></X>         ok
    <X A="bad"></X>      ok
    <X></X>              ok
    <X><C></C></X>       ERROR strconv.ParseInt: parsing "": invalid syntax
    <X><C/></X>          ERROR strconv.ParseInt: parsing "": invalid syntax
    <X><C>bad</C></X>    ERROR strconv.ParseInt: parsing "bad": invalid syntax
    $

Go 1.8 made attributes strictly checked, matching children:

    $ go1.8 run /tmp/x.go
    <X></X>              ok
    <X A=""></X>         ERROR strconv.ParseInt: parsing "": invalid syntax
    <X A="bad"></X>      ERROR strconv.ParseInt: parsing "bad": invalid syntax
    <X></X>              ok
    <X><C></C></X>       ERROR strconv.ParseInt: parsing "": invalid syntax
    <X><C/></X>          ERROR strconv.ParseInt: parsing "": invalid syntax
    <X><C>bad</C></X>    ERROR strconv.ParseInt: parsing "bad": invalid syntax
    $

but this broke XML code that had empty attributes (#19333).

In Go 1.9 we plan to start allowing empty children (#13417).
The fix for that will also make empty attributes work again:

    $ go run /tmp/x.go  # Go 1.9 development
    <X></X>              ok
    <X A=""></X>         ok
    <X A="bad"></X>      ERROR strconv.ParseInt: parsing "bad": invalid syntax
    <X></X>              ok
    <X><C></C></X>       ok
    <X><C/></X>          ok
    <X><C>bad</C></X>    ERROR strconv.ParseInt: parsing "bad": invalid syntax
    $

For Go 1.8.1, we want to restore the empty attribute behavior
to match Go 1.7 but not yet change the child behavior as planned for Go 1.9,
since that change hasn't been through release testing.

Instead, restore the more lax Go 1.7 behavior, so that XML files
with empty attributes will not be broken until Go 1.9:

    $ go run /tmp/x.go  # after this CL
    <X></X>              ok
    <X A=""></X>         ok
    <X A="bad"></X>      ok
    <X></X>              ok
    <X><C></C></X>       ERROR strconv.ParseInt: parsing "": invalid syntax
    <X><C/></X>          ERROR strconv.ParseInt: parsing "": invalid syntax
    <X><C>bad</C></X>    ERROR strconv.ParseInt: parsing "bad": invalid syntax
    $

Fixes #19333.

Change-Id: I3d38ebd2509f5b6ea3fd4856327f887f9a1a8085
Reviewed-on: https://go-review.googlesource.com/39607
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Sarah Adams <shadams@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

reflect.callReflect heap-allocates a stack frame and then constructs
pointers to the arguments and result areas of that frame. However, if
there are no results, the results pointer will point past the end of
the frame allocation. If there are also no arguments, the arguments
pointer will also point past the end of the frame allocation. If the
GC observes either these pointers, it may panic.

Fix this by not constructing these pointers if these areas of the
frame are empty.

This adds a test of calling no-argument/no-result methods via reflect,
since nothing in std did this before. However, it's quite difficult to
demonstrate the actual failure because it depends on both exact
allocation patterns and on GC scanning the goroutine's stack while
inside one of the typedmemmovepartial calls.

I also audited other uses of typedmemmovepartial and
memclrNoHeapPointers in reflect, since these are the most susceptible
to this. These appear to be the only two cases that can construct
out-of-bounds arguments to these functions.

Fixes #19724.
Fixes #19768 (backport).

Change-Id: I4b83c596b5625dc4ad0567b1e281bad4faef972b
Reviewed-on: https://go-review.googlesource.com/39604
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>

Right now, at least with Xcode 8.3, we invoke dsymutil and dutifully
copy what it produces back into the binary, but it has actually dropped
all the DWARF information that we wanted, because it didn't like
the look of go.o.

Make it like the look of go.o.

DWARF is tested in other ways, but typically indirectly and not for cgo programs.
Add a direct test, and one that exercises cgo.
This detects missing dwarf information in cgo-using binaries on macOS,
at least with Xcode 8.3, and possibly earlier versions as well.

Fixes #19772.

The backport to Go 1.8 disables TestDWARF on Windows because Windows
DWARF support is new in Go 1.9.

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

Without this, the load fails during kernel exec, which results in the
mysterious and completely uninformative "Killed: 9" error.

It appears that the stars (or at least the inputs) were properly aligned
with earlier versions of Xcode so that this happened accidentally.
Make it happen on purpose.

Gregory Man bisected the breakage to this change in LLVM,
which fits the theory nicely:
https://github.com/llvm-mirror/llvm/commit/9a41e59c

Fixes #19734.

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

Might as well provide a way around the mach-o munging
that doesn't require stripping all symbols.
After all, -w does mean no DWARF.

For #11887, #19734, and anyone else that needs to disable
this code path without losing the symbol table.

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

Fixes #19323
Fixes #19638 (backport)

Change-Id: I92d1bdefb15de6178a577a4fa0f0dc004f791904
Reviewed-on: https://go-review.googlesource.com/39601
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Currently, when printing tracebacks of other threads during
GOTRACEBACK=crash, if the thread is on the system stack we print only
the header for the user goroutine and fail to print its stack. This
happens because we passed the g0 to traceback instead of curg. The g0
never has anything set in its gobuf, so traceback doesn't print
anything.

Fix this by passing _g_.m.curg to traceback instead of the g0.

Fixes #19494.
Fixes #19637 (backport).

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

Change-Id: Ie52dac8eb4daed95e049ad74d5ae101e8a5cb854
Reviewed-on: https://go-review.googlesource.com/39599
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

The assembler back end uses F15 as a temporary register in these
instructions.

Checked the assembler back end and made sure that this is the
only case clobbering F15.

Fixes #19403.

Change-Id: I02b9e00fdd9229db899f501c8e9b306e02912d83
Reviewed-on: https://go-review.googlesource.com/39598
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

Removing stray xori that came from big endian copy/paste.
Adding atomicand8 check to runtime.check() that would have revealed
this error.
Might fix #19396.

Change-Id: If8d6f25d3e205496163541eb112548aa66df9c2a
Reviewed-on: https://go-review.googlesource.com/39597
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

The loop-A-encloses-loop-C code did not properly handle the
case where really C was already known to be enclosed by B,
and A was nearest-outer to B, not C.

Fixes #19217.

Change-Id: I755dd768e823cb707abdc5302fed39c11cdb34d4
Reviewed-on: https://go-review.googlesource.com/39596
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Added a flag to generic and various architectures' atomic
operations that are judged to have observable side effects
and thus cannot be dead-code-eliminated.

Test requires GOMAXPROCS > 1 without preemption in loop.

Fixes #19182.

Change-Id: Id2230031abd2cca0bbb32fd68fc8a58fb912070f
Reviewed-on: https://go-review.googlesource.com/39595
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>

This keeps the host linker from printing
ld: warning: option -s is obsolete and being ignored

Fixes #19775.

Change-Id: I18dd4e4b3f59cbf35dad770fd65e6baea5a7347f
Reviewed-on: https://go-review.googlesource.com/38851
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-on: https://go-review.googlesource.com/39606
TryBot-Result: Gobot Gobot <gobot@golang.org>

This was a subtle bug introduced in the previous release's fix for
issue 16156.

The definition of empty template was broken, causing the answer
to depend on the order of templates in the map.

Fixes #16156 (for real).
Fixes #19294.
Fixes #19204.

Change-Id: I1cd915c94534cad3116d83bd158cbc28700510b9
Reviewed-on: https://go-review.googlesource.com/38420
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-on: https://go-review.googlesource.com/39594Reviewed-by: Rob Pike <r@golang.org>

Go 1.7 and earlier rejected these images with chunkOrderError.
Go 1.8 panicked during decoding.
Go 1.9 will handle them successfully.

Make Go 1.8.1 match Go 1.7 and earlier, to remove the panic
without introducing new functionality in a minor release.

Fixes #19553.

Change-Id: I3c73a27aa3932300326273b6b563cdf606f3ab64
Reviewed-on: https://go-review.googlesource.com/39593
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

The aLongTimeAgo time value in net and net/http is used to cancel
in-flight read and writes. It was set to time.Unix(233431200, 0)
which seemed like far enough in the past.

But Raspberry Pis, lacking a real time clock, had to spoil the fun and
boot in 1970 at the Unix epoch time, breaking assumptions in net and
net/http.

So change aLongTimeAgo to time.Unix(1, 0), which seems like the
earliest safe value. I don't trust subsecond values on all operating
systems, and I don't trust the Unix zero time. The Raspberry Pis do
advance their clock at least. And the reported problem was that Hijack
on a ResponseWriter hung forever, waiting for the connection read
operation to finish. So now, even if kernel + userspace boots in under
a second (unlikely), the Hijack will just have to wait for up to a
second.

Updates #19747
Fixes #19771 (backport to Go 1.8.x)

Change-Id: Id59430de2e7b5b5117d4903a788863e9d344e53a
Reviewed-on: https://go-review.googlesource.com/38785
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
(cherry picked from commit e83fc2e44336423dab94bfe74fad4c4e6a4703b3)
Reviewed-on: https://go-review.googlesource.com/38786Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Scheduling values after calls to selectrecv,
will cause them to be executed multiple times, due to runtime.selectgo
jumping to the next instruction in the selectrecv basic block.
Prevent this by scheduling calls to selectrecv as late as possible

Fixes #19201

Change-Id: I6415792e2c465dc6d9bd6583ba1e54b107bcf5cc
Reviewed-on: https://go-review.googlesource.com/38587
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>