We want to adjust the DIV calling convention to use m,
and usleep can be called without an m, so switch to a
multiplication by the reciprocal (and test).
Step toward a fix for #6699 and #10486.
Change-Id: Iccf76a18432d835e48ec64a2fa34a0e4d6d4b955
Reviewed-on: https://go-review.googlesource.com/12898
Reviewed-by: Ian Lance Taylor <iant@golang.org>
If a function is large enough to need to flush the constant pool
mid-function, the line number assignment code was forcing the
line numbers not just for the constant pool but for all the instructions
that follow it. This made the line number information completely
wrong for all but the beginning of large functions on arm.
Same problem in code copied into arm64.
This broke runtime/trace's TestTraceSymbolize.
Fixes arm build.
Change-Id: I84d9fb2c798c4085f69b68dc766ab4800c7a6ca4
Reviewed-on: https://go-review.googlesource.com/12894
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
This allows running a cross-compile like
GOOS=darwin GOARCH=arm go build std
to check that everything builds.
Otherwise there is a redefinition error because both
root_nocgo_darwin.go and root_darwin_armx.go
supply initSystemRoots.
Change-Id: Ic95976b2b698d28c629bfc93d8dac0048b023578
Reviewed-on: https://go-review.googlesource.com/12897
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The test expects the dial to take 1.0 seconds
on Windows and allows it to go to 1.095 seconds.
That's far too optimistic.
Recent failures are reporting roughly 1.2 seconds.
Let it have 1.5.
Change-Id: Id69811ccb65bf4b4c159301a2b4767deb6ee8d28
Reviewed-on: https://go-review.googlesource.com/12895
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Urge users of math/rand to consider using crypto/rand when doing
security-sensitive work.
Related to issue #11871. While we haven't reached consensus on how
to make the package inherently safer, everyone agrees that the docs
for math/rand can be improved.
Change-Id: I576a312e51b2a3445691da6b277c7b4717173197
Reviewed-on: https://go-review.googlesource.com/12900
Reviewed-by: Rob Pike <r@golang.org>
For the android/arm builder.
Change-Id: Iad4881689223cd6479870da9541524a8cc458cce
Reviewed-on: https://go-review.googlesource.com/12859
Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
Fixes arm64 builder crash.
The bug is possible on all architectures; you just have to get lucky
and hit a preemption or a stack growth on entry to assertE2I2.
The test stacks the deck.
Change-Id: I8419da909b06249b1ad15830cbb64e386b6aa5f6
Reviewed-on: https://go-review.googlesource.com/12890
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
It says to disable until #7564 is fixed. It was fixed in April 2014.
Change-Id: I9bebfe96802bafdd2d1a0a47591df346d91b000c
Reviewed-on: https://go-review.googlesource.com/12858
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Also make invalidptr control the recently added GC pointer check,
as documented.
Change-Id: Iccfdf49480219d12be8b33b8f03d8312d8ceabed
Reviewed-on: https://go-review.googlesource.com/12857
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
The skips added in CL 12579, based on incorrect time stamps,
should be sufficient to identify and exclude all the time-related
flakiness on these systems.
If there is other flakiness, we want to find out.
For #10512.
Change-Id: I5b588ac1585b2e9d1d18143520d2d51686b563e3
Reviewed-on: https://go-review.googlesource.com/12746
Reviewed-by: Austin Clements <austin@google.com>
Nearly all the flaky failures we've seen in trace tests have been
due to the use of time stamps to determine relative event ordering.
This is tricky for many reasons, including:
- different cores might not have exactly synchronized clocks
- VMs are worse than real hardware
- non-x86 chips have different timer resolution than x86 chips
- on fast systems two events can end up with the same time stamp
Stop trying to make time reliable. It's clearly not going to be for Go 1.5.
Instead, record an explicit event sequence number for ordering.
Using our own counter solves all of the above problems.
The trace still contains time stamps, of course. The sequence number
is just used for ordering.
Should alleviate #10554 somewhat. Then tickDiv can be chosen to
be a useful time unit instead of having to be exact for ordering.
Separating ordering and time stamps lets the trace parser diagnose
systems where the time stamp order and actual order do not match
for one reason or another. This CL adds that check to the end of
trace.Parse, after all other sequence order-based checking.
If that error is found, we skip the test instead of failing it.
Putting the check in trace.Parse means that cmd/trace will pick
up the same check, refusing to display a trace where the time stamps
do not match actual ordering.
Using net/http's BenchmarkClientServerParallel4 on various CPU counts,
not tracing vs tracing:
name old time/op new time/op delta
ClientServerParallel4 50.4µs ± 4% 80.2µs ± 4% +59.06% (p=0.000 n=10+10)
ClientServerParallel4-2 33.1µs ± 7% 57.8µs ± 5% +74.53% (p=0.000 n=10+10)
ClientServerParallel4-4 18.5µs ± 4% 32.6µs ± 3% +75.77% (p=0.000 n=10+10)
ClientServerParallel4-6 12.9µs ± 5% 24.4µs ± 2% +89.33% (p=0.000 n=10+10)
ClientServerParallel4-8 11.4µs ± 6% 21.0µs ± 3% +83.40% (p=0.000 n=10+10)
ClientServerParallel4-12 14.4µs ± 4% 23.8µs ± 4% +65.67% (p=0.000 n=10+10)
Fixes#10512.
Change-Id: I173eecf8191e86feefd728a5aad25bf1bc094b12
Reviewed-on: https://go-review.googlesource.com/12579
Reviewed-by: Austin Clements <austin@google.com>
Otherwise the GC may see uninitialized memory there,
which might be old pointers that are retained, or it might
trigger the invalid pointer check.
Fixes#11907.
Change-Id: I67e306384a68468eef45da1a8eb5c9df216a77c0
Reviewed-on: https://go-review.googlesource.com/12852
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Lots and lots of ops!
Also XOR for good measure.
Add a pass to the compiler generator to check that all of the
architecture-specific opcodes are handled by genValue. We will
catch any missing ones if we come across them during compilation,
but probably better to catch them statically.
Change-Id: Ic4adfbec55c8257f88117bc732fa664486262868
Reviewed-on: https://go-review.googlesource.com/12813
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
The last time we tried this, linux/arm64 broke.
The series of CLs leading to this one fixes that problem.
Let's try again.
Fixes#9880.
Change-Id: I67bc1d959175ec972d4dcbe4aa6f153790f74251
Reviewed-on: https://go-review.googlesource.com/12849
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
The layout code has to date insisted on stack frames that are 16-aligned
including the saved LR, and it ensured this by growing the frame itself.
This breaks code that refers to values near the top of the frame by positive
offset from SP, and in general it's too magical: if you see TEXT xxx, $N,
you expect that the frame size is actually N, not sometimes N and sometimes N+8.
This led to a serious bug in the compiler where ambiguously live values
were not being zeroed correctly, which in turn triggered an assertion
in the GC about finding only valid pointers. The compiler has been
fixed to always emit aligned frames, and the hand-written assembly
has also been fixed.
Now that everything is aligned, make unaligned an error instead of
something to "fix" silently.
For #9880.
Change-Id: I05f01a9df174d64b37fa19b36a6b6c5f18d5ba2d
Reviewed-on: https://go-review.googlesource.com/12848
Reviewed-by: Austin Clements <austin@google.com>
The nosplit stack overflow checks were confused about morestack.
The comment about not having correct SP information at the call
to morestack was true, but that was a real bug, not something to
work around. I fixed that problem in CL 12144. With that fixed,
no need to special-case morestack in the way done here.
This cleanup and simplification of the code was the first step
to fixing a bug that happened when I started working on the
arm64 frame size adjustments, but the cleanup was sufficient
to make the bug go away.
For #9880.
Change-Id: I16b69a5c16b6b8cb4090295d3029c42d606e3b9b
Reviewed-on: https://go-review.googlesource.com/12846
Reviewed-by: Austin Clements <austin@google.com>
arm64 requires either no stack frame or a frame with a size that is 8 mod 16
(adding the saved LR will make it 16-aligned).
The cmd/internal/obj/arm64 has been silently aligning frames, but it led to
a terrible bug when the compiler and obj disagreed on the frame size,
and it's just generally confusing, so we're going to make misaligned frames
an error instead of something that is silently changed.
This CL prepares by updating assembly files.
Note that the changes in this CL are already being done silently by
cmd/internal/obj/arm64, so there is no semantic effect here,
just a clarity effect.
For #9880.
Change-Id: Ibd6928dc5fdcd896c2bacd0291bf26b364591e28
Reviewed-on: https://go-review.googlesource.com/12845
Reviewed-by: Austin Clements <austin@google.com>
If the compiler doesn't do it, cmd/internal/obj/arm64 will,
and that will break the zeroing of ambiguously live values
done in zerorange, which in turn produces uninitialized
pointer cells that the GC trips over.
For #9880.
Change-Id: Ice97c30bc8b36d06b7b88d778d87fab8e1827fdc
Reviewed-on: https://go-review.googlesource.com/12847
Reviewed-by: Austin Clements <austin@google.com>
From compiling go there were 761 functions where OR was needed.
Change-Id: Ied8bf59cec50a3175273387bc7416bd042def6d8
Reviewed-on: https://go-review.googlesource.com/12766
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
This adds a GCCPUFraction field to MemStats that reports the
cumulative fraction of the program's execution time spent in the
garbage collector. This is equivalent to the utilization percent shown
in the gctrace output and makes this available programmatically.
This does make one small effect on the gctrace output: we now report
the duration of mark termination up to just before the final
start-the-world, rather than up to just after. However, unlike
stop-the-world, I don't believe there's any way that start-the-world
can block, so it should take negligible time.
While there are many statistics one might want to expose via MemStats,
this is one of the few that will undoubtedly remain meaningful
regardless of future changes to the memory system.
The diff for this change is larger than the actual change. Mostly it
lifts the code for computing the GC CPU utilization out of the
debug.gctrace path.
Updates #10323.
Change-Id: I0f7dc3fdcafe95e8d1233ceb79de606b48acd989
Reviewed-on: https://go-review.googlesource.com/12844
Reviewed-by: Russ Cox <rsc@golang.org>
Currently we only capture GC phase transition times if
debug.gctrace>0, but we're about to compute GC CPU utilization
regardless of whether debug.gctrace is set, so we need these
regardless of debug.gctrace.
Change-Id: If3acf16505a43d416e9a99753206f03287180660
Reviewed-on: https://go-review.googlesource.com/12843
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
The following sequence of events can lead to the runtime attempting an
out-of-bounds access on a stack barrier slice:
1. A SIGPROF comes in on a thread while the G on that thread is in
_Gsyscall. The sigprof handler calls gentraceback, which saves a
local copy of the G's stkbar slice. Currently the G has no stack
barriers, so this slice is empty.
2. On another thread, the GC concurrently scans the stack of the
goroutine being profiled (it considers it stopped because it's in
_Gsyscall) and installs stack barriers.
3. Back on the sigprof thread, gentraceback comes across a stack
barrier in the stack and attempts to look it up in its (zero
length) copy of G's old stkbar slice, which causes an out-of-bounds
access.
This commit fixes this by adding a simple cas spin to synchronize the
SIGPROF handler with stack barrier insertion.
In general I would prefer that this synchronization be done through
the G status, since that's how stack scans are otherwise synchronized,
but adding a new lock is a much smaller change and G statuses are full
of subtlety.
Fixes#11863.
Change-Id: Ie89614a6238bb9c6a5b1190499b0b48ec759eaf7
Reviewed-on: https://go-review.googlesource.com/12748
Reviewed-by: Russ Cox <rsc@golang.org>
The scheduler, work buffer's dispose, and write barriers
can conspire to hide the a pointer from the GC's concurent
mark phase. If this pointer is the only path to a large
amount of marking the STW mark termination phase may take
a lot of time.
Consider the following:
1) dispose places a work buffer on the partial queue
2) the GC is busy so it does not immediately remove and
process the work buffer
3) the scheduler runs a mutator whose write barrier dequeues the
work buffer from the partial queue so the GC won't see it
This repeats until the GC reaches the mark termination
phase where the GC finally discovers the pointer along
with a lot of work to do.
This CL fixes the problem by having the mutator
dispose of the buffer to the full queue instead of
the partial queue. Since the write buffer never asks for full
buffers the conspiracy described above is not possible.
Updates #11694.
Change-Id: I2ce832f9657a7570f800e8ce4459cd9e304ef43b
Reviewed-on: https://go-review.googlesource.com/12840
Reviewed-by: Austin Clements <austin@google.com>
These are the old assemblers written in C, and now they are
not needed.
Fixes#10510.
Change-Id: Id9337ffc8eccfd93c84b2e23f427fb1a576b543d
Reviewed-on: https://go-review.googlesource.com/12784
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
At this stage, dist is only building go_bootstrap as cmd/compile and
the rest of the Go toolchain has already been built.
Change-Id: I6f99fa00ff1d3585e215f4ce84d49344c4fcb8a5
Reviewed-on: https://go-review.googlesource.com/12779
Reviewed-by: Russ Cox <rsc@golang.org>
With this, all non-float, non-complex
binary ops found in the standard library
are implemented.
Change-Id: I6087f115229888c0dce10ab35db3fd36a0e0a8b1
Reviewed-on: https://go-review.googlesource.com/12799
Reviewed-by: Keith Randall <khr@golang.org>
Together with teaching SSA to generate static data,
this fixes the encoding/pem and hash/adler32 tests.
Change-Id: I75f81f6c995dcb9c6d99bd3acda94a4feea8b87b
Reviewed-on: https://go-review.googlesource.com/12791
Reviewed-by: Keith Randall <khr@golang.org>
The existing backend recognizes special
assignment statements as being implementable
with static data rather than code.
Unfortunately, it assumes that it is in the middle
of codegen; it emits data and modifies the AST.
This does not play well with SSA's two-phase
bootstrapping approach, in which we attempt to
compile code but fall back to the existing backend
if something goes wrong.
To work around this:
* Add the ability to inquire about static data
without side-effects.
* Save the static data required for a function.
* Emit that static data during SSA codegen.
Change-Id: I2e8a506c866ea3e27dffb597095833c87f62d87e
Reviewed-on: https://go-review.googlesource.com/12790
Reviewed-by: Keith Randall <khr@golang.org>
For integer types less than a machine register, we have to decide
what the invariants are for the high bits of the register. We used
to set the high bits to the correct extension (sign or zero, as
determined by the type) of the low bits.
This CL makes the compiler ignore the high bits of the register
altogether (they are junk).
On this plus side, this means ops that generate subword results don't
have to worry about correctly extending them. On the minus side,
ops that consume subword arguments have to deal with the input
registers not being correctly extended.
For x86, this tradeoff is probably worth it. Almost all opcodes
have versions that use only the correct subword piece of their
inputs. (The one big exception is array indexing.) Not many opcodes
can correctly sign extend on output.
For other architectures, the tradeoff is probably not so clear, as
they don't have many subword-safe opcodes (e.g. 16-bit compare,
ignoring the high 16/48 bits). Fortunately we can decide whether
we do this per-architecture.
For the machine-independent opcodes, we pretend that the "register"
size is equal to the type width, so sign extension is immaterial.
Opcodes that care about the signedness of the input (e.g. compare,
right shift) have two different variants.
Change-Id: I465484c5734545ee697afe83bc8bf4b53bd9df8d
Reviewed-on: https://go-review.googlesource.com/12600
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Russ Cox fixed this issue for other systems
in CL 12026, but the Plan 9 part was forgotten.
Fixes#11656.
Change-Id: I91c033687987ba43d13ad8f42e3fe4c7a78e6075
Reviewed-on: https://go-review.googlesource.com/12762
Reviewed-by: Russ Cox <rsc@golang.org>
The only slice/interface comparisons that reach
the backend are comparisons to nil.
Funcs, maps, and channels are references types,
so pointer equality is enough.
Change-Id: I60a71da46a36202e9bd62ed370ab7d7f2e2800e7
Reviewed-on: https://go-review.googlesource.com/12715
Reviewed-by: Keith Randall <khr@golang.org>
Before this patch there was only partial support for ANDQconst
which was not lowered. This patch added support for AND operations
for all bit sizes and signs.
Change-Id: I3a6b2cddfac5361b27e85fcd97f7f3537ebfbcb6
Reviewed-on: https://go-review.googlesource.com/12761
Reviewed-by: Keith Randall <khr@golang.org>
The function is already defined between syscall_solaris.go and
syscall2_solaris.go.
Change-Id: I034baf7c8531566bebfdbc5a4061352cbcc31449
Reviewed-on: https://go-review.googlesource.com/12773
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reformat some help messages to stay within 80 characters.
Fixes#11840.
Change-Id: Iebafcb616f202ac44405e5897097492a79a51722
Reviewed-on: https://go-review.googlesource.com/12514
Reviewed-by: Rob Pike <r@golang.org>
This change prevents DNS query results using domain search list
overtaking results not using the list unconditionally, which only
happens when using builtin DNS stub resolver.
The previous internal lookup function lookup is split into lookup and
goLookupIPOrder for iteration over a set of names: FQDN or absolute
FQDN, with domain label suffixes in search list, without domain label
suffixes, and for concurrent A and AAAA record queries.
Fixes#11081.
Change-Id: I9ff0640f69276e372d97e709b149ed5b153e8601
Reviewed-on: https://go-review.googlesource.com/10836
Reviewed-by: Russ Cox <rsc@golang.org>
Rename test name from Http to HTTP, and fix some style nits.
Change-Id: I00fe1cecd69ca2f50be86a76ec90031c2f921707
Reviewed-on: https://go-review.googlesource.com/12760
Reviewed-by: Andrew Gerrand <adg@golang.org>
A further attempt to fix raiseproc on Solaris.
Change-Id: I8d8000d6ccd0cd9f029ebe1f211b76ecee230cd0
Reviewed-on: https://go-review.googlesource.com/12771
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
I forgot that the libc raise function only sends the signal to the
current thread. We need to actually use kill and getpid here, as we
do on other systems.
Change-Id: Iac34af822c93468bf68cab8879db3ee20891caaf
Reviewed-on: https://go-review.googlesource.com/12704
Reviewed-by: Russ Cox <rsc@golang.org>
I've also changed TestDialSerialAsyncSpuriousConnection for consistency,
although it always computes a finalDeadline of zero.
Note that #11225 is the root cause of the socket leak; this just hides
it from the unit test by restoring the shorter timeout.
Fixes#11878
Change-Id: Ie0037dd3bce6cc81d196765375489f8c61be74c2
Reviewed-on: https://go-review.googlesource.com/12712
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Paul Marks <pmarks@google.com>
Fixes#11436.
Change-Id: I5c4455e9b13b478838f23ac31e6343672dfc60af
Reviewed-on: https://go-review.googlesource.com/12143
Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Until cl/12721 and cl/12574, all standard library tests included
runtime/cgo on darwin/arm64 by virtue of package os including it. Now
that is no longer true, runtime/cgo needs to be added by the go tool
just as it is for darwin/arm. (This installs the Mach exception
handler used to properly handle EXC_BAD_ACCESS.)
Fixes#11901
Change-Id: I991525f46eca5b0750b93595579ebc0ff10e47eb
Reviewed-on: https://go-review.googlesource.com/12723
Reviewed-by: Russ Cox <rsc@golang.org>
The new Token API is meant to sit on the side of the Decoder,
so that you only get the new code (and any latent bugs in it)
if you are actively using the Token API.
The unconditional use of dec.peek in dec.tokenPrepareForDecode
violates that intention.
Change tokenPrepareForDecode not to call dec.peek unless needed
(because the Token API has advanced the state).
This restores the old code path behavior, no peeking allowed.
I checked by patching in the new tests from CL 12726 that
this change suffices to "fix" the error handling bug in dec.peek.
Obviously that bug should be fixed too, but the point is that
with this CL, bugs in dec.peek do not affect plain use of Decode
or Unmarshal.
I also checked by putting a panic in dec.peek that the only
tests that now invoke peek are:
TestDecodeInStream
ExampleDecoder_Token
ExampleDecoder_Decode_stream
and those tests all invoke dec.Token directly.
Change-Id: I0b242d0cb54a9c830548644670dc5ab5ccef69f2
Reviewed-on: https://go-review.googlesource.com/12740
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Peter Waldschmidt <peter@waldschmidt.com>
Rules may span multiple lines,
but if we're still unbalanced at the
end of the file, something is wrong.
I write unbalanced rules depressingly often.
Change-Id: Ibd04aa06539e2a0ffef73bb665febf3542fd11f1
Reviewed-on: https://go-review.googlesource.com/12710
Reviewed-by: Keith Randall <khr@golang.org>
This mimics the way the old backend
compiles OCALLMETH.
Change-Id: I635c8e7a48c8b5619bd837f78fa6eeba83a57b2f
Reviewed-on: https://go-review.googlesource.com/12549
Reviewed-by: Keith Randall <khr@golang.org>
From https://github.com/golang/go/issues/11745#issuecomment-123555313
this implements option (b), having the server pause slightly after
sending the final response on a TCP connection when we're about to close
it when we know there's a request body outstanding. This biases the
client (which might not be Go) to prefer our response header over the
request body write error.
Updates #11745
Change-Id: I07cb0b74519d266c8049d9e0eb23a61304eedbf8
Reviewed-on: https://go-review.googlesource.com/12658
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Seems like the simplest solution for 1.5. All the parts of the test
suite I can run on my current device (for which my exception handler
fix no longer works, apparently) pass without this code. I'll move it
into x/mobile/app.
Fixes#11884
Change-Id: I2da40c8c7b48a4c6970c4d709dd7c148a22e8727
Reviewed-on: https://go-review.googlesource.com/12721
Reviewed-by: Ian Lance Taylor <iant@golang.org>
If flushing a value from a register that might be used by the current
old-schedule value, save it to the home location.
This resolves the error that was changed from panic to unimplemented in
CL 12655.
Change-Id: If864be34abcd6e11d6117a061376e048a3e29b3a
Reviewed-on: https://go-review.googlesource.com/12682
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Currently we enter mark 2 by first flushing all existing gcWork caches
and then setting gcBlackenPromptly, which disables further gcWork
caching. However, if a worker or assist pulls a work buffer in to its
gcWork cache after that cache has been flushed but before caching is
disabled, that work may remain in that cache until mark termination.
If that work represents a heap bottleneck (e.g., a single pointer that
is the only way to reach a large amount of the heap), this can force
mark termination to do a large amount of work, resulting in a long
STW.
Fix this by reversing the order of these steps: first disable caching,
then flush all existing caches.
Rick Hudson <rlh> did the hard work of tracking this down. This CL
combined with CL 12672 and CL 12646 distills the critical parts of his
fix from CL 12539.
Fixes#11694.
Change-Id: Ib10d0a21e3f6170a80727d0286f9990df049fed2
Reviewed-on: https://go-review.googlesource.com/12688
Reviewed-by: Rick Hudson <rlh@golang.org>
Currently the GC coordinator enables GC assists at the same time it
enables background mark workers, after the concurrent scan phase is
done. However, this means a rapidly allocating mutator has the entire
scan phase during which to allocate beyond the heap trigger and
potentially beyond the heap goal with no back-pressure from assists.
This prevents the feedback system that's supposed to keep the heap
size under the heap goal from doing its job.
Fix this by enabling mutator assists during the scan phase. This is
safe because the write barrier is already enabled and globally
acknowledged at this point.
There's still a very small window between when the heap size reaches
the heap trigger and when the GC coordinator is able to stop the world
during which the mutator can allocate unabated. This allows *very*
rapidly allocator mutators like TestTraceStress to still occasionally
exceed the heap goal by a small amount (~20 MB at most for
TestTraceStress). However, this seems like a corner case.
Fixes#11677.
Change-Id: I0f80d949ec82341cd31ca1604a626efb7295a819
Reviewed-on: https://go-review.googlesource.com/12674
Reviewed-by: Russ Cox <rsc@golang.org>
Currently we hand-code a set of phases when draining is allowed.
However, this set of phases is conservative. The critical invariant is
simply that the write barrier must be enabled if we're draining.
Shortly we're going to enable mutator assists during the scan phase,
which means we may drain during the scan phase. In preparation, this
commit generalizes these assertions to check the fundamental condition
that the write barrier is enabled, rather than checking that we're in
any particular phase.
Change-Id: I0e1bec1ca823d4a697a0831ec4c50f5dd3f2a893
Reviewed-on: https://go-review.googlesource.com/12673
Reviewed-by: Russ Cox <rsc@golang.org>
Currently we clear both the mark 1 and mark 2 signals at the beginning
of concurrent mark. If either if these is clear, it acts as a signal
to the scheduler that it should start background workers. However,
this means that in the interim *between* mark 1 and mark 2, the
scheduler basically loops starting up new workers only to have them
return with nothing to do. In addition to harming performance and
delaying mutator work, this approach has a race where workers started
for mark 1 can mistakenly signal mark 2, causing it to complete
prematurely. This approach also interferes with starting assists
earlier to fix#11677.
Fix this by initially setting both mark 1 and mark 2 to "signaled".
The scheduler will not start background mark workers, though assists
can still run. When we're ready to enter mark 1, we clear the mark 1
signal and wait for it. Then, when we're ready to enter mark 2, we
clear the mark 2 signal and wait for it.
This structure also lets us deal cleanly with the situation where all
work is drained *prior* to the mark 2 wait, meaning that there may be
no workers to signal completion. Currently we deal with this using a
racy (and possibly incorrect) check for work in the coordinator itself
to skip the mark 2 wait if there's no work. This change makes the
coordinator unconditionally wait for mark completion and makes the
scheduler itself signal completion by slightly extending the logic it
already has to determine that there's no work and hence no use in
starting a new worker.
This is a prerequisite to fixing the remaining component of #11677,
which will require enabling assists during the scan phase. However, we
don't want to enable background workers until the mark phase because
they will compete with the scan. This change lets us use bgMark1 and
bgMark2 to indicate when it's okay to start background workers
independent of assists.
This is also a prerequisite to fixing #11694. It significantly reduces
the occurrence of long mark termination pauses in #11694 (from 64 out
of 1000 to 2 out of 1000 in one experiment).
Coincidentally, this also reduces the final heap size (and hence run
time) of TestTraceStress from ~100 MB and ~1.9 seconds to ~14 MB and
~0.4 seconds because it significantly shortens concurrent mark
duration.
Rick Hudson <rlh> did the hard work of tracking this down.
Change-Id: I12ea9ee2db9a0ae9d3a90dde4944a75fcf408f4c
Reviewed-on: https://go-review.googlesource.com/12672
Reviewed-by: Russ Cox <rsc@golang.org>
Currently, there are three ways to satisfy a GC assist: 1) the mutator
steals credit from background GC, 2) the mutator actually does GC
work, and 3) there is no more work available. 3 was never really
intended as a way to satisfy an assist, and it causes problems: there
are periods when it's expected that the GC won't have any work, such
as when transitioning from mark 1 to mark 2 and from mark 2 to mark
termination. During these periods, there's no back-pressure on rapidly
allocating mutators, which lets them race ahead of the heap goal.
For example, test/init1.go and the runtime/trace test both have small
reachable heaps and contain loops that rapidly allocate large garbage
byte slices. This bug lets these tests exceed the heap goal by several
orders of magnitude.
Fix this by forcing the assist (and hence the allocation) to block
until it can satisfy its debt via either 1 or 2, or the GC cycle
terminates.
This fixes one the causes of #11677. It's still possible to overshoot
the GC heap goal, but with this change the overshoot is almost exactly
by the amount of allocation that happens during the concurrent scan
phase, between when the heap passes the GC trigger and when the GC
enables assists.
Change-Id: I5ef4edcb0d2e13a1e432e66e8245f2bd9f8995be
Reviewed-on: https://go-review.googlesource.com/12671
Reviewed-by: Russ Cox <rsc@golang.org>
Currently it's possible for the GC assist to signal completion of the
mark phase, which puts the GC coordinator goroutine on the current P's
run queue, and then return to mutator code that delays until the next
forced preemption before actually yielding control to the GC
coordinator, dragging out completion of the mark phase. This delay can
be further exacerbated if the mutator makes other goroutines runnable
before yielding control, since this will push the GC coordinator on
the back of the P's run queue.
To fix this, this adds a Gosched to the assist if it completed the
mark phase. This immediately and directly yields control to the GC
coordinator. This already happens implicitly in the background mark
workers because they park immediately after completing the mark.
This is one of the reasons completion of the mark phase is being
dragged out and allowing the mutator to allocate without assisting,
leading to the large heap goal overshoot in issue #11677. This is also
a prerequisite to making the assist block when it can't pay off its
debt.
Change-Id: I586adfbecb3ca042a37966752c1dc757f5c7fc78
Reviewed-on: https://go-review.googlesource.com/12670
Reviewed-by: Russ Cox <rsc@golang.org>
Currently it's possible to perform GC work on a system stack or when
locks are held if there's an allocation that triggers an assist. This
is generally a bad idea because of the fragility of these contexts,
and it's incompatible with two changes we're about to make: one is to
yield after signaling mark completion (which we can't do from a
non-preemptible context) and the other is to make assists block if
there's no other way for them to pay off the assist debt.
This commit simply skips the assist if it's called from a
non-preemptible context. The allocation will still count toward the
assist debt, so it will be paid off by a later assist. There should be
little allocation from non-preemptible contexts, so this shouldn't
harm the overall assist mechanism.
Change-Id: I7bf0e6c73e659fe6b52f27437abf39d76b245c79
Reviewed-on: https://go-review.googlesource.com/12649
Reviewed-by: Russ Cox <rsc@golang.org>
When notetsleep_internal is called from notetsleepg, notetsleepg has
just given up the P, so write barriers are not allowed in
notetsleep_internal.
Change-Id: I1b214fa388b1ea05b8ce2dcfe1c0074c0a3c8870
Reviewed-on: https://go-review.googlesource.com/12647
Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Currently fractional and idle mark workers dispose of their gcWork
cache during mark 2 after incrementing work.nwait and after checking
whether there are any workers or any work available. This creates a
window for two races:
1) If the only remaining work is in this worker's gcWork cache, it
will see that there are no more workers and no more work on the
global lists (since it has not yet flushed its own cache) and
prematurely signal mark 2 completion.
2) After this worker has incremented work.nwait but before it has
flushed its cache, another worker may observe that there are no
more workers and no more work and prematurely signal mark 2
completion.
We can fix both of these by simply moving the cache flush above the
increment of nwait and the test of the completion condition.
This is probably contributing to #11694, though this alone is not
enough to fix it.
Change-Id: Idcf9656e5c460c5ea0d23c19c6c51e951f7716c3
Reviewed-on: https://go-review.googlesource.com/12646
Reviewed-by: Russ Cox <rsc@golang.org>
GC assists are supposed to steal at most the amount of background GC
credit available so that background GC credit doesn't go negative.
However, they are instead stealing the *total* amount of their debt
but only claiming up to the amount of credit that was available. This
results in draining the background GC credit pool too quickly, which
results in unnecessary assist work.
The fix is trivial: steal the amount of work we meant to steal (which
is already computed).
Change-Id: I837fe60ed515ba91c6baf363248069734a7895ef
Reviewed-on: https://go-review.googlesource.com/12643
Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
CL https://golang.org/cl/12470 has reportedly fixed the problems that
the misc/cgo/testsovar test encountered on darwin and netbsd. Let's
actually run the test.
Update #10360.
Update #11654.
Change-Id: I4cdd27a8ec8713620e0135780a03f63cfcc538d0
Reviewed-on: https://go-review.googlesource.com/12702
Reviewed-by: Russ Cox <rsc@golang.org>
This race was identified in #9796, but a sequence of fixes
proposed in golang.org/cl/4152 were rolled into
golang.org/cl/5910 which both fixed the race and
modified the name space behavior.
We rolled back the name space changes and lost the race fix.
Fix the race separate from the name space changes,
following the suggestion made by Roger Peppe in
https://go-review.googlesource.com/#/c/4152/7/src/encoding/xml/marshal.go@897Fixes#9796.
Fixes#11885.
Change-Id: Ib2b68982da83dee9e04db8b8465a8295259bba46
Reviewed-on: https://go-review.googlesource.com/12687
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Currently the gctrace output reports the trigger heap size, rather
than the actual heap size at the beginning of GC. Often these are the
same, or at least very close. However, it's possible for the heap to
already have exceeded this trigger when we first check the trigger and
start GC; in this case, this output is very misleading. We've
encountered this confusion a few times when debugging and this
behavior is difficult to document succinctly.
Change the gctrace output to report the actual heap size when GC
starts, rather than the trigger.
Change-Id: I246b3ccae4c4c7ea44c012e70d24a46878d7601f
Reviewed-on: https://go-review.googlesource.com/12452
Reviewed-by: Russ Cox <rsc@golang.org>
Whenever someone pastes gctrace output into GitHub, it helpfully turns
the GC cycle number into a link to some unrelated issue. Prevent this
by removing the pound before the cycle number. The fact that this is a
cycle number is probably more obvious at a glance than most of the
other numbers.
Change-Id: Ifa5fc7fe6c715eac50e639f25bc36c81a132ffea
Reviewed-on: https://go-review.googlesource.com/12413
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
svn dies due to not being able to validate the googlecode.com certificate.
hg does not even attempt to validate it.
Fixes#11806.
Change-Id: I84ced5aa84bb1e4a4cdb2254f2d08a64a1ef23f6
Reviewed-on: https://go-review.googlesource.com/12558
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Fixes TestGoGetWorksWithVanityWildcards,
but that test uses the network and is not run
on the builders.
For #11806.
Change-Id: I35c6677deaf84e2fa9bdb98b62d80d388b5248ae
Reviewed-on: https://go-review.googlesource.com/12557
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Some of these were right; others weren't.
Fixes 'GOGC=off GOSSAPKG=mime go test -a mime'.
The right long term fix is probably to teach the
register allocator about in-place instructions.
In the meantime, all the tests that we can run
now pass.
Change-Id: I8e37b00a5f5e14f241b427d45d5f5cc1064883a2
Reviewed-on: https://go-review.googlesource.com/12664
Reviewed-by: Keith Randall <khr@golang.org>
Prior to this, we were smashing our own stack,
which caused the crypto/sha256 tests to fail.
Change-Id: I7dd94cf466d175b3be0cd65f9c4fe8b1223081fe
Reviewed-on: https://go-review.googlesource.com/12660
Reviewed-by: Daniel Morsing <daniel.morsing@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
This extends https://golang.org/cl/2811, which only applied to Darwin
and GNU/Linux, to all Unix systems.
Fixes#9591.
Change-Id: Iec3fb438564ba2924b15b447c0480f87c0bfd009
Reviewed-on: https://go-review.googlesource.com/12661
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
From https://github.com/golang/go/issues/11745#issuecomment-123555313 :
The http.RoundTripper interface says you get either a *Response, or an
error.
But in the case of a client writing a large request and the server
replying prematurely (e.g. 403 Forbidden) and closing the connection
without reading the request body, what does the client want? The 403
response, or the error that the body couldn't be copied?
This CL implements the aforementioned comment's option c), making the
Transport give an N millisecond advantage to responses over body write
errors.
Updates #11745
Change-Id: I4485a782505d54de6189f6856a7a1f33ce4d5e5e
Reviewed-on: https://go-review.googlesource.com/12590
Reviewed-by: Russ Cox <rsc@golang.org>
We used to use build.Import to get the dependencies, but that meant
we had to repeat the check for every possible GOOS/GOARCH/cgo
combination, which took too long. So we made the test in short mode
only check the current GOOS/GOARCH/cgo combination.
But some combinations can't run the test at all. For example darwin/arm64
does not run tests with a full source file systems, so it cannot test itself,
so nothing was testing darwin/arm64. This led to bugs like #10455
not being caught.
Rewrite the test to read the imports out of the source files ourselves,
so that we can look at all source files in a directory in one pass,
regardless of which GOOS/GOARCH/cgo/etc they require.
This one complete pass runs in the same amount of time as the
old single combination check ran, so we can now test all systems,
even in short mode.
Change-Id: Ie216303c2515bbf1b6fb717d530a0636e271cb6d
Reviewed-on: https://go-review.googlesource.com/12576
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change adds new methods to Decoder.
* Decoder.Token steps through a JSON document, returning a value for each token.
* Decoder.Decode unmarshals the entire value at the token stream's current
position (in addition to its existing function in a stream of JSON values)
Fixes#6050.
Fixes#6499.
Change-Id: Iff283e0e7b537221ae256392aca6529f06ebe211
Reviewed-on: https://go-review.googlesource.com/9073
Reviewed-by: Russ Cox <rsc@golang.org>
A while back we discovered that the dependencies test allowed
arbitrary dependencies for packages we forgot to list.
To stop the damage we added a grandfathered list and fixed
the code to expect unlisted packages to have no dependencies.
This CL replaces the grandfathered list with some more
careful placement of dependency rules.
Thankfully, there were no terrible inversions.
Fixes#10487.
Change-Id: I5a6f92435bd2c66c47ec8ab629edbd88b189f028
Reviewed-on: https://go-review.googlesource.com/12575
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
It's not clear this really belongs anywhere at all,
but this is a better place for it than package os.
This way package os can avoid importing "C".
Fixes#10455.
Change-Id: Ibe321a93bf26f478951c3a067d75e22f3d967eb7
Reviewed-on: https://go-review.googlesource.com/12574
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Dave Cheney <dave@cheney.net>
It was not running because of invalid use of ArchChar.
I didn't catch this when I scrubbed ArchChar from the tree
because this code wasn't in the tree yet.
The test seems to pass, which is nice.
Change-Id: I59761a7a04a73681e147e25c1e7f010068276aa8
Reviewed-on: https://go-review.googlesource.com/12573
Reviewed-by: Robert Griesemer <gri@golang.org>
There is clearly work to do here with respect to xml name spaces,
but I don't believe the changes in this cycle are clearly correct.
The changes in this cycle have visible impact on the generated xml,
possibly breaking existing programs, and yet it's not clear that they
are the end of the story: there is still significant confusion about how
name spaces work or should work (see #9519, #9775, #8167, #7113).
I would like to wait to make breaking changes until we completely
understand what the behavior should be and can evaluate the benefit
of those breaking changes. My main concern here is that we will break
programs in Go 1.5 for the sake of name space adjustments and then
while trying to fix those other bugs we'll break programs in Go 1.6 too.
Let's wait until we know all the changes we want to make before we
decide whether or how to break existing programs.
This CL reverts:
5ae822b encoding/xml: minor changes
bb7e665 encoding/xml: fix xmlns= behavior
9f9d66d encoding/xml: fix default namespace of tags
b69ea01 encoding/xml: fix namespaces in a>b tags
3be158d encoding/xml: encoding name spaces correctly
and adjusts tests from
a9dddb5 encoding/xml: add more EncodeToken tests.
to expect Go 1.4 behavior.
I have confirmed that the name space parts of the test suite
as of this CL passes against the Go 1.4 encoding/xml package,
indicating that this CL successfully restores the Go 1.4 behavior.
(Other tests do not, but that's because there were some real
bug fixes in this cycle that are being kept. Specifically, the
tests that don't pass in Go 1.4 are TestMarshal's NestedAndComment
case, TestEncodeToken's encoding of newlines, and
TestSimpleUseOfEncodeToken returning an error for invalid
token types.)
I also checked that the Go 1.4 tests pass when run against
this copy of the sources.
Fixes#11841.
Change-Id: I97de06761038b40388ef6e3a55547ff43edee7cb
Reviewed-on: https://go-review.googlesource.com/12570
Reviewed-by: Nigel Tao <nigeltao@golang.org>
The "add a Request.Cancel channel" change (https://golang.org/cl/11601)
added support for "race free" cancellation, but introduced a data race. :)
Noticed while running "go test -race net/http". The test is skipped in
short mode, so we never saw it on the dashboard.
Change-Id: Ica14579d8723f8f9d1691e8d56c30b585b332c64
Reviewed-on: https://go-review.googlesource.com/12663
Reviewed-by: Aaron Jacobs <jacobsa@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Fix an issue where doasm fails if trying to multiply by a larger
than 32 bit const (doasm: notfound ft=9 tt=14 00008 IMULQ
$34359738369, CX 9 14). Fix truncation of 64 to 32 bit integer
when generating LEA causing incorrect values to be computed.
Change-Id: I1e65b63cc32ac673a9bb5a297b578b44c2f1ac8f
Reviewed-on: https://go-review.googlesource.com/12678
Reviewed-by: Keith Randall <khr@golang.org>
Not everyone is aware that go build is a wrapper for other
tools. Mention this in the text for go help build so people using
other build systems won't just wrap go build, which is usually a
mistake (it doesn't do incremental builds by default, for instance).
Update #11854.
Change-Id: I759f91f23ccd3671204c39feea12a3bfaf9f0114
Reviewed-on: https://go-review.googlesource.com/12625
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The system stack is only around 8kb on ARM so one can't put an 8kb buffer on
the stack. More than 1024 ARM cores seems sufficiently unlikely for the
foreseeable future.
Fixes#11853
Change-Id: I7cb27c1250a6153f86e269c172054e9dfc218c72
Reviewed-on: https://go-review.googlesource.com/12622
Reviewed-by: Austin Clements <austin@google.com>
Currently TestDoDupSuppress can fail if the goroutines created by its
loop run sequentially. This is rare, but it has caused failures on the
dashboard and in stress testing.
While I think there's no way to eliminate all possible thread
schedules that could make this test fail because it depends on waiting
until a Group.Do blocks, it is possible to make it much more robust.
This commit deflakes this test by forcing at least one invocation of
fn to start and all goroutines to reach the line just before the Do
call before allowing fn to proceed. fn then waits 10 milliseconds
before returning to allow the goroutines to pass through the Do.
With this change, in 50,000 runs of the stress testing configuration,
the number of calls to fn never even exceeded 1.
Fixes#11784.
Change-Id: Ie5adf5764545050ec407619769a656251c4cff04
Reviewed-on: https://go-review.googlesource.com/12681
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Update the docs to explain the code added in
commit 67e1d400.
Fixes#11831.
Change-Id: I8fe72e449507847c4bd9d77de40947ded7f2ff9d
Reviewed-on: https://go-review.googlesource.com/12515
Reviewed-by: Dave Cheney <dave@cheney.net>
Rewrite if !cond by swapping the branches and removing the not.
Change-Id: If3af1bac02bfc566faba872a8c7f7e5ce38e9f58
Reviewed-on: https://go-review.googlesource.com/12610
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
This prevents panics while attempting to generate code
for the runtime package. Now:
<unknown line number>: internal compiler error: localOffset of non-LocalSlot value: v10 = ADDQconst <*m> [256] v22
Change-Id: I20ed6ec6aae2c91183b8c826b8ebcc98e8ceebff
Reviewed-on: https://go-review.googlesource.com/12655
Reviewed-by: Keith Randall <khr@golang.org>
This generates more efficient code.
Before:
0x003a 00058 (rr.go:7) LEAQ go.string.hdr."="(SB), BX
0x0041 00065 (rr.go:7) LEAQ 16(BX), BP
0x0045 00069 (rr.go:7) MOVQ BP, 16(SP)
After:
0x003a 00058 (rr.go:7) LEAQ go.string."="(SB), BX
0x0041 00065 (rr.go:7) MOVQ BX, 16(SP)
It also matches the existing backend
and is more robust to other changes,
such as CL 11698, which I believe broke
the current code.
This CL fixes the encoding/base64 tests, as run with:
GOGC=off GOSSAPKG=base64 go test -a encoding/base64
Change-Id: I3c475bed1dd3335cc14e13309e11d23f0ed32c17
Reviewed-on: https://go-review.googlesource.com/12654
Reviewed-by: Keith Randall <khr@golang.org>
Issue 11214 reports problems with older versions of gdb. It does work
with gdb 7.9 on my Ubuntu Trusty system, so take that as the minimum
required version.
Fixes#11214.
Change-Id: I61b732895506575be7af595f81fc1bcf696f58c2
Reviewed-on: https://go-review.googlesource.com/12626
Reviewed-by: Austin Clements <austin@google.com>
This adds documentation for all the environment variables I could
locate in the go tool and the commands that it invokes.
Fixes#9672.
Change-Id: Id5f09160a3a8a938af4a3fcb8757eb3eced05416
Reviewed-on: https://go-review.googlesource.com/12620
Reviewed-by: Rob Pike <r@golang.org>
In https://go-review.googlesource.com/#/c/8611/ , these tests were
supposed to be skipped only for linux and darwin, as the comment says.
This patch fixes the logic in the if test.
Change-Id: Iff0a32186267457a414912c4c3ee4495650891a2
Reviewed-on: https://go-review.googlesource.com/12517
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Old code appended, did not play well with a closure
with a ... param.
Fixes#11075.
Change-Id: Ib7c8590c5c4e576e798837e7499e00f3494efb4a
Reviewed-on: https://go-review.googlesource.com/12580
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: David Chase <drchase@google.com>
This reduces the time to compile
test/slice3.go on my laptop from ~12s to ~3.8s.
It reduces the max memory use from ~4.8gb to
~450mb.
This is still considerably worse than tip,
at 1s and 300mb respectively, but it's
getting closer.
Hopefully this will fix the build at long last.
Change-Id: Iac26b52023f408438cba3ea1b81dcd82ca402b90
Reviewed-on: https://go-review.googlesource.com/12566
Reviewed-by: Keith Randall <khr@golang.org>
Experimentally, the Ops of v.Args do a good job
of differentiating values that will end up in
different partitions.
Most values have at most two args, so use them.
This reduces the wall time to run test/slice3.go
on my laptop from ~20s to ~12s.
Credit to Todd Neal for the idea.
Change-Id: I55d08f09eb678bbe8366924ca2fabcd32526bf41
Reviewed-on: https://go-review.googlesource.com/12565
Reviewed-by: Keith Randall <khr@golang.org>
These temporary environment variables make it
possible to enable using SSA-generated code
for a particular function or package without
having to rebuild the compiler.
This makes it possible to start bulk testing
SSA generated code.
First, bump up the default stack size
(_StackMin in runtime/stack2.go) to something
large like 32768, because without stackmaps
we can't grow stacks.
Then run something like:
for pkg in `go list std`
do
GOGC=off GOSSAPKG=`basename $pkg` go test -a $pkg
done
When a test fails, you can re-run those tests,
selectively enabling one function after another,
until you find the one that is causing trouble.
Doing this right now yields some interesting results:
* There are several packages for which we generate
some code and whose tests pass. Yay!
* We can generate code for encoding/base64, but
tests there fail, so there's a bug to fix.
* Attempting to build the runtime yields a panic during codegen:
panic: interface conversion: ssa.Location is nil, not *ssa.LocalSlot
* The top unimplemented codegen items are (simplified):
59 genValue not implemented: REPMOVSB
18 genValue not implemented: REPSTOSQ
14 genValue not implemented: SUBQ
9 branch not implemented: If v -> b b. Control: XORQconst <bool> [1]
8 genValue not implemented: MOVQstoreidx8
4 branch not implemented: If v -> b b. Control: SETG <bool>
3 branch not implemented: If v -> b b. Control: SETLE <bool>
2 load flags not implemented: LoadReg8 <flags>
2 genValue not implemented: InvertFlags <flags>
1 store flags not implemented: StoreReg8 <flags>
1 branch not implemented: If v -> b b. Control: SETGE <bool>
Change-Id: Ib64809ac0c917e25bcae27829ae634c70d290c7f
Reviewed-on: https://go-review.googlesource.com/12547
Reviewed-by: Keith Randall <khr@golang.org>
By walking only the current set of partitions
at any given point, the cse pass ended up doing
lots of extraneous, effectively O(n^2) work.
Using a regular for loop allows each cse pass to
make as much progress as possible by processing
each new class as it is introduced.
This can and should be optimized further,
but it already reduces by 75% cse time on test/slice3.go.
The overall time to compile test/slice3.go is still
dominated by the O(n^2) work in the liveness pass.
However, Keith is rewriting regalloc anyway.
Change-Id: I8be020b2f69352234587eeadeba923481bf43fcc
Reviewed-on: https://go-review.googlesource.com/12244
Reviewed-by: Keith Randall <khr@golang.org>
Use width-and-signed-specific multiply opcodes.
Implement OMUL.
A few other cleanups.
Fixes#11467
Change-Id: Ib0fe80a1a9b7208dbb8a2b6b652a478847f5d244
Reviewed-on: https://go-review.googlesource.com/12540
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
On Windows, gcc -o foo will generate foo.exe. Prevent that from
happening by adding a final '.' if necessary so that GCC thinks that
the file already has an extension.
Also remove the initial output file when doing an external link, and
use mayberemoveoutfile, not os.Remove, when building an archive
(otherwise we will do the wrong thing for -buildmode=c-archive -o
/dev/null).
I didn't add a test, as it requires using cgo and -o on Windows.
Fixes#11725.
Change-Id: I6ea12437bb6b4b9b8ee5c3b52d83509fa2437b2d
Reviewed-on: https://go-review.googlesource.com/12243
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Russ Cox <rsc@golang.org>
This reduces the wall time to run test/slice3.go
on my laptop from >10m to ~20s.
This could perhaps be further reduced by using
a worklist of blocks and/or implementing the
suggestion in the comment in this CL, but at this
point, it's fast enough that there is no need.
Change-Id: I741119e0c8310051d7185459f78be8b89237b85b
Reviewed-on: https://go-review.googlesource.com/12564
Reviewed-by: Keith Randall <khr@golang.org>
EncodeToken takes a Token (i.e. an interface{}) as a parameter,
and expects a value of type StartElement, EndElement, CharData,
Comment, ProcInst, or Directive.
If a pointer is passed instead, or any type which does not match
this list, the token is silently ignored.
Added a default case in the type switch to issue a proper error
when the type is invalid.
The behavior could be later improved by allowing pointers to
token to be accepted as well, but not for go1.5.
Fixes#11719
Change-Id: Ifd13c1563450b474acf66d57669fdccba76c1949
Reviewed-on: https://go-review.googlesource.com/12252
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Foreign code can be arbitrarily aligned,
so the function before it can have
arbitrarily much padding.
We can't call pcvalue on values in the padding.
Fixes#11653.
Change-Id: I7d57f813ae5a2409d1520fcc909af3eeef2da131
Reviewed-on: https://go-review.googlesource.com/12550
Reviewed-by: Rob Pike <r@golang.org>
We use 127.0.0.1 instead of localhost in Go networking tests.
The reporter of #11774 has localhost defined to be 120.192.83.162,
for reasons unknown.
Also, if TestTraceSymbolize calls Fatalf (for example because Listen
fails) then we need to stop the trace for future tests to work.
See failure log in #11774.
Fixes#11774.
Change-Id: Iceddb03a72d31e967acd2d559ecb78051f9c14b7
Reviewed-on: https://go-review.googlesource.com/12521
Reviewed-by: Rob Pike <r@golang.org>
It wasn't working. The wrong variable was used.
This would ideally have tests. It's also DEBUG.
Fixes#11816
Change-Id: Iec42d229b81d78cece4ba5c73f3040e2356eb98f
Reviewed-on: https://go-review.googlesource.com/12544
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
When dialing with a relative Timeout instead of an absolute Deadline,
the deadline function only makes sense if called before doing any
time-consuming work.
This change calls deadline exactly once, storing the result until the
Dial operation completes. The partialDeadline implementation is
reverted to the following patch set 3:
https://go-review.googlesource.com/#/c/8768/3..4/src/net/dial.go
Otherwise, when dialing a name with multiple IP addresses, or when DNS
is slow, the recomputed deadline causes the total Timeout to exceed that
requested by the user.
Fixes#11796
Change-Id: I5e1f0d545f9e86a4e0e2ac31a9bd108849cf0fdf
Reviewed-on: https://go-review.googlesource.com/12442
Run-TryBot: Paul Marks <pmarks@google.com>
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Add label and goto checks and improve test coverage.
Implement OSWITCH and OSELECT.
Implement OBREAK and OCONTINUE.
Allow generation of code in dead blocks.
Change-Id: Ibebb7c98b4b2344f46d38db7c9dce058c56beaac
Reviewed-on: https://go-review.googlesource.com/12445
Reviewed-by: Keith Randall <khr@golang.org>
Handle multiplication with -1, 0, 3, 5, 9 and all powers of two.
Change-Id: I8e87e7670dae389aebf6f446d7a56950cacb59e0
Reviewed-on: https://go-review.googlesource.com/12350
Reviewed-by: Keith Randall <khr@golang.org>
This is needed to handle vendor directories correctly. It was already
done for the regular imports when the package was loaded, but not for
the test-only imports.
It would be nice to do this while loading the package, but that breaks
the code that checks for direct references to vendor packages when
running go test. This change is relatively contained.
While we're at it, skip "C" test imports in go get.
Fixes#11628.
Fixes#11717.
Change-Id: I9cc308cf45683e3ff905320c2b5cb45db7716846
Reviewed-on: https://go-review.googlesource.com/12488
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Updated Address.String so it restores quoted local parts, which wasn't
done before.
When parsing `<" "@example.com>`, the formatted string returned
`< @example>`, which doens't match RFC 5322, since a space is not atext.
Another example is `<"bob@valid"@example.com>` which returned
`<bob@valid@example.com>`, which is completely invalid.
I also added support for quotes and backslashes in a quoted local part.
Besides formatting a parsed Address, the ParseAddress function also
needed more testing and finetuning for special cases.
Things like `<.john.doe@example.com>` and `<john..doe@example.com>`
e.a. were accepted, but are invalid.
I fixed those details and add tests for some other special cases.
Fixes#10768
Change-Id: Ib0caf8ad603eb21e32fcb957a5f1a0fe5d1c6e6e
Reviewed-on: https://go-review.googlesource.com/8724
Reviewed-by: Russ Cox <rsc@golang.org>
Some routines run without and m or g and cannot invoke the
race detector runtime. They must be opaque to the runtime.
That used to be true because they were written in C.
Now that they are written in Go, disable the race detector
annotations for those functions explicitly.
Add test.
Fixes#10874.
Change-Id: Ia8cc28d51e7051528f9f9594b75634e6bb66a785
Reviewed-on: https://go-review.googlesource.com/12534
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Same as we do for string symbols.
Fixes#11583.
Change-Id: Ia9264f6faf486697d987051b7f9851d37d8ad381
Reviewed-on: https://go-review.googlesource.com/12531
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
In the past badsignal would crash the program. In
https://golang.org/cl/10757044 badsignal was changed to call sigsend,
to fix issue #3250. The effect of this was that when a non-Go thread
received a signal, and os/signal.Notify was not being used to check
for occurrences of the signal, the signal was ignored.
This changes the code so that if os/signal.Notify is not being used,
then the signal handler is reset to what it was, and the signal is
raised again. This lets non-Go threads handle the signal as they
wish. In particular, it means that a segmentation violation in a
non-Go thread will ordinarily crash the process, as it should.
Fixes#10139.
Update #11794.
Change-Id: I2109444aaada9d963ad03b1d071ec667760515e5
Reviewed-on: https://go-review.googlesource.com/12503
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
This change fixes resolution of secure (https) repo URL for
git.apache.org Git repositories.
E.g. the correct repo URL for git.apache.org/thrift.git/lib/go/thrift is
https://git.apache.org/thrift.git, not https://git.apache.org/thriftFixes#10797
Change-Id: I67d5312ad8620eb780e42c2e002c8f286f60645a
Reviewed-on: https://go-review.googlesource.com/10092
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
It's a bad test and it's worst on uniprocessors.
Fixes#11143.
Change-Id: I0164231ada294788d7eec251a2fc33e02a26c13b
Reviewed-on: https://go-review.googlesource.com/12522
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
ae1ea2a moved trace-related functions from runtime/pprof to
runtime/trace, but missed a doc comment and a code comment. Update
these to reflect the move.
Change-Id: I6e1e8861e5ede465c08a2e3f80b976145a8b32d8
Reviewed-on: https://go-review.googlesource.com/12525
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
It is very useful to see which test commands are executed.
This is of global use, but I wrote it for #11654.
Change-Id: I9bfc8e55d5bef21f4c49b917f58bc9a44aefcade
Reviewed-on: https://go-review.googlesource.com/12510
Reviewed-by: Russ Cox <rsc@golang.org>
Move tracing functions from runtime/pprof to the new runtime/trace package.
Fixes#9710
Change-Id: I718bcb2ae3e5959d9f72cab5e6708289e5c8ebd5
Reviewed-on: https://go-review.googlesource.com/12511
Reviewed-by: Russ Cox <rsc@golang.org>
JSON decoding currently fails for null values bound to any type
which does implement the JSON Unmarshaler interface without checking
for null values (such as time.Time).
It also fails for types implementing the TextUnmarshaler interface.
The expected behavior of the JSON decoding engine in such case is
to process null by keeping the value unchanged without producing
any error.
Make sure null values are handled by the decoding engine itself,
and never passed to the UnmarshalText or UnmarshalJSON methods.
Fixes#9037
Change-Id: I261d85587ba543ef6f1815555b2af9311034d5bb
Reviewed-on: https://go-review.googlesource.com/9376
Reviewed-by: Russ Cox <rsc@golang.org>
dist test should not print (especially to stdout) during test
registration. This confuses other tools interacting with dist using
dist test --list, etc.
Change-Id: Ie4f82c13e49590c23a7a235d90ddbc4f5ed81e0b
Reviewed-on: https://go-review.googlesource.com/12487
Reviewed-by: Ian Lance Taylor <iant@golang.org>
In lieu of the more invasive https://go-review.googlesource.com/#/c/12373/ .
Change-Id: I0221783fcaa8af04520c80cd2993d7d542d2c431
Reviewed-on: https://go-review.googlesource.com/12486
Reviewed-by: Alan Donovan <adonovan@google.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
That test will install cmd/pack for linux_386; we don't want to change
GOROOT in short mode.
Change-Id: I4b00c578a99779a13c558208bfd4115f8f0513fa
Reviewed-on: https://go-review.googlesource.com/12481
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Bad rebase in CL 12439.
Change-Id: I7ad359519c6274be37456b655f19bf0ca6ac6692
Reviewed-on: https://go-review.googlesource.com/12449
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Prior to this fix, a zero-aligned variable such as a flags
variable would reset n to 0.
While we're here, log the stack layout so that debugging
and reading the generated assembly is easier.
Change-Id: I18ef83ea95b6ea877c83f2e595e14c48c9ad7d84
Reviewed-on: https://go-review.googlesource.com/12439
Reviewed-by: Keith Randall <khr@golang.org>
It is not clear to me what the right implementation is.
LoadReg8 and StoreReg8 are introduced during regalloc,
so after the amd64 rewrites. But implementing them
in genValue seems silly.
Change-Id: Ia708209c4604867bddcc0e5d75ecd17cf32f52c3
Reviewed-on: https://go-review.googlesource.com/12437
Reviewed-by: Keith Randall <khr@golang.org>
Bake the bit width and signedness into opcodes.
Pro: Rewrite rules become easier. Less chance for confusion.
Con: Lots more opcodes.
Let me know what you think. I'm leaning towards this, but I could be
convinced otherwise if people think this is too ugly.
Update #11467
Change-Id: Icf1b894268cdf73515877bb123839800d97b9df9
Reviewed-on: https://go-review.googlesource.com/12362
Reviewed-by: Alan Donovan <adonovan@google.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
The verb doesn't do anything, but if/when we move
these to the test directory, having it be right
will be one fewer thing to remember.
Change-Id: Ibf0280d7cc14bf48927e25215de6b91c111983d9
Reviewed-on: https://go-review.googlesource.com/12438
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This will be used in a subsequent commit.
Change-Id: I43eca21f4692d99e164c9f6be0760597c46e6a26
Reviewed-on: https://go-review.googlesource.com/12440
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The cmd/go tests run too long on a Raspberry Pi. I've cut times as
much as I can see without more serious steps like not running tests.
Fixes#11779.
Change-Id: Ice5da052902decea2e6ac32d0f2ce084c39ea1ab
Reviewed-on: https://go-review.googlesource.com/12368
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Speed up the test suite by building the errors package rather than the
strings package in some cases where the specific package we are
building doesn't matter. The errors package is smaller, and doesn't
have any assembler code.
Also make a couple of tests run in parallel.
Update #11779.
Change-Id: I62e47f8655f9d85bf93c70ae6e6121276d96aee0
Reviewed-on: https://go-review.googlesource.com/12365
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
It changes GOROOT, so we shouldn't run it in short mode. Also, it's
fairly slow.
Update #11779.
Change-Id: I3d3344954cf9b2ac70070c878a67cb65ac8fd85c
Reviewed-on: https://go-review.googlesource.com/12364
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
On my laptop reduces time required for test from 22 seconds to 0.14
seconds.
Update #11779.
Change-Id: I715d85bd9c6f7683c6915eedd2539813aa5efc58
Reviewed-on: https://go-review.googlesource.com/12363
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
This is mostly Russ's https://golang.org/cl/12145 but with some extra fixes to
account for the fact that function declarations without implementations now
break shared libraries, and including my test case.
Fixes#11480.
Change-Id: Iabdc2934a0378e5025e4e7affadb535eaef2c8f1
Reviewed-on: https://go-review.googlesource.com/12340
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The runtime.GC documentation was rewritten in df2809f to make it clear
that it blocks until GC is complete, but the re-rewrite in ed9a4c9 and
e28a679 lost this property when clarifying that it may also block the
entire program and not just the caller.
Try to arrive at wording that conveys both of these properties.
Change-Id: I1e255322aa28a21a548556ecf2a44d8d8ac524ef
Reviewed-on: https://go-review.googlesource.com/12392
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
The findmoduledatap function will not return nil in ordinary use, but
check for nil to try to avoid crashing when we are already crashing.
Update #11783.
Change-Id: If7b1adb51efab13b4c1a37b6f3c9ad22641a0b56
Reviewed-on: https://go-review.googlesource.com/12391
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The default value for error is nil so there is no need to assign this
value here.
Change-Id: I4714ef7607996ccbf91b704390e1d1d39ee3847b
Reviewed-on: https://go-review.googlesource.com/12355
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Old style. Make it compliant with our code review comments document.
Also, make WriteString's return parameter named 'n', not 'ret', for
consistency.
Noticed during another documentation review.
Change-Id: Ie88910c5841f8353bc5c0152e2168b497578e15e
Reviewed-on: https://go-review.googlesource.com/12324
Reviewed-by: Rob Pike <r@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
We shouldn't guarantee this behavior, but suggest it's possible.
Change-Id: I4c2afb48b99be4d91537306d3337171a13c9990a
Reviewed-on: https://go-review.googlesource.com/12346
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The change https://golang.org/cl/12192 changed the get code to use the
list of package imports, not the computed list of dependencies, as the
computed list could be out of date if the package changed when using
go get -u. Computing the dependency list would skip an import of "C",
but that would still be on the package import list. This changes the
code to skip "C" when walking the import list.
No test--the best test would be to add an import of "C" to
github.com/rsc/go-get-issue-9224-cmd for TestGoGetUpdate.
Fixes#11738.
Change-Id: Id89ddafeade2391d15688bfd142fafd67844a941
Reviewed-on: https://go-review.googlesource.com/12322
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
Updates #10061
CL 12353 updated the documentation for os.Rename to stipulate the function will
return errors of type *os.LinkError. This CL adds a test to ensure that the
implementations continue to obey this contract.
Change-Id: I41beb8c9d8356c737de251fdc6f652caab3ee636
Reviewed-on: https://go-review.googlesource.com/12329
Reviewed-by: Ian Lance Taylor <iant@golang.org>
No code changes. Just make it clear that runtime.GC is not concurrent.
Change-Id: I00a99ebd26402817c665c9a128978cef19f037be
Reviewed-on: https://go-review.googlesource.com/12345
Reviewed-by: Dave Cheney <dave@cheney.net>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The document `doc/go_spec.html` uses "preceeding" instead of the word
"preceding" in one place.
Fixed another occurrence in `src/go/types/typexpr.go`.
Change-Id: Ic67f62026b5c9d002c5c5632299f14ecac8b02ae
Reviewed-on: https://go-review.googlesource.com/12354
Reviewed-by: Ian Lance Taylor <iant@golang.org>
An out-of-date comment snuck in to cc8f544. Remove it.
Change-Id: I5bc7c17e737d1cabe57b88de06d7579c60ca28ff
Reviewed-on: https://go-review.googlesource.com/12328
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Rename should document that it returns *LinkError,
like Create and Stat do.
Fixes#10061
Change-Id: I7bfe8b0267f6c4a57dd6b26cba44928714711724
Reviewed-on: https://go-review.googlesource.com/12353
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This fixes a race between 1) sweeping and freeing an unmarked large
span and 2) reusing that span and allocating from it. This race arises
because mSpan_Sweep returns spans for large objects to the heap
*before* heapBitsSweepSpan clears the mark bit on the object in the
span.
Specifically, the following sequence of events can lead to an
incorrectly zeroed bitmap byte, which causes the garbage collector to
not trace any pointers in that object (the pointer bits for the first
four words are cleared, and the scan bits are also cleared, so it
looks like a no-scan object).
1) P0 calls mSpan_Sweep on a large span S0 with an unmarked object on it.
2) mSpan_Sweep calls heapBitsSweepSpan, which invokes the callback for
the one (unmarked) object on the span.
3) The callback calls mHeap_Free, which makes span S0 available for
allocation, but this is too early.
4) P1 grabs this S0 from the heap to use for allocation.
5) P1 allocates an object on this span and writes that object's type
bits to the bitmap.
6) P0 returns from the callback to heapBitsSweepSpan.
heapBitsSweepSpan clears the byte containing the mark, even though
this span is now owned by P1 and this byte contains important
bitmap information.
This fixes this problem by simply delaying the mHeap_Free until after
the heapBitsSweepSpan. I think the overall logic of mSpan_Sweep could
be simplified now, but this seems like the minimal change.
Fixes#11617.
Change-Id: I6b1382c7e7cc35f81984467c0772fe9848b7522a
Reviewed-on: https://go-review.googlesource.com/12320
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Rob Pike <r@golang.org>
Adjusts for the move from golang.org/x/tools/go/types and .../go/exact
to go/types and go/constant in the main repository.
Change-Id: I0da7248c540939e3e9b09c915b0a296937f1be73
Reviewed-on: https://go-review.googlesource.com/12284
Reviewed-by: Andrew Gerrand <adg@golang.org>
Keep track of the outargs size needed at each call.
Compute the size of the outargs section of the stack frame. It's just
the max of the outargs size at all the callsites in the function.
Change-Id: I3d0640f654f01307633b1a5f75bab16e211ea6c0
Reviewed-on: https://go-review.googlesource.com/12178
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
At least the most important parts, I think.
Fixes#10552
Change-Id: I1a03c5405bdbef337e0245d226e9247d3d067393
Reviewed-on: https://go-review.googlesource.com/12246
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
The iOS simulator compiles with GOOS=darwin GOARCH=386, and x509
sets the inappropriate flag -mmacosx-version-min=10.6. Condition
its compilation on the absence of an "ios" build tag.
Fixes#11736.
Change-Id: I4aa230643347320c3cb9d03b972734b2e0db930e
Reviewed-on: https://go-review.googlesource.com/12301
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
If we've already hit an Unimplemented, there may be important
SSA invariants that do not hold and which could cause
ssa.Compile to hang or spin.
While we're here, make detected dependency cycles stop execution.
Change-Id: Ic7d4eea659e1fe3f2c9b3e8a4eee5567494f46ad
Reviewed-on: https://go-review.googlesource.com/12310
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Implement ODOT. Similar to ArrayIndex, StructSelect selects a field
out of a larger Value.
We may need more ways to rewrite StructSelect, but StructSelect/Load
is the typical way it is used.
Change-Id: Ida7b8aab3298f4754eaf9fee733974cf8736e45d
Reviewed-on: https://go-review.googlesource.com/12265
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This seems to have broken arm64 in a mysterious way. Will try again later.
This reverts commit 0a3c991fd3.
Change-Id: Ic1b53413c4168977a27381d9cc6fb8d9d7cbb780
Reviewed-on: https://go-review.googlesource.com/12245
Reviewed-by: Russ Cox <rsc@golang.org>
If we receive an HTTP request with "Expect: 100-continue" and the
Handler never read to EOF, the conn is in an unknown state.
Don't reuse that connection.
Fixes#11549
Change-Id: I5be93e7a54e899d615b05f72bdcf12b25304bc60
Reviewed-on: https://go-review.googlesource.com/12262
Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Now that we care about the protocol of Git remotes (for the -insecure
flag), we need to recognize and parse the SCP-like remote format.
Fixesgolang/go#11457
Change-Id: Ia26132274fafb1cbfefe2475f7ac5f17ccd6da40
Reviewed-on: https://go-review.googlesource.com/12226
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Running a safe-point function on syscall entry uses systemstack() and
hence clobbers g.sched.pc and g.sched.sp. Fix this by re-saving them
after the systemstack, just like in the other uses of systemstack in
reentersyscall.
Change-Id: I47868a53eba24d81919fda56ef6bbcf72f1f922e
Reviewed-on: https://go-review.googlesource.com/12125
Reviewed-by: Russ Cox <rsc@golang.org>
Currently, we run a P's safe-point function immediately after entering
_Psyscall state. This is unsafe, since as soon as we put the P in
_Psyscall, we no longer control the P and another M may claim it.
We'll still run the safe-point function only once (because doing so
races on an atomic), but the P may no longer be at a safe-point when
we do so.
In particular, this means that the use of forEachP to dispose all P's
gcw caches is unsafe. A P may enter a syscall, run the safe-point
function, and dispose the P's gcw cache concurrently with another M
claiming the P and attempting to use its gcw cache. If this happens,
we may empty the gcw's workbuf after putting it on
work.{full,partial}, or add pointers to it after putting it in
work.empty. This will cause an assertion failure when we later pop the
workbuf from the list and its object count is inconsistent with the
list we got it from.
Fix this by running the safe-point function just before putting the P
in _Psyscall.
Related to #11640. This probably fixes this issue, but while I'm able
to show that we can enter a bad safe-point state as a result of this,
I can't reproduce that specific failure.
Change-Id: I6989c8ca7ef2a4a941ae1931e9a0748cbbb59434
Reviewed-on: https://go-review.googlesource.com/12124
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
There was already special code to recognize "?" in hidden_structdcl,
which is used for inlined types and variables. This recognizes "?" in
structdcl as well, a case that arises when a struct type appears
within an inlined function body.
Fixes#10219.
Change-Id: Ic5257ae54f817e0d4a189c2294dcd633c9f2101a
Reviewed-on: https://go-review.googlesource.com/12241
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The parser treats (R1+R2) on ppc64 the same as (R1,R2) on arm,
but it is not strictly a "register pair". Improve the text.
No semantic change.
Change-Id: Ib8b14881c6467add0d53150a901c01e962afb28b
Reviewed-on: https://go-review.googlesource.com/12212
Reviewed-by: Russ Cox <rsc@golang.org>
- Make Log2 exact for powers of two.
- Fix error tolerance function to make tolerance
a function of the correct (expected) value.
Fixes#9066.
Change-Id: I0320a93ce4130deed1c7b7685627d51acb7bc56d
Reviewed-on: https://go-review.googlesource.com/12230
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Originally 'go test -h' printed the output of 'go help test'.
Then issue #6576 was filed, because that output didn't list (for example) -bench.
CL 14502065 changed 'go test -h' to print the output of 'go help testflag'.
Then issue #9209 was filed, because that output didn't list (for example) -c.
To print all the relevant flags, parts of both 'go help test' and 'go help testflag'
are needed. Refactor the help messages to make those parts available
and print them.
Fixes#9209.
Change-Id: Ie8205b8fb37d00c10d25b3fc98f14286ec46c4e3
Reviewed-on: https://go-review.googlesource.com/12173
Reviewed-by: Rob Pike <r@golang.org>
Before, calling the RGBA method of YCbCr color would return red values
in the range [0x0080, 0xff80]. After, the range is [0x0000, 0xffff] and
is consistent with what Gray colors' RGBA method returns. In particular,
pure black, pure white and every Gray color in between are now exactly
representable as a YCbCr color.
This fixes a regression from Go 1.4 (where YCbCr{0x00, 0x80, 0x80} was
no longer equivalent to pure black), introduced by golang.org/cl/8073 in
the Go 1.5 development cycle. In Go 1.4, the +0x80 rounding was not
noticable when Cb == 0x80 && Cr == 0x80, because the YCbCr to RGBA
conversion truncated to 8 bits before multiplying by 0x101, so the
output range was [0x0000, 0xffff].
The TestYCbCrRoundtrip fuzzy-match tolerance grows from 1 to 2 because
the YCbCr to RGB conversion now maps to an ever-so-slightly larger
range, along with the usual imprecision of accumulating rounding errors.
Also s/int/int32/ in ycbcr.go. The conversion shouldn't overflow either
way, as int is always at least 32 bits, but it does make it clearer that
the computation doesn't depend on sizeof(int).
Fixes#11691
Change-Id: I538ca0adf7e040fa96c5bc8b3aef4454535126b9
Reviewed-on: https://go-review.googlesource.com/12220
Reviewed-by: Rob Pike <r@golang.org>
Fixes#10963.
Change-Id: I8d769b4d25b306f2df41f882ec01d97bbd63171d
Reviewed-on: https://go-review.googlesource.com/12221
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
Fixes#10338.
Change-Id: Ib86cb9a6c694b1e442a9957153c7ca38a7d11c3e
Reviewed-on: https://go-review.googlesource.com/12232
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Fixes#3652. (Well, already fixed, but tests that it stays fixed.)
Change-Id: I4e17f595ee2ad513de86ac3861e8e66b1230b3be
Reviewed-on: https://go-review.googlesource.com/12195
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Fixes#9224.
Change-Id: Ie0f4f14407099e4fa7ebe361a95b6492012928a2
Reviewed-on: https://go-review.googlesource.com/12192
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This fix only works on Git 2.3.0 and later.
There appears to be no portable way to fix the earlier versions.
We already run git with stdin closed, but on Unix git calls getpass,
which opens /dev/tty itself. We could do package syscall-specific
things to get /dev/tty invalidated during the exec, but I'd really
rather not. And on Windows, Git opens "CONIN$" and "CONOUT$"
itself, and I have no idea how to invalidate those.
Fix the problem for newish Git versions and wait for people to update.
Best we can do.
Fixes#9341.
Change-Id: I576579b106764029853e0f74d411e19108deecf5
Reviewed-on: https://go-review.googlesource.com/12175
Reviewed-by: Rob Pike <r@golang.org>
Fixes#11305.
Change-Id: Icaa3a009aa4ab214c9aaf74f52c3e622fa266a9d
Reviewed-on: https://go-review.googlesource.com/12194
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Fix now uses same test as 'go build'.
Fixes#10500.
Change-Id: I2fcf2d95430643370aa29165d89a188988dee446
Reviewed-on: https://go-review.googlesource.com/12174
Reviewed-by: Rob Pike <r@golang.org>
Also adds to 'go test' all the build flags that were missing
due to inconsistency in the duplication (for example, -toolexec).
Fixes#10504.
Change-Id: I1935b5caa13d5e551a0483904adffa8877087df7
Reviewed-on: https://go-review.googlesource.com/12170
Reviewed-by: Rob Pike <r@golang.org>
While we are here, fix a few things not updated for -insecure.
Fixes#8163.
Change-Id: Ib80c9ac00d6b61cce26c3d20bee3d30ab9af1331
Reviewed-on: https://go-review.googlesource.com/12148
Reviewed-by: Rob Pike <r@golang.org>
Was detecting only non-trivial ones.
Fixes#9690.
Change-Id: I662d81dd4818ddf29592057c090805772c84287b
Reviewed-on: https://go-review.googlesource.com/12147
Reviewed-by: Rob Pike <r@golang.org>
These used to be defined at use, but that breaks when shared libraries
are involved.
For #11480.
Change-Id: I416a848754fb615c0d75f9f0ccc00723d07f7f01
Reviewed-on: https://go-review.googlesource.com/12145
Reviewed-by: Rob Pike <r@golang.org>
When the prologue call to morestack was moved down to the
bottom of the function, the pc/sp tables were not updated.
If a traceback through a call to morestack is needed, it would
get confused at and stop at morestack.
Confirmed the fix by adding //go:systemstack (which calls
morestackc, but same issue) where it did not belong
and inspecting the crash.
Change-Id: Id0294bb9dba51ef1a49154637228fb57f1086a94
Reviewed-on: https://go-review.googlesource.com/12144
Reviewed-by: Rob Pike <r@golang.org>
A malformed Host header can result in a malformed HTTP request.
Clean them to avoid this.
Updates #11206. We may come back and make this stricter for 1.6.
Change-Id: I23c7d821cd9dbf66c3c15d26750f305e3672d984
Reviewed-on: https://go-review.googlesource.com/11241
Reviewed-by: Russ Cox <rsc@golang.org>
The interface to set TCP keepalive on Plan 9 is
writing the "keepalive n" string to the TCP ctl file,
where n is the milliseconds between keepalives.
Fixes#11266.
Change-Id: Ic96f6c584063665a1ddf921a9a4ddfa13cc7501b
Reviewed-on: https://go-review.googlesource.com/11860
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
When testing if a value is an integer, if the value is a constant,
don't ignore the type if it has one.
Fixes#11594.
Change-Id: I2ff387e4f9e8ab7cae35c4838350e0a1fce2e625
Reviewed-on: https://go-review.googlesource.com/12045
Reviewed-by: Alan Donovan <adonovan@google.com>
When building a directive, the current sanity check prevents
a '>' to be used, which makes a DOCTYPE directive with an
internal subset be rejected. It is accepted by the parser
though, so what can be parsed cannot be encoded.
Improved the corresponding sanity check to mirror the behavior
of the parser (in the way it handles angle brackets, quotes,
and comments).
Fixes#10158
Change-Id: Ieffea9f870f2694548e12897f8f47babc0ea4414
Reviewed-on: https://go-review.googlesource.com/11630
Reviewed-by: Russ Cox <rsc@golang.org>
The "string" option only applies for strings, floats, integers, and
booleans as per the documentation. So when decoding ignore the "string"
option if the value is not of one of the types mentioned. This matches
the Marshal step which also ignores the "string" option for invalid
types.
Fixes#9812
Change-Id: I0fb2b43d0668bc0e2985886d989abbf2252070e2
Reviewed-on: https://go-review.googlesource.com/10183
Reviewed-by: Russ Cox <rsc@golang.org>
Phi ops should always be scheduled first. They have the semantics
of all happening simultaneously at the start of the block. The regalloc
phase assumes all the phis will appear first.
Change-Id: I30291e1fa384a0819205218f1d1ec3aef6d538dd
Reviewed-on: https://go-review.googlesource.com/12154
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
This rolls back most of golang.org/cl/8841, aka 2f98bac310, and makes a
different fix. It keeps the TestTruncatedSOSDataDoesntPanic test
introduced by that other CL, which obviously still passes after this CL.
Fixes#11650, a regression (introduced by cl/8841) from Go 1.4.
The original cl/8841 changed the image/jpeg not to panic on an input
given in #10387. We still do not panic on that input, after this CL.
I have a corpus of over 160,000 JPEG images, a sample of a web crawl.
The image/jpeg code ran happily over that whole corpus both before and
after this CL, although that corpus clearly didn't catch the regression
in the first place.
This code was otherwise tested manually. I don't think that it's trivial
to synthesize a JPEG input that happens to run out of Huffman data at
just the right place. The test image attached to #11650 obviously has
that property, but I don't think we can simply add that test image to
the repository: it's 227KiB, and I don't know its copyright status.
I also looked back over the issue tracker for problematic JPEGs that
people have filed. The Go code, after this CL, is still happy on these
files in my directory:
issue2362a.jpeg
issue3916.jpeg
issue3976.jpeg
issue4084.jpeg
issue4259.jpeg
issue4291.jpeg
issue4337.jpeg
issue4500.jpeg
issue4705.jpeg
issue4975.jpeg
issue5112.jpeg
issue6767.jpeg
issue9888.jpeg
issue10133.jpeg
issue10357.jpeg
issue10447.jpeg
issue11648.jpeg
issue11650.jpeg
There were other images attached in the issue tracker that aren't
actually valid JPEGs. They failed both before and after this CL:
broken-issue2362b.jpeg
broken-issue6450.jpeg
broken-issue8693.jpeg
broken-issue10154.jpeg
broken-issue10387.jpeg
broken-issue10388.jpeg
broken-issue10389.jpeg
broken-issue10413.jpeg
In summary, this CL fixes#11650 and, after some automated and manual
testing, I don't think introduces new regressions.
Change-Id: I30b67036e9b087f3051d57dac7ea05fb4fa36f66
Reviewed-on: https://go-review.googlesource.com/12163
Reviewed-by: Rob Pike <r@golang.org>
Fixes build from https://golang.org/cl/12152
Plan 9 lacks syscall.EPIPE. I was misled by api/go1.txt and also
forgot to use the trybots. :(
Change-Id: I4982fe969ad4a8724090cb03009bfb21780d8aa7
Reviewed-on: https://go-review.googlesource.com/12153
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The old numerical names like 6.out.go are a relic from the old tools.
Easier to rename than explain.
The anames.go files were modified by go generate; no changes
beyond the explanatory comment at the top.
Change-Id: I84742c75c60e47724baa9d49a91fef1f8581f021
Reviewed-on: https://go-review.googlesource.com/12069
Run-TryBot: Rob Pike <r@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
These memstats are currently being computed by gcMark, which was
appropriate in Go 1.4, but gcMark is now just one part of a bigger
picture. In particular, it can't account for the sweep termination
pause time, it can't account for all of the mark termination pause
time, and the reported "pause end" and "last GC" times will be
slightly earlier than they really are.
Lift computing of these statistics into func gc, which has the
appropriate visibility into the process to compute them correctly.
Fixes one of the issues in #10323. This does not add new statistics
appropriate to the concurrent collector; it simply fixes existing
statistics that are being misreported.
Change-Id: I670cb16594a8641f6b27acf4472db15b6e8e086e
Reviewed-on: https://go-review.googlesource.com/11794
Reviewed-by: Russ Cox <rsc@golang.org>
Currently we report MemStats.PauseEnd in nanoseconds, but with no
particular 0 time. On Linux, the 0 time is when the host started. On
Darwin, it's the UNIX epoch. This is also inconsistent with the other
absolute time in MemStats, LastGC, which is always reported in
nanoseconds since 1970.
Fix PauseEnd so it's always reported in nanoseconds since 1970, like
LastGC.
Fixes one of the issues raised in #10323.
Change-Id: Ie2fe3169d45113992363a03b764f4e6c47e5c6a8
Reviewed-on: https://go-review.googlesource.com/11801
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
This change does clean up as preparation for fixing #11081.
- renames cfg to resolvConf for clarification
- adds a new type resolverConfig and its methods: init, update,
tryAcquireSema, releaseSema for mutual exclusion of resolv.conf data
- deflakes, simplifies tests for resolv.conf data; previously the tests
sometimes left some garbage in the data
Change-Id: I277ced853fddc3791dde40ab54dbd5c78114b78c
Reviewed-on: https://go-review.googlesource.com/10931
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Fixes#11307.
Fixes#11055.
Change-Id: I8d6b04cb509e62e27d6935b91ffe35fdaea4ebcd
Reviewed-on: https://go-review.googlesource.com/12028
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
Missed select case when adding the barrier last time.
All the more reason to refactor this code in Go 1.6.
Fixes#11643.
Change-Id: Ib0d19d6e0939296c0a3e06dda5e9b76f813bbc7e
Reviewed-on: https://go-review.googlesource.com/12086
Reviewed-by: Austin Clements <austin@google.com>
This is a copy of an upstream change to the tools repo:
https://go-review.googlesource.com/#/c/8924/
This is a second attempt at CL 8954, with the necessary change to
go/build's deps test.
Change-Id: Ib798498cf85fea0baec5667e9324d11f6ae8ad64
Reviewed-on: https://go-review.googlesource.com/9173
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
This is clearly what was intended all along. ./all.bash passes with this
change.
Change-Id: I16996da11cf1e4d2dc2a4434b7611a724691e8dc
Reviewed-on: https://go-review.googlesource.com/12068
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Joint hacking with josharian. Hints from matloob and Todd Neal.
Now with tests, and OROR.
Change-Id: Iff8826fde475691fb72a3eea7396a640b6274af9
Reviewed-on: https://go-review.googlesource.com/12041
Reviewed-by: Keith Randall <khr@golang.org>
