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

crypto/x509: Correction of incrorrect default version number in TBSCertificateList and Certificate.CreateCRL

RFC5280 states:

"This optional field describes the version of the encoded CRL.  When
 extensions are used, as required by this profile, this field MUST be
 present and MUST specify version 2 (the integer value is 1)."

This CL has been discussed at: http://golang.org/cl/172560043

Change-Id: I8a72d7593d5ca6714abe9abd6a37437c3b69ab0f
Reviewed-on: https://go-review.googlesource.com/2259Reviewed-by: Adam Langley <agl@golang.org>

And add names for the curve implemented in crypto/elliptic.

This permits a safer alternative to switching on BitSize
for code that implements curve-dependent cryptosystems.
(E.g., ECDSA on P-xxx curves with the matched SHA-2
instances.)

Change-Id: I653c8f47506648028a99a96ebdff8389b2a95fc1
Reviewed-on: https://go-review.googlesource.com/2133Reviewed-by: Adam Langley <agl@golang.org>

According to RFC4055 a NULL parameter MUST be present in the signature
algorithm. This patch adds the NULL value to the Signature Algorithm
parameters in the signingParamsForPrivateKey function for RSA based keys.

Section 2.1 states:

"There are two possible encodings for the AlgorithmIdentifier
parameters field associated with these object identifiers.  The two
alternatives arise from the loss of the OPTIONAL associated with the
algorithm identifier parameters when the 1988 syntax for
AlgorithmIdentifier was translated into the 1997 syntax.  Later the
OPTIONAL was recovered via a defect report, but by then many people
thought that algorithm parameters were mandatory.  Because of this
history some implementations encode parameters as a NULL element
while others omit them entirely.  The correct encoding is to omit the
parameters field; however, when RSASSA-PSS and RSAES-OAEP were
defined, it was done using the NULL parameters rather than absent
parameters.

All implementations MUST accept both NULL and absent parameters as
legal and equivalent encodings.

To be clear, the following algorithm identifiers are used when a NULL
parameter MUST be present:

   sha1Identifier AlgorithmIdentifier ::= { id-sha1, NULL }
   sha224Identifier AlgorithmIdentifier ::= { id-sha224, NULL }
   sha256Identifier AlgorithmIdentifier ::= { id-sha256, NULL }
   sha384Identifier AlgorithmIdentifier ::= { id-sha384, NULL }
   sha512Identifier AlgorithmIdentifier ::= { id-sha512, NULL }"

This CL has been discussed at: http://golang.org/cl/177610043

Change-Id: Ic782161938b287f34f64ef5eb1826f0d936f2f71
Reviewed-on: https://go-review.googlesource.com/2256Reviewed-by: Adam Langley <agl@golang.org>

While we're here, rename TestIssue7234 to Test7234 for consistency
with other tests.

Fixes #9557.

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

Please see golang.org/cl/2588 for reasons behind the name change.
We also need NO_LOCAL_POINTERS for assembly function with non-zero
local frame size.

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

Previously, gccheckmark could only be enabled or disabled by calling
runtime.GCcheckmarkenable/GCcheckmarkdisable.  This was a necessary
hack because GODEBUG was broken.

Now that GODEBUG works again, move control over gccheckmark to a
GODEBUG variable and remove these runtime functions.  Currently,
gccheckmark is enabled by default (and will probably remain so for
much of the 1.5 development cycle).

Change-Id: I2bc6f30c21b795264edf7dbb6bd7354b050673ab
Reviewed-on: https://go-review.googlesource.com/2603Reviewed-by: Rick Hudson <rlh@golang.org>

It was just an oversight that this one method of Logger was not
made available for the standard (std) Logger.

Fixes #9183

Change-Id: I2f251becdb0bae459212d09ea0e5e88774d16dea
Reviewed-on: https://go-review.googlesource.com/2686Reviewed-by: Andrew Gerrand <adg@golang.org>

Fixes #9432

Change-Id: I08c92481afa7c7fac890aa780efc1cb2fabad528
Reviewed-on: https://go-review.googlesource.com/2115Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Russ Cox <rsc@golang.org>

Renaming the function broke the race detector since it looked for the
name, didn't find it anymore and didn't insert the necessary
instrumentation.

Change-Id: I11fed6e807cc35be5724d26af12ceff33ebf4f7b
Reviewed-on: https://go-review.googlesource.com/2661Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

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

