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

This was working when 5a was built on x86 because REG_R0 = 32,
and a 32-bit shift on x86 uses only the low 32 bits of the shift count.

On ARM, the shift clamping is different.

Moving to Go will avoid these differing shift semantics.
I tripped over and fixed this bug in new5a the same way earlier tonight.

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

Change-Id: I6ee7aa76673e51576b5a84c512b22a0f8af5b02f
Reviewed-on: https://go-review.googlesource.com/3966Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

These benchmarks are only for functions commonly used in loops. The
other functions are typically used for inspection or setup and thus are
not performance sensitive.

Change-Id: I8d0a0ba2d8234ecacb40fa3aa9077bf93c8fe89c
Reviewed-on: https://go-review.googlesource.com/3680Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

This reverts commit da4abda2.

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

Fixes #9756.

Change-Id: If4ee6fe10f8f90294ff9c5e7480371494094b111
Signed-off-by: Shenghou Ma <minux@golang.org>
Reviewed-on: https://go-review.googlesource.com/3740Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>

Fixes #9759.

Change-Id: I263f1251b9401371231374551c4f71c70cb6e359
Signed-off-by: Shenghou Ma <minux@golang.org>
Reviewed-on: https://go-review.googlesource.com/3931Reviewed-by: Dave Cheney <dave@cheney.net>

Followup to https://go-review.googlesource.com/3910

We only need 1000 iteratinons.

Change-Id: Ib63ae53105176abec77bad9609d638aeda7bcd61
Reviewed-on: https://go-review.googlesource.com/3901Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

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

