The receiver itself is not transmitted and does not need to be
marshalable by encoding/gob.
Fixes#16803.
Change-Id: I42a3603fb7d3b36c97dcc2e51a398cd65ec3227d
Reviewed-on: https://go-review.googlesource.com/32094
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
The SignatureAndHashAlgorithm from TLS 1.2[1] is being changed to
SignatureScheme in TLS 1.3[2]. (The actual values are compatible
however.)
Since we expect to support TLS 1.3 in the future, we're already using
the name and style of SignatureScheme in the recently augmented
ClientHelloInfo. As this is public API, it seems that SignatureScheme
should have its own type and exported values, which is implemented in
this change.
[1] https://tools.ietf.org/html/rfc5246#section-7.4.1.4.1
[2] https://tools.ietf.org/html/draft-ietf-tls-tls13-18#section-4.2.3
Change-Id: I0482755d02bb9a04eaf075c012696103eb806645
Reviewed-on: https://go-review.googlesource.com/32119
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Since a root certificate is self-signed, it's a valid child of itself.
If a root certificate appeared both in the pool of intermediates and
roots the verification code could find a chain which included it twice:
first as an intermediate and then as a root. (Existing checks prevented
the code from looping any more.)
This change stops the exact same certificate from appearing twice in a
chain. This simplifies the results in the face of the common
configuration error of a TLS server returning a root certificate.
(This should also stop two different versions of the “same” root
appearing in a chain because the self-signature on one will not validate
for the other.)
Fixes#16800.
Change-Id: I004853baa0eea27b44d47b9b34f96113a92ebac8
Reviewed-on: https://go-review.googlesource.com/32121
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Fixes a bug where assignments that should come after a call
were instead being issued before the call.
Fixes#17596Fixes#17618
Change-Id: Ic9ae4c34ae38fc4ccd0604b65345b05896a2c295
Reviewed-on: https://go-review.googlesource.com/32226
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
The mechanism is initially introduced (and reviewed) in CL 30597
on S390X.
Change-Id: I83024d2fc84c8efc23fbda52b3ad83073f42cb93
Reviewed-on: https://go-review.googlesource.com/32179
Reviewed-by: David Chase <drchase@google.com>
The mechanism is initially introduced (and reviewed) in CL 30597
on S390X.
Change-Id: I12fbe6e9269b2936690e0ec896cb6b5aa40ad7da
Reviewed-on: https://go-review.googlesource.com/32180
Reviewed-by: David Chase <drchase@google.com>
DUFFZERO was disabled due to issue #12108. CL 27592 fixed it and
enabled DUFFZERO in general, but this one was forgotten.
Change-Id: I0476a3a0524c7b54218f7a747bdba76cd823fbc5
Reviewed-on: https://go-review.googlesource.com/32181
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
With the removal of the old backend,
a Label is just a Node.
Passes toolstash -cmp.
Change-Id: Ia62cb00fbc551efb75a4ed4dc6ed54fca0831dbf
Reviewed-on: https://go-review.googlesource.com/32216
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Tests for determinism was not working as intended since io.Copybuffer
uses the io.WriterTo if available.
This exposed that level 0 (no compression) changed output
based on the number of writes and buffers given to the
writer.
Previously, Write would emit a new raw block (BTYPE=00) for
every non-empty call to Write.
This CL fixes it such that a raw block is only emitted upon
the following conditions:
* A full window is obtained (every 65535 bytes)
* Flush is called
* Close is called
Change-Id: I807f866d97e2db7820f11febab30a96266a6cbf1
Reviewed-on: https://go-review.googlesource.com/31174
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
EscScope behaves like EscHeap in current code.
There are no need to handle it specially.
So remove it and use EscHeap instead.
Change-Id: I910106fd147f00e5f4fd52c7dde05128141a5160
Reviewed-on: https://go-review.googlesource.com/32130
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The CloseWrite method sends a close_notify alert record to the other
side of the connection. This record indicates that the sender has
finished sending on the connection. Unlike the Close method, the sender
may still read from the connection until it recieves a close_notify
record (or the underlying connection is closed). This is analogous to a
TCP half-close.
This is a rework of CL 25159 with fixes for the unstable test.
Updates #8579
Change-Id: I47608d2f82a88baff07a90fd64c280ed16a60d5e
Reviewed-on: https://go-review.googlesource.com/31318
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Re-writing the switch statement as a single boolean expression
reduces the number of branches that the compiler generates.
It is also arguably easier to read as a pair of numeric ranges
that valid runes can exist in.
No test changes since the existing test does a good job of
testing all of the boundaries.
This change was to gain back some performance after a correctness
fix done in http://golang.org/cl/32123.
The correctness fix (CL/32123) slowed down the benchmarks slightly:
benchmark old ns/op new ns/op delta
BenchmarkIndexRune/10-4 19.3 21.6 +11.92%
BenchmarkIndexRune/32-4 33.6 35.2 +4.76%
Since the fix relies on utf8.ValidRune, this CL improves benchmarks:
benchmark old ns/op new ns/op delta
BenchmarkIndexRune/10-4 21.6 20.0 -7.41%
BenchmarkIndexRune/32-4 35.2 33.5 -4.83%
Change-Id: Ib1ca10a2e29c90e879a8ef9b7221c33e85d015d8
Reviewed-on: https://go-review.googlesource.com/32122
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
In all previous versions of Go, the behavior of IndexRune(s, r)
where r was utf.RuneError was that it would effectively return the
index of any invalid UTF-8 byte sequence (include RuneError).
Optimizations made in http://golang.org/cl/28537 and
http://golang.org/cl/28546 altered this undocumented behavior such
that RuneError would only match on the RuneError rune itself.
Although, the new behavior is arguably reasonable, it did break code
that depended on the previous behavior. Thus, we add special checks
to ensure that we preserve the old behavior.
There is a slight performance hit for correctness:
benchmark old ns/op new ns/op delta
BenchmarkIndexRune/10-4 19.3 21.6 +11.92%
BenchmarkIndexRune/32-4 33.6 35.2 +4.76%
This only occurs on small strings. The performance hit for larger strings
is neglible and not shown.
Fixes#17611
Change-Id: I1d863a741213d46c40b2e1724c41245df52502a5
Reviewed-on: https://go-review.googlesource.com/32123
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
By using these utility functions, the code can be made a little shorter.
Thanks to Omar Shafie for pointing this out in
https://golang.org/cl/27393/.
Change-Id: I33fd97cf7d60a31d0844ec16c12bba530dcc6f6d
Reviewed-on: https://go-review.googlesource.com/32120
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
- Removes a subject-verb disagreement.
- Documents that PATCH requests also populate PostForm.
- Explains that r.PostForm is always set (but blank for GET etc.).
Fixes#16609
Change-Id: I6b4693f8eb6db7c66fd9b9cd1df8927f50d46d50
Reviewed-on: https://go-review.googlesource.com/32091
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Don't include package path when creating LSyms for auto and param
variables during Prog generation, and update the DWARF emit routine
accordingly (remove the code that chops off package path from names in
DWARF var location expressions). Implementation suggested by mdempsky@.
The intent of this change is to have saner location expressions in cases
where the variable corresponds to a structure field. For example, the
SSA compiler's "decompose" phase can take a slice value and break it
apart into three scalar variables corresponding to the fields (slice "X"
gets split into "X.len", "X.cap", "X.ptr"). In such cases we want the
name in the location expression to omit the package path but preserve
the original variable name (e.g. "X").
Fixes#16338
Change-Id: Ibc444e7f3454b70fc500a33f0397e669d127daa1
Reviewed-on: https://go-review.googlesource.com/31819
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Sometimes neither the src nor the dst of an escape edge
contains the line number appropriate to the edge, so add
a field so that can be set correctly.
Also updated some of the explanations to be less jargon-y
and perhaps more informative, and folded bug example into
test.
Cleaned up some of the function/method names in esc.go
and did a quick sanity check that each "bundling" function
was actually called often enough to justify its existence.
Fixes#17459.
Change-Id: Ieba53ab0a6ba1f7a6c4962bc0b702ede9cc3a3cc
Reviewed-on: https://go-review.googlesource.com/31660
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Currently, markroot delays scanning mark worker stacks until mark
termination by putting the mark worker G directly on the rescan list
when it encounters one during the mark phase. Without this, since mark
workers are non-preemptible, two mark workers that attempt to scan
each other's stacks can deadlock.
However, this is annoyingly asymmetric and causes some real problems.
First, markroot does not own the G at that point, so it's not
technically safe to add it to the rescan list. I haven't been able to
find a specific problem this could cause, but I suspect it's the root
cause of issue #17099. Second, this will interfere with the hybrid
barrier, since there is no stack rescanning during mark termination
with the hybrid barrier.
This commit switches to a different approach. We move the mark
worker's call to gcDrain to the system stack and set the mark worker's
status to _Gwaiting for the duration of the drain to indicate that
it's preemptible. This lets another mark worker scan its G stack while
the drain is running on the system stack. We don't return to the G
stack until we can switch back to _Grunning, which ensures we don't
race with a stack scan. This lets us eliminate the special case for
mark worker stack scans and scan them just like any other goroutine.
The only subtlety to this approach is that we have to disable stack
shrinking for mark workers; they could be referring to captured
variables from the G stack, so it's not safe to move their stacks.
Updates #17099 and #17503.
Change-Id: Ia5213949ec470af63e24dfce01df357c12adbbea
Reviewed-on: https://go-review.googlesource.com/31820
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
This issue has been fixed in CL 31271.
Fixes#8908.
Change-Id: I8015490e2d992e09c664560e42188315e0e0669e
Reviewed-on: https://go-review.googlesource.com/32150
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Now that SSA's write barrier pass is generating calls to these,
compile doesn't need to look them up.
Change-Id: Ib50e5f2c67b247ca280d467c399e23877988bc12
Reviewed-on: https://go-review.googlesource.com/32170
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TestRemoveDevNull was added in CL 31657. However, this test
was failing on Plan 9, because /dev/null was considered as
a regular file.
On Plan 9, there is no special mode to distinguish between
device files and regular files.
However, files are served by different servers. For example,
/dev/null is served by #c (devcons), while /bin/cat is served
by #M (devmnt).
We chose to consider only the files served by #M as regular
files. All files served by different servers will be considered
as device files.
Fixes#17598.
Change-Id: Ibb1c3357d742cf2a7de15fc78c9e436dc31982bb
Reviewed-on: https://go-review.googlesource.com/32152
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This allows callers to invoke f.Usage() themselves and get the default
usage handler instead of a panic (from calling a nil function).
Fixes#16955.
Change-Id: Ie337fd9e1f85daf78c5eae7b5c41d5ad8c1f89bf
Reviewed-on: https://go-review.googlesource.com/31576
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Currently, if the number of stack barriers for a stack is 0, we'll
create a zero-length slice that points just past the end of the stack
allocation. This bad pointer causes GC panics.
Fix this by creating a nil slice if the stack barrier count is 0.
In practice, the only way this can happen is if
GODEBUG=gcstackbarrieroff=1 is set because even the minimum size stack
reserves space for two stack barriers.
Change-Id: I3527c9a504c445b64b81170ee285a28594e7983d
Reviewed-on: https://go-review.googlesource.com/31762
Reviewed-by: Rick Hudson <rlh@golang.org>
This adds debug code enabled in gccheckmark mode that panics if we
attempt to mark an unallocated object. This is a common issue with the
hybrid barrier when we're manipulating uninitialized memory that
contains stale pointers. This also tends to catch bugs that will lead
to "sweep increased allocation count" crashes closer to the source of
the bug.
Change-Id: I443ead3eac6f316a46f50b106078b524cac317f4
Reviewed-on: https://go-review.googlesource.com/31761
Reviewed-by: Rick Hudson <rlh@golang.org>
Currently reflectcall has a subtle dance with write barriers where the
assembly code copies the result values from the stack to the in-heap
argument frame without write barriers and then calls into the runtime
after the fact to invoke the necessary write barriers.
For the hybrid barrier (and for ROC), we need to switch to a
*pre*-write write barrier, which is very difficult to do with the
current setup. We could tie ourselves in knots of subtle reasoning
about why it's okay in this particular case to have a post-write write
barrier, but this commit instead takes a different approach. Rather
than making things more complex, this simplifies reflection calls so
that the argument copy is done in Go using normal bulk write barriers.
The one difficulty with this approach is that calling into Go requires
putting arguments on the stack, but the call* functions "donate" their
entire stack frame to the called function. We can get away with this
now because the copy avoids using the stack and has copied the results
out before we clobber the stack frame to call into the write barrier.
The solution in this CL is to call another function, passing arguments
in registers instead of on the stack, and let that other function
reserve more stack space and setup the arguments for the runtime.
This approach seemed to work out the best. I also tried making the
call* functions reserve 32 extra bytes of frame for the write barrier
arguments and adjust SP up by 32 bytes around the call. However, even
with the necessary changes to the assembler to correct the spdelta
table, the runtime was still having trouble with the frame layout (and
the changes to the assembler caused many other things that do strange
things with the SP to fail to assemble). The approach I took doesn't
require any funny business with the SP.
Updates #17503.
Change-Id: Ie2bb0084b24d6cff38b5afb218b9e0534ad2119e
Reviewed-on: https://go-review.googlesource.com/31655
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The logic for saving the list of packages was not always
preferring to keep error messages around correctly.
The missed error led to an internal consistency failure later.
Fixes#17119.
Change-Id: I9723b5d2518c25e2cac5249e6a7b907be95b521c
Reviewed-on: https://go-review.googlesource.com/31812
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Quentin Smith <quentin@golang.org>
If we leave it for compilation sometimes the error appears first
in derived vendor paths, without any indication where they came from.
This is better.
$ go1.7 build canonical/d
cmd/go/testdata/src/canonical/a/a.go:3: non-canonical import path "canonical/a//vendor/c" (should be "canonical/a/vendor/c")
cmd/go/testdata/src/canonical/a/a.go:3: can't find import: "canonical/a//vendor/c"
$ go build canonical/d
package canonical/d
imports canonical/b
imports canonical/a/: non-canonical import path: "canonical/a/" should be "canonical/a"
$
Fixes#16954.
Change-Id: I315ccec92a00d98a08c139b3dc4e17dbc640edd0
Reviewed-on: https://go-review.googlesource.com/31668
Reviewed-by: Quentin Smith <quentin@golang.org>
This is not strictly illegal but it probably should be (too late)
and doesn't mean what it looks like it means:
the second key-value pair has the key ",xml".
Fixes#14466.
Change-Id: I174bccc23fd28affeb87f57f77c6591634ade641
Reviewed-on: https://go-review.googlesource.com/32031
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Quentin Smith <quentin@golang.org>
This CL introduces some minor changes to match rules more closely
to the instructions they are targeting. s390x logical operation
with immediate instructions typically leave some bits in the
target register unchanged. This means for example that an XOR
with -1 requires 2 instructions. It is better in cases such as
this to create a constant and leave it visible to the compiler
so that it can be reused rather than hiding it in the assembler.
This CL also tweaks the rules a bit to ensure that constants are
folded when possible.
Change-Id: I1c6dee31ece00fc3c5fdf6a24f1abbc91dd2db2a
Reviewed-on: https://go-review.googlesource.com/31754
Reviewed-by: Keith Randall <khr@golang.org>
Currently any warning will make dist fail because the
text will be considered as part of the package list.
Change-Id: I09a14089cd0448c3779e2f767e9356fe3325d8d9
Reviewed-on: https://go-review.googlesource.com/32111
TryBot-Result: Gobot Gobot <gobot@golang.org>
Run-TryBot: Andrew Gerrand <adg@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
In the situation where the Client.Jar is set and the Request.Header
has cookies manually inserted, the redirect logic needs to be
able to apply changes to cookies from "Set-Cookie" headers to both
the Jar and the manually inserted Header cookies.
Since Header cookies lack information about the original domain
and path, the logic in this CL simply removes cookies from the
initial Header if any subsequent "Set-Cookie" matches. Thus,
in the event of cookie conflicts, the logic preserves the behavior
prior to change made in golang.org/cl/28930.
Fixes#17494
Updates #4800
Change-Id: I645194d9f97ff4d95bd07ca36de1d6cdf2f32429
Reviewed-on: https://go-review.googlesource.com/31435
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Now that sweeping and span marking use the sweep list, there's no need
for the work.spans snapshot of the allspans list. This change
eliminates the few remaining uses of it, which are either dead code or
can use allspans directly, and removes work.spans and its support
functions.
Change-Id: Id5388b42b1e68e8baee853d8eafb8bb4ff95bb43
Reviewed-on: https://go-review.googlesource.com/30537
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Currently markrootSpans iterates over all spans ever allocated to find
the in-use spans. Since we now have a list of in-use spans, change it
to iterate over that instead.
This, combined with the previous change, fixes#9265. Before these two
changes, blowing up the heap to 8GB and then shrinking it to a 0MB
live set caused the small-heap portion of the test to run 60x slower
than without the initial blowup. With these two changes, the time is
indistinguishable.
No significant effect on other benchmarks.
Change-Id: I4a27e533efecfb5d18cba3a87c0181a81d0ddc1e
Reviewed-on: https://go-review.googlesource.com/30536
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Currently sweeping walks the list of all spans, which means the work
in sweeping is proportional to the maximum number of spans ever used.
If the heap was once large but is now small, this causes an
amortization failure: on a small heap, GCs happen frequently, but a
full sweep still has to happen in each GC cycle, which means we spent
a lot of time in sweeping.
Fix this by creating a separate list consisting of just the in-use
spans to be swept, so sweeping is proportional to the number of in-use
spans (which is proportional to the live heap). Specifically, we
create two lists: a list of unswept in-use spans and a list of swept
in-use spans. At the start of the sweep cycle, the swept list becomes
the unswept list and the new swept list is empty. Allocating a new
in-use span adds it to the swept list. Sweeping moves spans from the
unswept list to the swept list.
This fixes the amortization problem because a shrinking heap moves
spans off the unswept list without adding them to the swept list,
reducing the time required by the next sweep cycle.
Updates #9265. This fix eliminates almost all of the time spent in
sweepone; however, markrootSpans has essentially the same bug, so now
the test program from this issue spends all of its time in
markrootSpans.
No significant effect on other benchmarks.
Change-Id: Ib382e82790aad907da1c127e62b3ab45d7a4ac1e
Reviewed-on: https://go-review.googlesource.com/30535
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Currently we set the len and cap of h.spans to the full reserved
region of the address space and track the actual mapped region
separately in h.spans_mapped. Since we have both the len and cap at
our disposal, change things so len(h.spans) tracks how much of the
spans array is mapped and eliminate h.spans_mapped. This simplifies
mheap and means we'll get nice "index out of bounds" exceptions if we
do try to go off the end of the spans rather than a SIGSEGV.
Change-Id: I8ed9a1a9a844d90e9fd2e269add4704623dbdfe6
Reviewed-on: https://go-review.googlesource.com/30533
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Like h_allspans and mheap_.allspans, these were two ways of referring
to the spans array from when the runtime was split between C and Go.
Clean this up by making mheap_.spans a slice and eliminating h_spans.
Change-Id: I3aa7038d53c3a4252050aa33e468c48dfed0b70e
Reviewed-on: https://go-review.googlesource.com/30532
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
This was necessary in the C days when allspans was an mspan**, but now
that allspans is a Go slice, this is redundant with len(allspans) and
we can use range loops over allspans.
Change-Id: Ie1dc39611e574e29a896e01690582933f4c5be7e
Reviewed-on: https://go-review.googlesource.com/30531
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
These are two ways to refer to the allspans array that hark back to
when the runtime was split between C and Go. Clean this up by making
mheap_.allspans a slice and eliminating h_allspans.
Change-Id: Ic9360d040cf3eb590b5dfbab0b82e8ace8525610
Reviewed-on: https://go-review.googlesource.com/30530
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
When the compiler insert write barriers, the frontend makes
conservative decisions at an early stage. This may have false
positives which result in write barriers for stack writes.
A new phase, writebarrier, is added to the SSA backend, to delay
the decision and eliminate false positives. The frontend still
makes conservative decisions. When building SSA, instead of
emitting runtime calls directly, it emits WB ops (StoreWB,
MoveWB, etc.), which will be expanded to branches and runtime
calls in writebarrier phase. Writes to static locations on stack
are detected and write barriers are removed.
All write barriers of stack writes found by the script from
issue #17330 are eliminated (except two false positives).
Fixes#17330.
Change-Id: I9bd66333da9d0ceb64dcaa3c6f33502798d1a0f8
Reviewed-on: https://go-review.googlesource.com/31131
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
The runtime traceback code assumes non-empty frame has link
link register saved on LR architectures. Make sure it is so in
the assember.
Also make sure that LR is stored before update SP, so the traceback
code will not see a half-updated stack frame if a signal comes
during the execution of function prologue.
Fixes#17381.
Change-Id: I668b04501999b7f9b080275a2d1f8a57029cbbb3
Reviewed-on: https://go-review.googlesource.com/31760
Reviewed-by: Michael Munday <munday@ca.ibm.com>
Update the ppc64x disassembly code for use by objdump
from golang.org/x/arch/ppc64/ppc64asm commit fcea5ea.
Enable the objdump testcase for external linking on ppc64le
make a minor fix to the expected output.
Fixes#17447
Change-Id: I769cc7f8bfade594690a476dfe77ab33677ac03b
Reviewed-on: https://go-review.googlesource.com/32015
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
For historical reasons, the go/doc package does not include
the methods within an interface as part of the documented
methods for that type. Thus,
go doc ast.Node.Pos
gives an incorrect and confusing error message:
doc: no method Node.Pos in package go/ast
This CL does some dirty work to dig down to the methods
so interface methods now present their documentation:
% go doc ast.node.pos
func Pos() token.Pos // position of first character belonging to the node
%
It must largely sidestep the doc package to do this, which
is a shame. Perhaps things will improve there one day.
The change does not handle embeddings, and in principle the
same approach could be done for struct fields, but that is also
not here yet. But this CL fixes the thing that was bugging me.
Change-Id: Ic10a91936da96f54ee0b2f4a4fe4a8c9b93a5b4a
Reviewed-on: https://go-review.googlesource.com/31852
Reviewed-by: Robert Griesemer <gri@golang.org>
Instead of generating typelink symbols in the compiler
mark types that should have typelinks with a flag.
The linker detects this flag and adds the marked types
to the typelink table.
name old s/op new s/op delta
LinkCmdCompile 0.27 ± 6% 0.25 ± 6% -6.93% (p=0.000 n=97+98)
LinkCmdGo 0.30 ± 5% 0.29 ±10% -4.22% (p=0.000 n=97+99)
name old MaxRSS new MaxRSS delta
LinkCmdCompile 112k ± 3% 106k ± 2% -4.85% (p=0.000 n=100+100)
LinkCmdGo 107k ± 3% 103k ± 3% -3.00% (p=0.000 n=100+100)
Change-Id: Ic95dd4b0101e90c1fa262c9c6c03a2028d6b3623
Reviewed-on: https://go-review.googlesource.com/31772
Run-TryBot: Shahar Kohanim <skohanim@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The condition to determine if any further iterations are needed is
evaluated to false in case it encounters a NaN. Instead, flip the
condition to keep looping until the factor is greater than the machine
roundoff error.
Updates #17577
Change-Id: I058abe73fcd49d3ae4e2f7b33020437cc8f290c3
Reviewed-on: https://go-review.googlesource.com/31952
Reviewed-by: Robert Griesemer <gri@golang.org>
In sinit.go, gdata can already handle strings and complex, so no
reason to handle them separately.
In obj.go, inline gdatastring and gdatacomplex into gdata, since it's
the only caller. Allows extracting out the common Linksym calls.
Passes toolstash -cmp.
Change-Id: I3cb18d9b4206a8a269c36e0d30a345d8e6caba1f
Reviewed-on: https://go-review.googlesource.com/31498
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
It no longer exists as of CL 31010.
Change-Id: Idd61f392544cad8b3f3f8d984dc5c953b473e2e5
Reviewed-on: https://go-review.googlesource.com/31934
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Some original shift opcodes for ppc64x expected an operand to be
a mask instead of a shift count, preventing some valid shift counts
from being written.
This adds new opcodes for shifts where needed, using mnemonics that
match the ppc64 asm and allowing the assembler to accept the full set
of valid shift counts.
Fixes#15016
Change-Id: Id573489f852038d06def279c13fd0523736878a7
Reviewed-on: https://go-review.googlesource.com/31853
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com>
Reviewed-by: David Chase <drchase@google.com>
These are emulated by the assembler and we don't need them.
Change-Id: I2b07c5315a5b642fdb5e50b468453260ae121164
Reviewed-on: https://go-review.googlesource.com/31758
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Before go supported buildmode=shared ·f symbols used to be defined
only when they were used. In order to solve #11480 the strategy
was changed to have these symbols defined on declaration which is
less efficient and generates many unneeded symbols.
With this change the best strategy is chosen for each situation,
improving static linking time:
name old s/op new s/op delta
LinkCmdCompile 0.27 ± 5% 0.25 ± 6% -8.22% (p=0.000 n=98+96)
LinkCmdGo 0.30 ± 6% 0.29 ± 8% -5.03% (p=0.000 n=95+99)
name old MaxRSS new MaxRSS delta
LinkCmdCompile 107k ± 2% 98k ± 3% -8.32% (p=0.000 n=99+100)
LinkCmdGo 106k ± 3% 104k ± 3% -1.94% (p=0.000 n=99+100)
Change-Id: I965eeee30541e724fd363804adcd6fda10f965a4
Reviewed-on: https://go-review.googlesource.com/31031
Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
In general, these functions cannot behave correctly when given a
hostname, because a hostname may represent multiple IP addresses, and
first(isIPv4) chooses at most one.
Updates #9334
Change-Id: Icfb629f84af4d976476385a3071270253c0000b1
Reviewed-on: https://go-review.googlesource.com/31931
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Looking at the kernel sources, I don't see how this is possible.
But obviously it is. Just try again.
Fixes#17161.
Change-Id: Iea7d53f7cf75944792d2f75a0d07129831c7bcdb
Reviewed-on: https://go-review.googlesource.com/31823
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The old code leaves garbages in a temporary directory because it
cannot remove the current working directory on windows.
The new code changes the directory before calling os.Remove.
Furthermore, the old code assumes that ioutil.TempDir (os.TempDir)
doesn't return a relative path nor an UNC path.
If it isn't the case, the new code calls t.Fatal earlier for preventing
ambiguous errors.
Finally, the old code reassigns the variable which is used by the defer
function. It could cause unexpected results, so avoid that.
Change-Id: I5fc3902059ecaf18dc1341ecc4979d1206034cd7
Reviewed-on: https://go-review.googlesource.com/31790
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Updates #15345
Change-Id: I447d133512e99a9900928a910e161a85db6e8b75
Reviewed-on: https://go-review.googlesource.com/31792
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
It appears to be a vestigial holding ground for bugs.
But we have an issue tracker, and #1909 is there and open.
Change-Id: I912ff222a24c51fab483be0c67dad534f5a84488
Reviewed-on: https://go-review.googlesource.com/31859
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
CL 31468 added TestLookupNonLDH, which was failing on Plan 9,
because LookupHost was expecting to return errNoSuchHost
on DNS resolution failure, while Plan 9 returned the
"dns failure" string.
In the Plan 9 implementation of lookupHost, we now return
errNoSuchHost instead of the "dns failure" string, so
the behavior is more consistant with other operating systems.
Fixes#17568.
Change-Id: If64f580dc0626a4a4f19e5511ba2ca5daff5f789
Reviewed-on: https://go-review.googlesource.com/31873
Run-TryBot: David du Colombier <0intro@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Russ Cox
Adam Langley
Keith Randall
Josh Bleecher Snyder
Cherry Zhang
Vladimir Stefanovic
Nigel Tao
Chris McGee
Klaus Post
Hiroshi Ioka
Bill O'Farrell
Ben Burkert
Joe Tsai
Robert Griesemer
Brad Fitzpatrick
Jaana Burcu Dogan
Carl Johnson
Than McIntosh
David Chase
Mikio Hara
Austin Clements
David du Colombier
Rob Pike
Filippo Valsorda
Michael Munday
Alexander Morozov
Francesc Campoy
Matthew Dempsky
Tom Bergan
Lynn Boger
shaharko
Mohit Agarwal
Martin Möhrmann
Paul Marks
Ian Lance Taylor
Alex Brainman