Update #9554

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

Also fix one unaligned stack size for nacl that is caught
by this change.

Fixes #9539.

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

CL 2520 omitted to set the type for an OCONVNOP node.
Typechecking obviously cannot do it for us.

5g inserts float64 <--> [u]int64 conversions at walk time.
The missing type caused it to crash.

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

Recognize loops of the form

for i := range a {
	a[i] = zero
}

in which the evaluation of a is free from side effects.
Replace these loops with calls to memclr.
This occurs in the stdlib in 18 places.

The motivating example is clearing a byte slice:

benchmark                old ns/op     new ns/op     delta
BenchmarkGoMemclr5       3.31          3.26          -1.51%
BenchmarkGoMemclr16      13.7          3.28          -76.06%
BenchmarkGoMemclr64      50.8          4.14          -91.85%
BenchmarkGoMemclr256     157           6.02          -96.17%

Update #5373.

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

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

If an inbound connection is closed, cancel the outbound http request.

This is particularly useful if the outbound request may consume resources
unnecessarily until it is cancelled.

Fixes #8406

Change-Id: I738c4489186ce342f7e21d0ea3f529722c5b443a
Signed-off-by: Peter Waller <p@pwaller.net>
Reviewed-on: https://go-review.googlesource.com/2320Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Fixes #9541.

Change-Id: I5d659ad50d7c3d1c92ed9feb86cda4c1a6e62054
Reviewed-on: https://go-review.googlesource.com/2584Reviewed-by: Dave Cheney <dave@cheney.net>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Reduce buffer to maximally needed size for conversion of 64bit integers.
Reduce number of used integer divisions.

benchmark            old ns/op     new ns/op     delta
BenchmarkItoa        144           119           -17.36%
BenchmarkPrintln     783           752           -3.96%

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

Random is bad, it can block and prevent binaries from starting.
Use urandom instead.  We'd rather have bad random bits than no
random bits.

Change-Id: I360e1cb90ace5518a1b51708822a1dae27071ebd
Reviewed-on: https://go-review.googlesource.com/2582Reviewed-by: Dave Cheney <dave@cheney.net>
Reviewed-by: Minux Ma <minux@golang.org>

This is a replay of CL 189760043 that is in release-branch.go1.4,
but not in master branch somehow.

Change-Id: I11eb40a24273e7be397e092ef040e54efb8ffe86
Reviewed-on: https://go-review.googlesource.com/2541Reviewed-by: Andrew Gerrand <adg@golang.org>

In 32-bit worlds, 8-byte objects are only aligned to 4-byte boundaries.

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

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

For a non-zero-sized struct with a final zero-sized field,
add a byte to the size (before rounding to alignment).  This
change ensures that taking the address of the zero-sized field
will not incorrectly leak the following object in memory.

reflect.funcLayout also needs this treatment.

Fixes #9401

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

(analog to Change-Id: Ia473e9ab9c63a955c252426684176bca566645ae)

Fixes #9243.

benchmark              old ns/op     new ns/op     delta
BenchmarkAddVV_1       5.76          5.60          -2.78%
BenchmarkAddVV_2       7.17          6.98          -2.65%
BenchmarkAddVV_3       8.69          8.57          -1.38%
BenchmarkAddVV_4       10.5          10.5          +0.00%
BenchmarkAddVV_5       13.3          11.6          -12.78%
BenchmarkAddVV_1e1     20.4          19.3          -5.39%
BenchmarkAddVV_1e2     166           140           -15.66%
BenchmarkAddVV_1e3     1588          1278          -19.52%
BenchmarkAddVV_1e4     16138         12657         -21.57%
BenchmarkAddVV_1e5     167608        127836        -23.73%
BenchmarkAddVW_1       4.87          4.76          -2.26%
BenchmarkAddVW_2       6.10          6.07          -0.49%
BenchmarkAddVW_3       7.75          7.65          -1.29%
BenchmarkAddVW_4       9.30          9.39          +0.97%
BenchmarkAddVW_5       10.8          10.9          +0.93%
BenchmarkAddVW_1e1     18.8          18.8          +0.00%
BenchmarkAddVW_1e2     143           134           -6.29%
BenchmarkAddVW_1e3     1390          1266          -8.92%
BenchmarkAddVW_1e4     13877         12545         -9.60%
BenchmarkAddVW_1e5     155330        125432        -19.25%

