The documentation for doc says:
> Doc prints the documentation comments associated with the item identified by its
> arguments (a package, const, func, type, var, or method) followed by a one-line
> summary of each of the first-level items "under" that item (package-level
> declarations for a package, methods for a type, etc.).

Certain variables (and constants, functions, and types) have value specifications
that are multiple lines long. Prior to this change, doc would print out all of the
lines necessary to display the value. This is inconsistent with the documented
behavior, which guarantees a one-line summary for all first-level items.
We fix this here by writing a general oneLineNode method that always returns
a one-line summary (guaranteed!) of any input node.

Packages like image/color/palette and unicode now become much
more readable since large slices are now a single line.

$ go doc image/color/palette
<<<
// Before:
var Plan9 = []color.Color{
	color.RGBA{0x00, 0x00, 0x00, 0xff},
	color.RGBA{0x00, 0x00, 0x44, 0xff},
	color.RGBA{0x00, 0x00, 0x88, 0xff},
	... // Hundreds of more lines!
}
var WebSafe = []color.Color{
	color.RGBA{0x00, 0x00, 0x00, 0xff},
	color.RGBA{0x00, 0x00, 0x33, 0xff},
	color.RGBA{0x00, 0x00, 0x66, 0xff},
	... // Hundreds of more lines!
}

// After:
var Plan9 = []color.Color{ ... }
var WebSafe = []color.Color{ ... }
>>>

In order to test this, I ran `go doc` and `go doc -u` on all of the
standard library packages and diff'd the output with and without the
change to ensure that all differences were intended.

Fixes #13072

Change-Id: Ida10b7796b7e4e174a929b55c60813a9eb7158fe
Reviewed-on: https://go-review.googlesource.com/25420
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

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

For #16339

Change-Id: I8927f40e0fd166795f41c784ad92449743f73af5
Reviewed-on: https://go-review.googlesource.com/30213Reviewed-by: Matthew Dempsky <mdempsky@google.com>

For #16339.

Change-Id: Ie2e3338b87e84f45cda0868213bbcd2dae9ab6e3
Reviewed-on: https://go-review.googlesource.com/30212Reviewed-by: Matthew Dempsky <mdempsky@google.com>

For now, we also accept "type p = p.T" (using = instead of =>, for
type aliases only), so we can experiment with an approach that only
uses type aliases. This concession is implemened in the parser.

For #16339

Change-Id: I88b5522a8b6cfc2e97ca146ede8b32af340220f8
Reviewed-on: https://go-review.googlesource.com/30211Reviewed-by: Matthew Dempsky <mdempsky@google.com>

For #16339.

Change-Id: I0f83e46f13b5c8801aacf48fc8b690049edbbbff
Reviewed-on: https://go-review.googlesource.com/30210Reviewed-by: Matthew Dempsky <mdempsky@google.com>

Also add a benchmark that shows off the new behavior.  The
existing benchmarks reuse the same slice, and thus don't ever have
to clear memory.  Running the Append|Grow benchmarks in runtime:

name                              old time/op  new time/op  delta
AppendSliceLarge/1024Bytes-12      265ns ± 1%   265ns ± 3%     ~     (p=0.524 n=17+20)
AppendSliceLarge/4096Bytes-12      807ns ± 3%   772ns ± 1%   -4.38%  (p=0.000 n=20+20)
AppendSliceLarge/16384Bytes-12    3.20µs ± 4%  2.82µs ± 4%  -11.93%  (p=0.000 n=19+20)
AppendSliceLarge/65536Bytes-12    13.0µs ± 4%  11.0µs ± 3%  -15.22%  (p=0.000 n=20+20)
AppendSliceLarge/262144Bytes-12   62.7µs ± 1%  51.6µs ± 1%  -17.67%  (p=0.000 n=19+20)
AppendSliceLarge/1048576Bytes-12   337µs ± 3%   289µs ± 3%  -14.36%  (p=0.000 n=20+20)
GrowSliceBytes-12                 31.2ns ± 4%  31.4ns ±11%     ~     (p=0.308 n=19+18)
GrowSliceInts-12                  53.4ns ±14%  45.0ns ± 6%  -15.74%  (p=0.000 n=20+19)
GrowSlicePtr-12                   87.0ns ± 3%  83.3ns ± 3%   -4.26%  (p=0.000 n=18+17)
GrowSliceStruct24Bytes-12         88.9ns ± 5%  77.8ns ± 2%  -12.45%  (p=0.000 n=20+19)
Append-12                         17.2ns ± 1%  17.3ns ± 2%     ~     (p=0.464 n=18+17)
AppendGrowByte-12                 2.28ms ± 1%  1.92ms ± 2%  -15.65%  (p=0.000 n=20+18)
AppendGrowString-12                255ms ± 3%   253ms ± 4%     ~     (p=0.065 n=19+19)
AppendSlice/1Bytes-12             3.13ns ± 0%  3.11ns ± 1%   -0.65%  (p=0.000 n=17+18)
AppendSlice/4Bytes-12             3.02ns ± 2%  3.11ns ± 1%   +3.27%  (p=0.000 n=18+17)
AppendSlice/7Bytes-12             4.14ns ± 3%  4.13ns ± 2%     ~     (p=0.380 n=19+18)
AppendSlice/8Bytes-12             3.74ns ± 3%  3.68ns ± 1%   -1.76%  (p=0.000 n=19+18)
AppendSlice/15Bytes-12            4.03ns ± 2%  4.04ns ± 2%     ~     (p=0.261 n=19+20)
AppendSlice/16Bytes-12            4.03ns ± 2%  4.03ns ± 0%     ~     (p=0.062 n=18+17)
AppendSlice/32Bytes-12            3.23ns ± 4%  3.43ns ± 1%   +6.10%  (p=0.000 n=17+18)
AppendStr/1Bytes-12               3.51ns ± 1%  3.52ns ± 1%     ~     (p=0.321 n=18+19)
AppendStr/4Bytes-12               3.46ns ± 1%  3.46ns ± 1%     ~     (p=0.977 n=18+20)
AppendStr/8Bytes-12               3.18ns ± 1%  3.19ns ± 1%     ~     (p=0.650 n=16+17)
AppendStr/16Bytes-12              6.08ns ±27%  5.52ns ± 3%   -9.16%  (p=0.002 n=18+19)
AppendStr/32Bytes-12              3.71ns ± 1%  3.53ns ± 1%   -4.73%  (p=0.000 n=20+19)
AppendSpecialCase-12              17.7ns ± 1%  17.8ns ± 3%   +0.86%  (p=0.045 n=17+18)
AppendInPlace/NoGrow/Byte-12       375ns ± 1%   376ns ± 1%   +0.35%  (p=0.021 n=20+18)
AppendInPlace/NoGrow/1Ptr-12      1.01µs ± 1%  1.10µs ± 1%   +9.28%  (p=0.000 n=18+20)
AppendInPlace/NoGrow/2Ptr-12      1.85µs ± 2%  1.71µs ± 1%   -7.51%  (p=0.000 n=19+18)
AppendInPlace/NoGrow/3Ptr-12      2.57µs ± 2%  2.44µs ± 1%   -5.08%  (p=0.000 n=19+19)
AppendInPlace/NoGrow/4Ptr-12      3.52µs ± 2%  3.35µs ± 2%   -4.70%  (p=0.000 n=20+19)
AppendInPlace/Grow/Byte-12         212ns ± 1%   217ns ± 8%   +2.57%  (p=0.000 n=20+20)
AppendInPlace/Grow/1Ptr-12         214ns ± 2%   217ns ± 3%   +1.23%  (p=0.001 n=18+19)
AppendInPlace/Grow/2Ptr-12         298ns ± 2%   300ns ± 2%   +0.55%  (p=0.038 n=19+20)
AppendInPlace/Grow/3Ptr-12         367ns ± 2%   366ns ± 2%     ~     (p=0.452 n=20+18)
AppendInPlace/Grow/4Ptr-12         416ns ± 2%   411ns ± 2%   -1.18%  (p=0.000 n=20+19)
StackGrowth-12                    43.4ns ± 1%  43.4ns ± 0%     ~     (p=1.000 n=16+16)
StackGrowthDeep-12                11.4µs ± 4%  10.3µs ± 4%   -9.65%  (p=0.000 n=20+19)

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

BlockCall was removed in golang.org/cl/28950.

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

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

Passes toolstash/buildall.

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

Remove the use of io.ReadAll in http.parsePostForm to avoid converting
the whole input from []byte to string and not performing well
space-allocated-wise.

Instead a new function called parsePostFormURLEncoded is used and is
fed directly an io.Reader that is parsed using a bufio.Reader.

Benchmark:

name         old time/op    new time/op    delta
PostQuery-4    2.90µs ± 6%    2.82µs ± 4%     ~       (p=0.094 n=9+9)

name         old alloc/op   new alloc/op   delta
PostQuery-4    1.05kB ± 0%    0.90kB ± 0%  -14.49%  (p=0.000 n=10+10)

name         old allocs/op  new allocs/op  delta
PostQuery-4      6.00 ± 0%      7.00 ± 0%  +16.67%  (p=0.000 n=10+10)

