I don't have access to this e-mail inbox anymore.

Change-Id: Ia3dff6a56c7f6c782be74a998a622ef0611eca7e
Reviewed-on: https://go-review.googlesource.com/122456Reviewed-by: Daniel Martí <mvdan@mvdan.cc>

This function tests that calling Shutdown on a Server that has a "new"
connection yet to write any bytes, in which case it should wait for five
seconds until considering the connection as "idle".

However, the test was flaky. If Shutdown happened to run before the
server accepted the connection, the connection would immediately be
rejected as the server is already closed, as opposed to being accepted
in the "new" state. Then, Shutdown would return almost immediately, as
it had no connections to wait for:

	--- FAIL: TestServerShutdownStateNew (2.00s)
	    serve_test.go:5603: shutdown too soon after 49.41µs
	    serve_test.go:5617: timeout waiting for Read to unblock

Fix this by making sure that the connection has been accepted before
calling Shutdown. Verified that the flake is gone after 50k concurrent
runs of the test with no failures, whereas the test used to fail around
10% of the time on my laptop:

	go test -c && stress -p 256 ./http.test -test.run TestServerShutdownStateNew

Fixes #26233.

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

Also add missing copyright headers with year determined from git log.

Change-Id: Iafc9881e746543f0a582dad2b0874d8399baf618
Reviewed-on: https://go-review.googlesource.com/122415Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

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

The maximum number of 'spanz' iterations that the s390x assembler
performs to reach a fixed point for relative offsets was 10. This
turned out to be too aggressive for one example of auto-generated
fuzzing code. Increase the number of iterations by 10x to reduce
the likelihood that the limit will be hit again. This limit only
exists to help find bugs in the assembler.

master at tip does not fail with the example code in the issue, I
have therefore not submitted it as a test (it is also quite large).
I tested this change with the example code at the commit given and
it fixes the issue.

Fixes #25269.

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

Otherwise it is possible that msan will consider the C result to be
partially initialized, which may cause msan to think that the Go stack
is partially uninitialized. The compiler will never mark the stack as
initialized, so without this CL it is possible for stack addresses to
be passed to msanread, which will cause a false positive error from msan.

Fixes #26209

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

There is no "window" global in a web worker context. Use "self" instead.

Fixes #26192

Change-Id: I6c6f3db6c3d3d9ca00a473f8c18b849bc07a0017
Reviewed-on: https://go-review.googlesource.com/122055
Run-TryBot: Richard Musiol <neelance@gmail.com>
Reviewed-by: Richard Musiol <neelance@gmail.com>

Use an HTML comment with triple dashes for the copypright header, which
means that the paragraph will be ignored when rendering both HTML and
TeX.

While at it, quote "GC", and properly link to internal/ssa/README.md.

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

Along with CL 122135,
Fixes #26197

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

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>