benchmark              old MB/s     new MB/s     speedup
BenchmarkAddVV_1       5556.09      5715.12      1.03x
BenchmarkAddVV_2       8926.55      9170.64      1.03x
BenchmarkAddVV_3       11042.15     11201.77     1.01x
BenchmarkAddVV_4       12168.21     12245.50     1.01x
BenchmarkAddVV_5       12041.39     13805.73     1.15x
BenchmarkAddVV_1e1     15659.65     16548.18     1.06x
BenchmarkAddVV_1e2     19268.57     22728.64     1.18x
BenchmarkAddVV_1e3     20141.45     25033.36     1.24x
BenchmarkAddVV_1e4     19827.86     25281.92     1.28x
BenchmarkAddVV_1e5     19092.06     25031.92     1.31x
BenchmarkAddVW_1       822.12       840.92       1.02x
BenchmarkAddVW_2       1310.89      1317.89      1.01x
BenchmarkAddVW_3       1549.31      1568.26      1.01x
BenchmarkAddVW_4       1720.45      1703.77      0.99x
BenchmarkAddVW_5       1857.12      1828.66      0.98x
BenchmarkAddVW_1e1     2126.39      2132.38      1.00x
BenchmarkAddVW_1e2     2784.49      2969.21      1.07x
BenchmarkAddVW_1e3     2876.89      3157.35      1.10x
BenchmarkAddVW_1e4     2882.32      3188.51      1.11x
BenchmarkAddVW_1e5     2575.16      3188.96      1.24x

(measured on OS X 10.9.5, 2.3 GHz Intel Core i7, 8GB 1333 MHz DDR3)

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

Add compile time constants for bases 10 and 16 instead of computing the cutoff
value on every invocation of ParseUint by a division.

Reduce usage of slice operations.

amd64:
benchmark              old ns/op     new ns/op     delta
BenchmarkAtoi          44.6          36.0          -19.28%
BenchmarkAtoiNeg       44.2          38.9          -11.99%
BenchmarkAtoi64        72.5          56.7          -21.79%
BenchmarkAtoi64Neg     66.1          58.6          -11.35%

386:
benchmark              old ns/op     new ns/op     delta
BenchmarkAtoi          86.6          73.0          -15.70%
BenchmarkAtoiNeg       86.6          72.3          -16.51%
BenchmarkAtoi64        126           108           -14.29%
BenchmarkAtoi64Neg     126           108           -14.29%

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

run GC in its own background goroutine making the
caller runnable if resources are available. This is
critical in single goroutine applications.
Allow goroutines that allocate a lot to help out
the GC and in doing so throttle their own allocation.
Adjust test so that it only detects that a GC is run
during init calls and not whether the GC is memory
efficient. Memory efficiency work will happen later
in 1.5.

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

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

This improves the printing of GC times to be both more human-friendly
and to provide enough information for the construction of MMU curves
and other statistics.  The new times look like:

GC: #8 72413852ns @143036695895725 pause=622900 maxpause=427037 goroutines=11 gomaxprocs=4
GC:     sweep term: 190584ns	   max=190584	total=275001	procs=4
GC:     scan:       260397ns	   max=260397	total=902666	procs=1
GC:     install wb: 5279ns	   max=5279	total=18642	procs=4
GC:     mark:       71530555ns	   max=71530555	total=186694660	procs=1
GC:     mark term:  427037ns	   max=427037	total=1691184	procs=4

This prints gomaxprocs and the number of procs used in each phase for
the benefit of analyzing mutator utilization during concurrent phases.
This also means the analysis doesn't have to hard-code which phases
are STW.

This prints the absolute start time only for the GC cycle.  The other
start times can be derived from the phase durations.  This declutters
the view for humans readers and doesn't pose any additional complexity
for machine readers.

This removes the confusing "cycle" terminology.  Instead, this places
the phase duration after the phase name and adds a "ns" unit, which
both makes it implicitly clear that this is the duration of that phase
and indicates the units of the times.

This adds a "GC:" prefix to all lines for easier identification.

Finally, this generally cleans up the code as well as the placement of
spaces in the output and adds print locking so the statistics blocks
are never interrupted by other prints.

Change-Id: Ifd056db83ed1b888de7dfa9a8fc5732b01ccc631
Reviewed-on: https://go-review.googlesource.com/2542Reviewed-by: Rick Hudson <rlh@golang.org>

          (platforms w/o corresponding assembly kernels)

