The implementation is mostly copied from the commit that added
linux/amd64 support for this feature (https://golang.org/cl/17761).

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

We already remove -rdynamic if -static appears in -extldflags.
Extend that to apply to CGO_LDFLAGS and #cgo LDFLAGS as well.

Updates #26197

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

Currently we use a globally unique symbol property on objects that get
passed from JavaScript to Go to store a unique ID that Go then uses when
referring back to the JavaScript object (via js.Value.ref). This
approach fails however when a JavaScript object cannot be modified, i.e.
cannot have new properties added or is frozen. The test that is added as
part of this commit currently fails with:

  Cannot add property Symbol(), object is not extensible

Instead we consolidate the string, symbol and object unique ID mapping
into a single map. Map key equality is determined via strict equality,
which is the semantic we want in this situation.

Change-Id: Ieb2b50fc36d3c30e148aa7a41557f3c59cd33766
Reviewed-on: https://go-review.googlesource.com/121799
Run-TryBot: Paul Jolly <paul@myitcv.org.uk>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Richard Musiol <neelance@gmail.com>

Fixes #25911

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

Since the initial version was written, I've gotten help writing
cmd/compile/README.md and I've also learned some more on my own, so it's
time to organise this document better and expand it.

First, split up the document in sections, starting from the simplest
ideas that can be explained on their own. From there, build all the way
up into SSA functions and how they are compiled.

Each of the sections also gets more detail now; most ideas that were a
paragraph are now a section with several paragraphs. No new major
sections have been added in this CL.

While at it, add a copyright notice and make better use of markdown,
just like in the other README.md.

Also fix a file path in value.go, which I noticed to be stale while
reading godocs to write the document.

Finally, leave a few TODO comments for areas that would benefit from
extra input from people familiar with the SSA package. They will be
taken care of in future CLs.

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

Follow the convertion (https://golang.org/s/generatedcode) for generated
code in stringer.go.

Change-Id: I7b5fbb04ba03e8ac77a9a0a402088669469de858
Reviewed-on: https://go-review.googlesource.com/122015
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

When a command has a test that is not in package main, the main
package is built as a library, with ForceLibrary set. It can of course
also be built as an ordinary main package. If we don't record that fact
in the hash, then both variants of the command will use the same hash,
which causes a GODEBUG=gocacheverify=1 failure. It also seems unsafe
although it's not clear to me whether it can cause an actual failure.

Along with CL 121941,
Fixes #25666

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

The linker's sym.Symbol struct contains two string fields, "Dynimplib"
and "Dynimpvers" that are used only in very specific circumstances
(for many symbols, such as DWARF syms, they are wasted space). Split
these two off into a separate struct, then point to an instance of
that struct when needed. This reduces the size of sym.Symbol so as to
save space in the common case.

Updates #26186

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

The sym.Symbol 'Reachparent' field is used only when field tracking
is enabled. So as to use less memory for the common case where
field tracking is not enabled, remove this field and use a side
table stored in the context to achieve the same functionality.

Updates #26186

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

Fixes #24518.

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

Before CL 116855, Transport would only skip over 100 (expect-continue)
responses automatically and treat all other 1xx responses as if they
were the final status. CL 116855 made the Transport more spec
compliant (ignoring unknown 1xx responses), but broke "101 Switching
Protocols" in the process. Since 101 is already in use and defined to
not have a following message, treat it as terminal.

Note that because the Client/Transport don't support hijacking the
underlying Conn, most clients doing a WebSocket or other protocol
upgrade are probably using net.Dial + http.ReadResponse instead, which
remained unaffected (before & after this CL).

The main affect of this CL is to fix tests that were using the
Client/Transport to test that a server returns 101, presumably without
actually switching to another protocol.

Fixes #26161

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

Fixes #20239

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

The vetx output file is a build output, and as such should be
deterministic. This CL changes it to not depend on map iteration order.

This avoids a pointless GODEBUG=gocacheverify=1 failure.

Updates #25666

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

Late opt pass may generate dead stores, which messes up store
chain calculation in later passes. Run generic deadcode even
in -N mode to remove them.

Fixes #26163.

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

These rules don't even type check.  ADDQconstmodify returns memory,
and it is being rewritten to a value that returns an int64.

There should be a MOVQstore wrapped around the result.
These rules never fire during all.bash, so they aren't even tested.

I'm just going to remove them for now.

Change-Id: I76008eb51ae4e16c707fac73c05a8d67cac149ae
Reviewed-on: https://go-review.googlesource.com/121935
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

If the address of an auto reaches a phi then any further stores to
the pointer represented by the phi probably need to be kept. This
is because stores to the other arguments to the phi may be visible
to the program.

Fixes #26153.

Change-Id: Ic506c6c543bf70d792e5b1a64bdde1e5fdf1126a
Reviewed-on: https://go-review.googlesource.com/121796
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>

Allow static complication of cgo enabled libraries.

Fixes #16651

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

Fixes #26173

Change-Id: I032551f63b359c8cbb7296931e1957d2bff8f328
Reviewed-on: https://go-review.googlesource.com/121819
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>

TestUtimesNanoAt in the vendored copy of golang.org/x/sys/unix currently
fails on the linux-arm-arm5spacemonkey builder. Update the vendored copy
to pick up the fix from CL 120816.

Updates #26034

Change-Id: I75c8875089f58a4c32e2e7aa75884b2bcba7bd68
Reviewed-on: https://go-review.googlesource.com/121800
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Currently, on Windows, the thread stack size is set or assumed in many
different places. In non-cgo binaries, both the Go linker and the
runtime have a copy of the stack size, the Go linker sets the size of
the main thread stack, and the runtime sets the size of other thread
stacks. In cgo binaries, the external linker sets the main thread
stack size, the runtime assumes the size of the main thread stack will
be the same as used by the Go linker, and the cgo entry code assumes
the same.

Furthermore, users can change the main thread stack size using
editbin, so the runtime doesn't even really know what size it is, and
user C code can create threads with unknown thread stack sizes, which
we also assume have the same default stack size.

This is all a mess.

Fix the corner cases of this and the duplication of knowledge between
the linker and the runtime by querying the OS for the stack bounds
during thread setup. Furthermore, we unify all of this into just
runtime.minit for both cgo and non-cgo binaries and for the main
thread, other runtime-created threads, and C-created threads.

Updates #20975.

Change-Id: I45dbee2b5ea2ae721a85a27680737ff046f9d464
Reviewed-on: https://go-review.googlesource.com/120336
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Currently, we allocate 1MB or 2MB thread stacks on Windows, but in
non-cgo binaries still set the g0 stack bounds assuming only 64k is
available. While this is fine in pure Go binaries, a non-cgo Go binary
on Windows can use the syscall package to call arbitrary DLLs, which
may call back into Go. If a DLL function uses more than 64k of stack
and then calls back into Go, the Go runtime will believe that it's out
of stack space and crash.

Fix this by plumbing the correct stack size into the g0 stacks of
non-cgo binaries. Cgo binaries already use the correct size because
their g0 stack sizes are set by a different code path.

Fixes #20975.

Change-Id: Id6fb559cfe1e1ea0dfac56d4654865c20dccf68d
Reviewed-on: https://go-review.googlesource.com/120195
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Executing tests in cmd/go/internal/modfetch/gitrepo/fetch_test.go in enviroment
witout outside connectivity in to the internet results in tests failure:

2018/06/25 12:48:26 git clone --mirror https://vcs-test.golang.org/git/gitrepo1 /tmp/gitrepo-test-221822392/gitrepo2 in : exit status 128:
	Cloning into bare repository '/tmp/gitrepo-test-221822392/gitrepo2'...
	fatal: unable to access 'https://vcs-test.golang.org/git/gitrepo1/': Could not resolve host: vcs-test.golang.org
FAIL	cmd/go/internal/modfetch/gitrepo	0.144s

Call flag.Parse in TestMain to properly initialize test environment variables

Fixes #26007

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

The OpenBSD sysctl code has been copy-pasted three times now. Abstract
it.

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

On the OpenBSD builder this reduces the test time from 213 seconds to
60 seconds, without loss of testing.

Not sure why the test is so much slower on OpenBSD, so not closing the
issues.

Updates #26155
Updates #26174

Change-Id: I13b58bbe3b209e591c308765077d2342943a3d2a
Reviewed-on: https://go-review.googlesource.com/121820
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ralph Corderoy <ralph@inputplus.co.uk>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: Idbd8a1b5bfeb1c23c86cef0697cf0380900e95f3
GitHub-Last-Rev: a8c2b27046582c4eef932a8502826a3b23b8dab3
GitHub-Pull-Request: golang/go#26175
Reviewed-on: https://go-review.googlesource.com/121821Reviewed-by: Keith Randall <khr@golang.org>

For each Javascript object that returns to Go as a js.Value, we
associate the ref id to it. But if this ref id is copied or
inherited to other object, it would mess up the ref-object
mapping.

In storeValue, make sure the object is indeed the one we are
storing. Otherwise allocate a new ref id.

Fixes #26143.

Change-Id: Ie60bb2f8d1533da1bbe6f46045866515ec2af5a9
Reviewed-on: https://go-review.googlesource.com/121835
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Richard Musiol <neelance@gmail.com>

The previous CL (https://go-review.googlesource.com/c/go/+/96756)
added comments that didn't really say much, but there is something
so say: what the units are and that they are indexed starting at 1.

Add a more helpful comment on the type, and also follow proper
style by using initial capitals and a period.

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

This commit adds examples that demonstrate usage in a practical way.

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

Before GCC 8 C code like

const unsigned long long int neg = (const unsigned long long) -1;
void f(void) { static const double x = (neg); }

would get an error "initializer element is not constant". In GCC 8 and
later it does not.

Because a value like neg, above, can not be used as a general integer
constant, this causes cgo to conclude that it is a floating point
constant. The way that cgo handles floating point values then causes
it to get the wrong value for it: 18446744073709551615 rather than -1.
These are of course the same value when converted to int64, but Go
does not permit that kind of conversion for an out-of-range constant.

This CL side-steps the problem by treating floating point constants
with integer type as they would up being treated before GCC 8: as
variables rather than constants.

Fixes #26066

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

Fixes issue #26139

Change-Id: Id9a3e5c443ee175ad9add6296ed45bdf328b15a0
GitHub-Last-Rev: b3f8a8f165d15cfffd4948151eae34f95330748c
GitHub-Pull-Request: golang/go#26146
Reviewed-on: https://go-review.googlesource.com/121696Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Fixes #23316

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

Updates http2 to x/net/http2 git rev 97aa3a539 for:

    http2: dynamic table updates must occur first
    https://golang.org/cl/111681

    http2: receiving too much data is a protocol error
    https://golang.org/cl/111679

    http2: correct overflow protection
    https://golang.org/cl/111675

    http2: make Server send GOAWAY if Handler sets "Connection: close" header
    https://golang.org/cl/121415

Fixes #20977

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

If the runtime code panics due to a bad index or slice expression,
then throw instead of panicing. This will skip calls to recover and dump
the entire runtime stack trace. The runtime should never panic due to
an out of bounds index, and this will help with debugging if it does.

For #24991
Updates #25201

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

OpenBSD 6.4 is going to start requiring that the SP points to memory
that was mapped with MAP_STACK on system call entry, traps, and when
switching to the alternate signal stack [1]. Currently, Go doesn't map
any memory MAP_STACK, so the kernel quickly kills Go processes.

Fix this by remapping the memory that backs stack spans with
MAP_STACK, and re-remapping it without MAP_STACK when it's returned to
the heap.

[1] http://openbsd-archive.7691.n7.nabble.com/stack-register-checking-td338238.html

Fixes #26142.

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

CL 103055 made it so that invalid parameter expansions, like "$|", did
not make the dollar sign silently disappear.

A few edge cases were not taken into account, such as "${}" and "${",
which were now printing just "$". For consistency and to not break
existing programs, go back to eating up the characters when invalid
syntax is encountered.

For completeness, add a "$" test case too, even though its behavior is
unchanged by this CL.

Fixes #26135.

Change-Id: I5d25db9a8356dc6047a8502e318355113a99b247
Reviewed-on: https://go-review.googlesource.com/121636
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

The existing implementation of bytes.Compare on s390x doesn't work properly for slices longer
than 256 elements. This change fixes that. Added tests for long strings and slices of bytes.

Fixes #26114

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

This reverts commit 1a27f048.

Reason for revert: Broke the ssacheck and -N-l builders, and the -N-l fix looks like it will take some time and take a different route entirely.

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

Be super explicit that HTTP keep-alives != TCP keep-alives.

Fixes #26128

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

I thought I removed this but failed to amend it to my commit before
submitting.

Change-Id: I2d687d91f4de72251548faa700006af0fea503af
Reviewed-on: https://go-review.googlesource.com/121615
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>

If one quickly looks at the strings package godoc, reading the name
TrimLeft, one might think it removes a prefix from the string.

The function's godoc does explain its purpose, but it's apparent that it
is not clear enough, as there have been numerous raised issues about
this confusion: #12771 #14657 #18160 #19371 #20085 #25328 #26119. These
questions are also frequent elsewhere on the internet.

Add a very short paragraph to the godoc, to hopefully point new Go
developers in the right direction faster. Do the same thing for
TrimRight and TrimSuffix.

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