Fixes #14655

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

Todd originally set cmpDepth to 4.  Quoting:

I picked a depth of 4 by timing tests of `go tool compile arithConst_ssa.go` and `go test -c net/http`.

    3.89 / 3.92  CL w/cmpDepth = 1
    3.78 / 3.92  CL w/cmpDepth = 2
    3.44 / 3.96  CL w/cmpDepth = 3
    3.29 / 3.9   CL w/cmpDepth = 4
    3.3  / 3.93  CL w/cmpDepth = 5
    3.29 / 3.92  CL w/cmpDepth = 10

I don't see the same behavior now, differences in those two benchmarks
are in the noise (between 1 and 4).

In issue 17127, CSE takes a really long time.  Lowering cmpDepth
from 4 to 1 lowers compile time from 8 minutes to 1 minute.

Fixes #17127

Change-Id: I6dc544bbcf2a9dca73637d0182d3de1a5ae6c944
Reviewed-on: https://go-review.googlesource.com/30257
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>

Missed one in the prior CL.

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

Implementation of spec change https://golang.org/cl/24190/.

For #16085.

Change-Id: Ib7cb513354269282dfad663c7d2c6e624149f3cd
Reviewed-on: https://go-review.googlesource.com/30191Reviewed-by: David Crawshaw <crawshaw@golang.org>

Implementation of spec change https://golang.org/cl/24190/.

For #16085.

Change-Id: I17bbbce38d98a169bc64e84983a7ebfe7142f6e9
Reviewed-on: https://go-review.googlesource.com/30190Reviewed-by: Alan Donovan <adonovan@google.com>

Implementation of spec change https://golang.org/cl/24190/.

For #16085.

Change-Id: Id71ef29af5031b073e8be163f578d1bb768ff97a
Reviewed-on: https://go-review.googlesource.com/30169Reviewed-by: Matthew Dempsky <mdempsky@google.com>

Does not pass toolstash, but only because it causes ATYPE instructions
to be emitted in a different order, and it avoids emitting type
metadata for unused variables.

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

This is a backwards-compatible language change.

Per the proposal (#16085), the rules for conversions are relaxed
such that struct tags in any of the structs involved in the conversion
are ignored (recursively).

Because this is loosening the existing rules, code that compiled so
far will continue to compile.

For #16085.
Fixes #6858.

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

Identify live stack variables during SSA and compute the stack frame
layout earlier so that we can emit instructions with the correct
offsets upfront.

Passes toolstash/buildall.

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

Probably a holdover from linked list vs. slice.

Change-Id: Ib2540b08ef0ae48707d44a5d57bc23f8d65c760d
Reviewed-on: https://go-review.googlesource.com/30256
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Currently, it separates comments from rest of the AST. This causes problems when
long counter increment statements are added before compiler directives.
See Issue #17315.

This change moves comments handling into AST Visitor so that when printer prints
code from AST, position of compiler directives relative to the associated function
is preserved.

Tested with https://gist.github.com/dhananjay92/837df6bc1f171b1350f85d7a7d59ca1e
and unit test.

Fixes #17315

Change-Id: I61a80332fc1923de6fc59ff63b953671598071fa
Reviewed-on: https://go-review.googlesource.com/30161Reviewed-by: Rob Pike <r@golang.org>

Fold MOVDaddr ops into MOVXstorezero ops.
Also fold ADDconst into MOVDaddr so we're sure there isn't
(MOVDstorezero (ADDconst (MOVDaddr ..)))

Without this CL, we get:

v1 = MOVDaddr {s}
v2 = VARDEF {s}
v3 = MOVDstorezero v1 v2

The liveness pass thinks the MOVDaddr is a read of s, so s is
incorrectly thought to be live at the start of the function.

Fixes #17194

Change-Id: I2b4a2f13b12aa5b072941ee1c7b89f3793650cdc
Reviewed-on: https://go-review.googlesource.com/30086
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Michael Munday <munday@ca.ibm.com>

Wasn't convenient enough.

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

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

The aim is to make the decrypt() timing profile constant, irrespective of
the CBC padding length or correctness.  The old algorithm, on valid padding,
would only MAC bytes up to the padding length threshold, making CBC
ciphersuites vulnerable to plaintext recovery attacks as presented in the
"Lucky Thirteen" paper.

The new algorithm Write()s to the MAC all supposed payload, performs a
constant time Sum()---which required implementing a constant time Sum() in
crypto/sha1, see the "Lucky Microseconds" paper---and then Write()s the rest
of the data. This is performed whether the padding is good or not.

This should have no explicit secret-dependent timings, but it does NOT
attempt to normalize memory accesses to prevent cache timing leaks.

Updates #13385

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

I avoided anywhere in the compiler or things which might be used by
the compiler in the future, since they need to build with Go 1.4.

I also avoided anywhere where there was no benefit to changing it.

I probably missed some.

Updates #16721

Change-Id: Ib3c895ff475c6dec2d4322393faaf8cb6a6d4956
Reviewed-on: https://go-review.googlesource.com/30250
TryBot-Result: Gobot Gobot <gobot@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>

Fixes #7177.

Change-Id: Iba6063905f4f9c6acef8aba76b55d996f186d835
Reviewed-on: https://go-review.googlesource.com/29892Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>

golang.org/x/net/lif becomes vendor/golang_org/x/net/lif.

At git rev 9f0e377 (golang.org/cl/29893)

Updates #7177.

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

This change switches the use of socket implementation from the
conventional SUS-based one to the latest POSIX-based one to make
socket control message work correctly on Solaris.

It looks like those two implementations, Socket over TLI/XTI and
Socket, have different semantics in details but it wouldn't hurt
the existing applications because the exposed syscall API doesn't
support socket properties related to such a protocol independent
application framework.

Fixes #7402.

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

Reversed, indexed and multi-register stores/loads cannot accept SB
inputs. Therefore if one of these Ops is an input to a rule any
pointer that is an argument to that Op cannot be OpSB.

Change-Id: Ib8048362d1c6277122afec0d13a1c905290d69cb
Reviewed-on: https://go-review.googlesource.com/30131
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

Change-Id: I422708d50c3c727246e7991039877660ca034dc9
Reviewed-on: https://go-review.googlesource.com/30144
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

In particular, it wasn't obvious that some values are special (unless
you also found those special values), so document that it isn't
necessarily a hash value.

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