For short vector adds there's some erradic slow-down, but overall
these routines have become significantly faster. This only matters
for platforms w/o native (assembly) versions of these kernels, so
we are not concerned about the minor slow-down for short vectors.

This code was already reviewed under Mercurial (golang.org/cl/172810043)
but wasn't submitted before the switch to git.

Benchmarks run on 2.3GHz Intel Core i7, running OS X 10.9.5,
with the respective AddVV and AddVW assembly routines disabled.

benchmark              old ns/op     new ns/op     delta
BenchmarkAddVV_1       6.59          7.09          +7.59%
BenchmarkAddVV_2       10.3          10.1          -1.94%
BenchmarkAddVV_3       10.9          12.6          +15.60%
BenchmarkAddVV_4       13.9          15.6          +12.23%
BenchmarkAddVV_5       16.8          17.3          +2.98%
BenchmarkAddVV_1e1     29.5          29.9          +1.36%
BenchmarkAddVV_1e2     246           232           -5.69%
BenchmarkAddVV_1e3     2374          2185          -7.96%
BenchmarkAddVV_1e4     58942         22292         -62.18%
BenchmarkAddVV_1e5     668622        225279        -66.31%
BenchmarkAddVW_1       6.81          5.58          -18.06%
BenchmarkAddVW_2       7.69          6.86          -10.79%
BenchmarkAddVW_3       9.56          8.32          -12.97%
BenchmarkAddVW_4       12.1          9.53          -21.24%
BenchmarkAddVW_5       13.2          10.9          -17.42%
BenchmarkAddVW_1e1     23.4          18.0          -23.08%
BenchmarkAddVW_1e2     175           141           -19.43%
BenchmarkAddVW_1e3     1568          1266          -19.26%
BenchmarkAddVW_1e4     15425         12596         -18.34%
BenchmarkAddVW_1e5     156737        133539        -14.80%
BenchmarkFibo          381678466     132958666     -65.16%

benchmark              old MB/s     new MB/s     speedup
BenchmarkAddVV_1       9715.25      9028.30      0.93x
BenchmarkAddVV_2       12461.72     12622.60     1.01x
BenchmarkAddVV_3       17549.64     15243.82     0.87x
BenchmarkAddVV_4       18392.54     16398.29     0.89x
BenchmarkAddVV_5       18995.23     18496.57     0.97x
BenchmarkAddVV_1e1     21708.98     21438.28     0.99x
BenchmarkAddVV_1e2     25956.53     27506.88     1.06x
BenchmarkAddVV_1e3     26947.93     29286.66     1.09x
BenchmarkAddVV_1e4     10857.96     28709.46     2.64x
BenchmarkAddVV_1e5     9571.91      28409.21     2.97x
BenchmarkAddVW_1       1175.28      1433.98      1.22x
BenchmarkAddVW_2       2080.01      2332.54      1.12x
BenchmarkAddVW_3       2509.28      2883.97      1.15x
BenchmarkAddVW_4       2646.09      3356.83      1.27x
BenchmarkAddVW_5       3020.69      3671.07      1.22x
BenchmarkAddVW_1e1     3425.76      4441.40      1.30x
BenchmarkAddVW_1e2     4553.17      5642.96      1.24x
BenchmarkAddVW_1e3     5100.14      6318.72      1.24x
BenchmarkAddVW_1e4     5186.15      6350.96      1.22x
BenchmarkAddVW_1e5     5104.07      5990.74      1.17x

Change-Id: I7a62023b1105248a0e85e5b9819d3fd4266123d4
Reviewed-on: https://go-review.googlesource.com/2480Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>

Replaced use of rotate instructions (RCRQ, RCLQ) with ADDQ/SBBQ
for restoring/saving the carry flag per suggestion from Torbjörn
Granlund (author of GMP bignum libs for C).
The rotate instructions tend to be slower on todays machines.