(For zero values the strconv %b format prints the bias-adjusted exponent;
there's no bias in Float.)

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

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

In android-L, logging is done through the logd daemon.
If logd daemon is available, send logging to logd.
Otherwise, fallback to the legacy mechanism (/dev/log files).

This change adds access/socket/connect calls to interact with the logd.

Fixes golang/go#9398.

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

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

This reverts commit 80590711.

Conflicts:
	src/runtime/proc1.go (resolved by hand)

Change-Id: Ic62e3e802f0007ff9012b37bc5fd41fcafc153d0
Reviewed-on: https://go-review.googlesource.com/3885Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

Add Addr-checking for all Progs on input to liblink, in liblink/pass.c,
including requiring use of TYPE_ADDR, not TYPE_CONST.
Update compilers and assemblers to satisfy checks.

Change-Id: Idac36b9f6805f0451cb541d2338992ca5eaf3963
Reviewed-on: https://go-review.googlesource.com/3801Reviewed-by: Austin Clements <austin@google.com>

Generating array types like [4]int would fail even though the int type
is generatable. Allow generating values of array types when the inner
type is generatable.

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

cc is no more.

Change-Id: I8d1bc0d2e471cd9357274204c9bc1fa67cbc272d
Reviewed-on: https://go-review.googlesource.com/3833Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>

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

We don't need placeholders for the old built-in poll server any more.

Change-Id: I3a510aec6a30bc2ac97676c400177cdfe557b8dc
Reviewed-on: https://go-review.googlesource.com/3863Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

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

The issue #8432 has been marked as an issue for golang.org/x/net.

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

The unbounded list-based defer pool can grow infinitely.
This can happen if a goroutine routinely allocates a defer;
then blocks on one P; and then unblocked, scheduled and
frees the defer on another P.
The scenario was reported on golang-nuts list.

We've been here several times. Any unbounded local caches
are bad and grow to infinite size. This change introduces
central defer pool; local pools become fixed-size
with the only purpose of amortizing accesses to the
central pool.

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

Using benchmark from the issue:

benchmark                    old ns/op     new ns/op     delta
BenchmarkRangeStringCast     2162          1152          -46.72%

benchmark                    old allocs     new allocs     delta
BenchmarkRangeStringCast     1              0              -100.00%

Fixes #2204

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

Before 3c0fee10, runtime.gogo was just long enough to align to 64 bytes
on OSs with short get_tls implementations and 80 bytes on OSs with
longer get_tls implementations (Windows, Solaris, and Plan 9).
3c0fee10 added a few instructions, which pushed it to 80 on most OSs,
including Windows and Plan 9, and 96 on Solaris.

Fixes #9770.

Change-Id: Ie84810657c14ab16dce9f0e0a932955251b0bf33
Reviewed-on: https://go-review.googlesource.com/3850Reviewed-by: Alex Brainman <alex.brainman@gmail.com>

golang.org/cl/144110044 made _ consts treated
as exported as a small, safe fix for #5397.
It also introduced issue #9615.

golang.org/cl/2091 then fixed the underlying issue,
which was missing type information when the type
was specified only for _.

This cl reverts the original fix.

Fixes #9615.

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

Generalizes PRF calculation for TLS 1.2 to support arbitrary hashes (SHA-384 instead of SHA-256).
Testdata were all updated to correspond with the new cipher suites in the handshake.

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

Follow-up to cl 2682.

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

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

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

Additional elements in a DN can be added in via ExtraNames. This
option can also be used for sorting DN elements in a custom order.

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

Use memprofilerate in GODEBUG instead of memprofrate to be
consistent with other uses.

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

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

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

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

This makes names like ANOP, ATEXT, AGLOBL, ACALL, AJMP, ARET
available for use by architecture-independent processing passes.

On arm and ppc64, the alternate names are now aliases for the
official ones (ABL for ACALL, AB or ABR for AJMP, ARETURN for ARET).

Change-Id: Id027771243795af2b3745199c645b6e1bedd7d18
Reviewed-on: https://go-review.googlesource.com/3577Reviewed-by: Aram Hăvărneanu <aram@mgk.ro>
Reviewed-by: Austin Clements <austin@google.com>

Like the TEXT/GLOBL flags, this was split between from.scale and reg,
neither of which is appropriate.

Change-Id: I2a16ef066a53b6edb7afb16cce108c0d1d26389c
Reviewed-on: https://go-review.googlesource.com/3576Reviewed-by: Aram Hăvărneanu <aram@mgk.ro>
Reviewed-by: Austin Clements <austin@google.com>

Use AXXX instead of AGOK (neither is a valid instruction but AXXX is zero)
for the initial setting of Prog.as, and now there are no non-zero default
field settings.

Remove the arch-specific zprog/zprg in favor of a single global zprog.
Remove the arch-specific prg constructor in favor of emallocz(sizeof(Prog)).

Change-Id: Ia73078726768333d7cdba296f548170c1bea9498
Reviewed-on: https://go-review.googlesource.com/3575Reviewed-by: Aram Hăvărneanu <aram@mgk.ro>
Reviewed-by: Austin Clements <austin@google.com>

Originally, when this code was part of 6l/8l, every new
Prog was constructed starting with zprg, which set back=2,
and then this code walked over the list setting back=1 for
backward branches, back=0 otherwise. The initial back=2
setting was used to identify forward branches (the branched-to
instruction had back == 2 since it hadn't yet been set to 0 or 1).

When the code was extracted into liblink and linked directly
with 6a/6g/8a/8g, those programs created the Prog struct
and did not set back=2, breaking this backward branch detection.

No one noticed, because the next loop recomputes the information.
The only requirement for the next loop is that p->back == 0 or 1 for
each of the Progs in the list.

The initialization of the zprg with back=2 would cause problems
in this second loop, for the few liblink-internally-generated instructions
that are created by copying zprg, except that the first loop was
making sure that back == 0 or 1.

The first loop's manipulation of p->back can thus be deleted,
provided we also delete the zprg.back = 2 initializations.

This is awful and my fault. I apologize.

While we're here, remove the .scale = 1 from the zprg init too.
Anything that sets up a scaled index should set the scale itself.
(And mostly those come from outside liblink anyway.)

Tested by checking that all generated code is bit-for-bit
identical to before this CL.

Change-Id: I7f6e0b33ce9ccd5b7dc25e0f00429fedd0957c8c
Reviewed-on: https://go-review.googlesource.com/3574Reviewed-by: Austin Clements <austin@google.com>

A step toward making the zero Prog useful.

Change-Id: I427b98b1ce9bd8f093da825aa4bb83244fc01903
Reviewed-on: https://go-review.googlesource.com/3573Reviewed-by: Dave Cheney <dave@cheney.net>
Reviewed-by: Austin Clements <austin@google.com>

Before, amd64 and 386 stored the flags in p->from.scale
and arm and ppc64 stored the flags in p->reg.
Both caused special cases in printing and in handling of the
addresses.

To avoid possible conflicts with the real meaning of p->from
and to avoid storing a non-register value in a reg field,
use from3 to hold a TYPE_CONST value giving the flags.

There is still a special case for printing, because the flags
are specified without a $, and normally a TYPE_CONST prints
with a $. But that's much less special than what came before.

This allows us to remove the textflag and settextflag methods
from LinkArch. They are no longer architecture-specific.

Change-Id: I931da8e1ecd92e127cd9aa44ef5a73c42e730110
Reviewed-on: https://go-review.googlesource.com/3572Reviewed-by: Austin Clements <austin@google.com>