gcDumpObject is often used on a stack pointer (for example, when
checkmark finds an unmarked object on the stack), but since stack
spans don't have an elemsize, it doesn't print any of the memory from
the frame. Make it at least slightly more useful by printing
everything between obj and obj+off (inclusive). While we're here, also
print out the span state.

Change-Id: I51be064ea8791b4a365865bfdc7afa7b5aaecfbd
Reviewed-on: https://go-review.googlesource.com/30142
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

Currently span states are untyped constants and the field is just a
uint8. Make this more type-safe by introducing a type for the span
state.

Change-Id: I369bf59fe6e8234475f4921611424fceb7d0a6de
Reviewed-on: https://go-review.googlesource.com/30141
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

Should be more asymptotically happy.

We process each variable in turn to find all the
locations where it needs a phi (the dominance frontier
of all of its definitions).  Then we add all those phis.
This takes O(n * #variables), although hopefully much less.

Then we do a single tree walk to match all the
FwdRefs with the nearest definition or phi.
This takes O(n) time.

The one remaining inefficiency is that we might end up
introducing a bunch of dead phis in the first step.
A TODO is to introduce phis only where they might be
used by a read.

The old algorithm is still faster on small functions,
so there's a cutover size (currently 500 blocks).

This algorithm supercedes the David's sparse phi
placement algorithm for large functions.

Lowers compile time of example from #14934 from
~10 sec to ~4 sec.
Lowers compile time of example from #16361 from
~4.5 sec to ~3 sec.
Lowers #16407 from ~20 min to ~30 sec.

Update #14934
Update #16361
Fixes #16407

Change-Id: I1cff6364e1623c143190b6a924d7599e309db58f
Reviewed-on: https://go-review.googlesource.com/30163Reviewed-by: David Chase <drchase@google.com>

Updates #17330.

Change-Id: I83fe80139a2213f3169db884b84a4c3bd15b58b6
Reviewed-on: https://go-review.googlesource.com/30140
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

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

Allows users to override the default secure protocol list by setting the
GIT_ALLOW_PROTOCOL environment variable.

Addresses #17299 for vcs.go.

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

Allow overriding default name of `pkg-config` tool via environment
variable PKG_CONFIG (same as used by autoconf pkg.m4 macros). This
facilitates easy cross-compilation of cgo code.

Original patch against Go <= 1.4 was written by
xnox_canonical <dimitri.ledkov@canonical.com> in 2014.
Source: https://codereview.appspot.com/104960043/

Fixes #16253

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

Update gc liveness to remove special conservative treatment
of ambiguously live vars, since there is no longer a need to
protect against GCDEBUG=gcdead.

Change-Id: Id6e2d03218f7d67911e8436d283005a124e6957f
Reviewed-on: https://go-review.googlesource.com/24896Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>