benchmark              old ns/op     new ns/op     delta
BenchmarkAddVV_1       5.69          5.51          -3.16%
BenchmarkAddVV_2       7.15          6.87          -3.92%
BenchmarkAddVV_3       8.69          8.06          -7.25%
BenchmarkAddVV_4       8.10          8.13          +0.37%
BenchmarkAddVV_5       8.37          8.47          +1.19%
BenchmarkAddVV_1e1     13.1          12.0          -8.40%
BenchmarkAddVV_1e2     78.1          69.4          -11.14%
BenchmarkAddVV_1e3     815           656           -19.51%
BenchmarkAddVV_1e4     8137          7345          -9.73%
BenchmarkAddVV_1e5     100127        93909         -6.21%
BenchmarkAddVW_1       4.86          4.71          -3.09%
BenchmarkAddVW_2       5.67          5.50          -3.00%
BenchmarkAddVW_3       6.51          6.34          -2.61%
BenchmarkAddVW_4       6.69          6.66          -0.45%
BenchmarkAddVW_5       7.20          7.21          +0.14%
BenchmarkAddVW_1e1     10.0          9.34          -6.60%
BenchmarkAddVW_1e2     45.4          52.3          +15.20%
BenchmarkAddVW_1e3     417           491           +17.75%
BenchmarkAddVW_1e4     4760          4852          +1.93%
BenchmarkAddVW_1e5     69107         67717         -2.01%

benchmark              old MB/s      new MB/s      speedup
BenchmarkAddVV_1       11241.82      11610.28      1.03x
BenchmarkAddVV_2       17902.68      18631.82      1.04x
BenchmarkAddVV_3       22082.43      23835.64      1.08x
BenchmarkAddVV_4       31588.18      31492.06      1.00x
BenchmarkAddVV_5       38229.90      37783.17      0.99x
BenchmarkAddVV_1e1     48891.67      53340.91      1.09x
BenchmarkAddVV_1e2     81940.61      92191.86      1.13x
BenchmarkAddVV_1e3     78443.09      97480.44      1.24x
BenchmarkAddVV_1e4     78644.18      87129.50      1.11x
BenchmarkAddVV_1e5     63918.48      68150.84      1.07x
BenchmarkAddVW_1       13165.09      13581.00      1.03x
BenchmarkAddVW_2       22588.04      23275.41      1.03x
BenchmarkAddVW_3       29483.82      30303.96      1.03x
BenchmarkAddVW_4       38286.54      38453.21      1.00x
BenchmarkAddVW_5       44414.57      44370.59      1.00x
BenchmarkAddVW_1e1     63816.84      68494.08      1.07x
BenchmarkAddVW_1e2     140885.41     122427.16     0.87x
BenchmarkAddVW_1e3     153258.31     130325.28     0.85x
BenchmarkAddVW_1e4     134447.63     131904.02     0.98x
BenchmarkAddVW_1e5     92609.41      94509.88      1.02x

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

Edge cases like base 2 and 36 conversions are now covered.
Many tests are mirrored from the itoa tests.

Added more test cases for syntax errors.

Change-Id: Iad8b2fb4854f898c2bfa18cdeb0cb4a758fcfc2e
Reviewed-on: https://go-review.googlesource.com/2463Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

I would like to create new syscalls in src/internal/syscall,
and I prefer not to add new shell scripts for that.

Replacement for CL 136000043.

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

This test was taking a long time, reduce its zealousness.

Change-Id: Ib824247b84b0039a9ec690f72336bef3738d4c44
Reviewed-on: https://go-review.googlesource.com/2502Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Minux Ma <minux@golang.org>

$GOTESTONLY controls which set of tests gets run. Only "std" is
supported. This should bring the time of plan9 builder down
from 90 minutes to a maybe 10-15 minutes when running on GCE.

(Plan 9 has performance problems when running on GCE, and/or with the
os/exec package)

This is a temporary workaround for one builder. The other Plan 9
builders will continue to do full builds. The plan9 buidler will be
renamed plan9-386-gcepartial or something to indicate it's not running
the 'test/*' directory, or API tests. Go on Plan 9 has bigger problems
for now. This lets us get trybots going sooner including Plan 9,
without waiting 90+ minutes.

Update #9491

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

This isn't the final answer, but it will give us a clue about what's
going on.

Update #9491

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

Removing #cgo directive parsing from cmd/cgo was done in
https://golang.org/cl/8610044.

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

SWIG has always returned a typed interface value for a C++ class,
so the interface value will never be nil even if the pointer itself
is NULL. ptr == NULL in C/C++ should be ptr.Swigcptr() == 0 in Go.

Fixes #9514.

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

Increasing the timeout prevents the runtime test
to time out on the Plan 9 instances running on GCE.

Update golang/go#9491

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

Now that there's no 6c compiler anymore, there's no need for cgo to
generate C headers that are compatible with it.

Fixes #9528

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