Currently the pacer is designed to pace against the edge. Specifically,
it tries to find the sweet spot at which there are zero assists, but
simultaneously finishes each GC perfectly on time.
This pretty much works, despite the noisiness of the measurement of the
cons/mark ratio, which is central to the pacer's function. (And this
noise is basically a given; the cons/mark ratio is used as a prediction
under a steady-state assumption.) Typically, this means that the GC
might assist a little bit more because it started the GC late, or it
might execute more GC cycles because it started early. In many cases the
magnitude of this variation is small.
However, we can't possibly control for all sources of noise, especially
since some noise can come from the underlying system. Furthermore, there
are inputs to the measurement that have effectively no restrictions on
how they vary, and the pacer needs to assume that they're essentially
static when they might not be in some applications (i.e. goroutine
stacks).
The result of high noise is that the variation in when a GC starts is
much higher, leading to a significant amount of assists in some GC
cycles. While the GC cycle frequency basically averages out in the
steady-state in the face of this variation, starting a GC late has the
significant drawback of reducing application latencies.
This CL thus biases the pacer toward avoiding assists by picking a
cons/mark smoothing function that takes the maximum measured cons/mark
over 5 cycles total. I picked 5 cycles because empirically this was the
best trade-off between window size and smoothness for a uniformly
distributed jitter in the cons/mark signal. The cost here is that if
there's a significant phase change in the application that makes it less
active with the GC, then we'll be using a stale cons/mark measurement
for 5 cycles. I suspect this is fine precisely because this only happens
when the application becomes less active, i.e. when latency matters
less.
Another good reason for this particular bias is that even though the GC
might start earlier and end earlier on average, resulting in more
frequent GC cycles and potentially worse throughput, it also means that
it uses less memory used on average. As a result, there's a reasonable
workaround in just turning GOGC up slightly to reduce GC cycle
frequency and bringing memory (and hopefully throughput) levels back to
the same baseline. Meanwhile, there should still be fewer assists than
before which is just a clear improvement to latency.
Lastly, this CL updates the GC pacer tests to capture this bias against
assists and toward GC cycles starting earlier in the face of noise.
Sweet benchmarks didn't show any meaningful difference, but real
production applications showed a reduction in tail latencies of up
to 45%.
Updates #56966.
Change-Id: I8f03d793f9a1c6e7ef3524d18294dbc0d7de6122
Reviewed-on: https://go-review.googlesource.com/c/go/+/467875
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
This is relatively easy using the new traceback iterator.
Ancestor tracebacks are now limited to 50 frames. We could keep that
at 100, but the fact that it used 100 before seemed arbitrary and
unnecessary.
Fixes#7181
Updates #54466
Change-Id: If693045881d84848f17e568df275a5105b6f1cb0
Reviewed-on: https://go-review.googlesource.com/c/go/+/475960
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Correct an error message to missing section, not unreachable
symbol.
Also, under -v >= 2, dump symbol info on error for debugging.
Updates #58966.
Change-Id: I0f832c517d64f4b672b313a8b9be2d028744f945
Reviewed-on: https://go-review.googlesource.com/c/go/+/476735
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
It was carryover from the mips64 port (where it represented the platform
GP register) but LoongArch platform ABI doesn't have the GP concept.
Change-Id: Iea326ae13676e95b040b52aaadc08d311b507bd3
Reviewed-on: https://go-review.googlesource.com/c/go/+/475815
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
When compiling Go programs to WebAssembly, the memory allocation
strategy was neither releasing memory to the OS nor reusing blocks freed
by calls to runtime.sysFreeOS.
This CL unifies the plan9 and wasm memory management strategy
since both platforms use a linear memory space and do not have a
mechanism for returning memory blocks to the OS.
Fixes#59061
Change-Id: I282ba93c0fe1a0961a31c0825b2a7e0478b8713d
GitHub-Last-Rev: 1c485be4fb
GitHub-Pull-Request: golang/go#59065
Reviewed-on: https://go-review.googlesource.com/c/go/+/476717
Reviewed-by: Julien Fabre <ju.pryz@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Evan Phoenix <evan@phx.io>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This is a roll-forward of CL 477395 which was rolled back in CL 477736.
The earlier CL failed because we didn't account for the fact that
on some targets PIE is the default. That is now fixed.
Change-Id: I3e93faa9506033d27040cc9920836f010e05cd26
Reviewed-on: https://go-review.googlesource.com/c/go/+/477919
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Change-Id: I8f8d38c48d4ffe70d15330ea0d4794f264c88f25
Reviewed-on: https://go-review.googlesource.com/c/go/+/477918
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Before this CL, the code checked whether external linking was
required for -buildmode=pie. This CL changes it to also consider
whether external linking is required if PIE is the default build mode.
Change-Id: I5ac62fc027622576a152a8b7b5d97bc1d112adb4
Reviewed-on: https://go-review.googlesource.com/c/go/+/477917
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
On Windows we default to PIE, except in race mode.
Pass isRace to platform.DefaultPIE to centralize that decision.
This is in preparation for adding another call to DefaultPIE.
Change-Id: I91b75d307e7d4d260246a934f98734ddcbca372a
Reviewed-on: https://go-review.googlesource.com/c/go/+/477916
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Restore CL 477195, which was reverted in CL 477795.
This version includes CL 477397, which fixes the test problems
with CL 477195. CL 477397 was not submitted because it had an
unrelated failure on darwin-amd64. That failure is fixed by CL 477736.
Fixes#31544
Change-Id: I3a2258cd0ca295cede3511ab212e56fd0114f94a
Reviewed-on: https://go-review.googlesource.com/c/go/+/477839
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The Go linker has always used IMAGE_SYM_TYPE_NULL as COFF symbol
type [1] when external linking and array of structs
(IMAGE_SYM_DTYPE_ARRAY<<4+IMAGE_SYM_TYPE_STRUCT) when internal linking.
This behavior seems idiosyncratic, and looking at the git history it
seems that it has probably been cargo culted from earlier toolchains.
This CL updates the Go linker to use IMAGE_SYM_DTYPE_FUNCTION<<4 for
those symbols representing functions, and IMAGE_SYM_TYPE_NULL otherwise.
This new behavior better represents the symbol types, and can help
other tools interpreting the intent of each symbol, e.g. debuggers or
tools extracting debug info from Go binaries. It also mimics what other
toolchains do, i.e. MSVC, LLVM, and GCC.
[1] https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#type-representation
Change-Id: I6b39b2048e95f0324b2eb90c85802ce42db455d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/475856
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Add the following common local transformations
(t + x) - (t + y) == x - y
(t + x) - (y + t) == x - y
(x + t) - (y + t) == x - y
(x + t) - (t + y) == x - y
(x - t) + (t + y) == x + y
(x - t) + (y + t) == x + y
The compiler itself matches such patterns many times. This also aligns with other popular compilers.
Fixes#59111
Change-Id: Ibdfdb414782f8fcaa20b84ac5d43d0d9ae2c7b60
GitHub-Last-Rev: 1aad82e62e
GitHub-Pull-Request: golang/go#59119
Reviewed-on: https://go-review.googlesource.com/c/go/+/477555
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
This reverts CL 477195.
Reason for revert: test fails on darwin and solaris builders.
Change-Id: I68085f06bc84b0b8649804b8968626ed0e788931
Reviewed-on: https://go-review.googlesource.com/c/go/+/477795
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Bypass: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Currently, on e == nil or e.Tag == 0, SeekPC returns with a nil error.
Instead, indicate that the PC is unknown.
Change-Id: I9594296034e2df872e399bd800b00cb565c413c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/473695
Reviewed-by: Carlos Amedee <carlos@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Rather than implying that all ppc64 GOARCHs use function descriptors,
provide a define for platforms that make use of function descriptors.
Condition on GO_PPC64X_HAS_FUNCDESC when choosing whether or not
to load the entry address from the first slot of the function
descriptor.
Updates #56001.
Change-Id: I9cdc788f2de70a1262c17d8485b555383d1374b5
Reviewed-on: https://go-review.googlesource.com/c/go/+/476117
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This will be used for operating systems other than AIX and Linux (both of
which provide a more specific version).
Updates #56001
Change-Id: Ia1de994866b66f03c83696faa92d0531a0b75273
Reviewed-on: https://go-review.googlesource.com/c/go/+/473698
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Also map uname output containing powerpc64 to ppc64 on openbsd.
Updates #56001
Change-Id: I6a4470cb0e5d6c6940d5268a6a06d23430c7859a
Reviewed-on: https://go-review.googlesource.com/c/go/+/475635
Reviewed-by: Eric Grosse <grosse@gmail.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The previous documentation used a double-negative in describing Join behavior; this use of language could be confusing.
This update removes the double-negative.
Change-Id: If13e88682e865314a556e7d381143a97fa5486d9
GitHub-Last-Rev: 92b3f88a5d
GitHub-Pull-Request: golang/go#59082
Reviewed-on: https://go-review.googlesource.com/c/go/+/477095
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
There is already a case that when buildmode=shared passes only the
basename of the -o argument to the link command to the linker (and
runs in the directory of that argument) to avoid having that
(temporary) directory of the file be included in the LC_ID_DYLIB load
command. Extend the case to buildmode=plugin, because the same thing
can happen there.
This can only happen on darwin: the -o command can be embedded into
Mach-O and PE binaries, but plugin isn't supported on Windows.
For #58557
Change-Id: I7a4a5627148e77c6906ac4583af3d9f053d5b249
Reviewed-on: https://go-review.googlesource.com/c/go/+/477296
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Change-Id: If5613ae73d03c196f26340fd6293e37c78c29bd1
Reviewed-on: https://go-review.googlesource.com/c/go/+/477395
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Fixes#31544
Change-Id: Ic99875ad227876eb741e93653589310327c9c0ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/477195
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
For the following description, consider the following basic block graph:
b1 ───┐┌──── b2
││
││
▼▼
b3
For register allocator transitions between basic blocks, there are two
key passes (significant paraphrasing):
First, each basic block is visited in some predetermined visit order.
This is the core visitOrder range loop in regAllocState.regalloc. The
specific ordering heuristics aren't important here, except that the
order guarantees that when visiting a basic block at least one of its
predecessors has already been visited.
Upon visiting a basic block, that block sets its expected starting
register state (regAllocState.startRegs) based on the ending register
state (regAlloc.State.endRegs) of one of its predecessors. (How it
chooses which predecessor to use is not important here.)
From that starting state, registers are assigned for all values in the
block, ultimately resulting in some ending register state.
After all blocks have been visited, the shuffle pass
(regAllocState.shuffle) ensures that for each edge, endRegs of the
predecessor == startRegs of the successor. That is, it makes sure that
the startRegs assumptions actually hold true for each edge. It does this
by adding moves to the end of the predecessor block to place values in
the expected register for the successor block. These may be moves from
other registers, or from memory if the value is spilled.
Now on to the actual problem:
Assume that b1 places some value v1 into register R10, and thus ends
with endRegs containing R10 = v1.
When b3 is visited, it selects b1 as its model predecessor and sets
startRegs with R10 = v1.
b2 does not have v1 in R10, so later in the shuffle pass, we will add a
move of v1 into R10 to the end of b2 to ensure it is available for b3.
This is all perfectly fine and exactly how things should work.
Now suppose that b3 does not use v1. It does need to use some other
value v2, which is not currently in a register. When assigning v2 to a
register, it finds all registers are already in use and it needs to dump
a value. Ultimately, it decides to dump v1 from R10 and replace it with
v2.
This is fine, but it has downstream effects on shuffle in b2. b3's
startRegs still state that R10 = v1, so b2 will add a move to R10 even
though b3 will unconditionally overwrite it. i.e., the move at the end
of b2 is completely useless and can result in code like:
// end of b2
MOV n(SP), R10 // R10 = v1 <-- useless
// start of b3
MOV m(SP), R10 // R10 = v2
This is precisely what happened in #58298.
This CL addresses this problem by dropping registers from startRegs if
they are never used in the basic block prior to getting dumped. This
allows the shuffle pass to avoid placing those useless values into the
register.
There is a significant limitation to this CL, which is that it only
impacts the immediate predecessors of an overwriting block. We can
discuss this by zooming out a bit on the previous graph:
b4 ───┐┌──── b5
││
││
▼▼
b1 ───┐┌──── b2
││
││
▼▼
b3
Here we have the same graph, except we can see the two predecessors of
b1.
Now suppose that rather than b1 assigning R10 = v1 as above, the
assignment is done in b4. b1 has startRegs R10 = v1, doesn't use the
value at all, and simply passes it through to endRegs R10 = v1.
Now the shuffle pass will require both b2 and b5 to add a move to
assigned R10 = v1, because that is specified in their successor
startRegs.
With this CL, b3 drops R10 = v1 from startRegs, but there is no
backwards propagation, so b1 still has R10 = v1 in startRegs, and b5
still needs to add a useless move.
Extending this CL with such propagation may significantly increase the
number of useless moves we can remove, though it will add complexity to
maintenance and could potentially impact build performance depending on
how efficiently we could implement the propagation (something I haven't
considered carefully).
As-is, this optimization does not impact much code. In bent .text size
geomean is -0.02%. In the container/heap test binary, 18 of ~2500
functions are impacted by this CL. Bent and sweet do not show a
noticeable performance impact one way or another, however #58298 does
show a case where this can have impact if the useless instructions end
up in the hot path of a tight loop.
For #58298.
Change-Id: I2fcef37c955159d068fa0725f995a1848add8a5f
Reviewed-on: https://go-review.googlesource.com/c/go/+/471158
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
Previously, the reverse proxy is unable to detect
the support for hijack or flush if those things
are residing in the response writer in a wrapped
manner.
The reverse proxy now makes use of the new http
response controller as the means to discover
the underlying flusher and hijacker associated
with the response writer, allowing wrapped flusher
and hijacker become discoverable.
Change-Id: I53acbb12315c3897be068e8c00598ef42fc74649
Reviewed-on: https://go-review.googlesource.com/c/go/+/468755
Run-TryBot: Damien Neil <dneil@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This presumably got missed in CL 393875.
Change-Id: I4f2de00ebd6ec405d5e289a7f8c2fc781607260b
Reviewed-on: https://go-review.googlesource.com/c/go/+/475617
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
The backtrace knows to stop in the system stack due to writing to the SP,
so here the fake mstart caller in the system stack is no longer needed and
can be removed
ref. CL 288799
Change-Id: I0841e75fd515cf6a0d98abe4cffc3f63fc275e0e
Reviewed-on: https://go-review.googlesource.com/c/go/+/416035
Auto-Submit: Wayne Zuo <wdvxdr@golangcn.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: WANG Xuerui <git@xen0n.name>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Looks like CL 475735 contained a not-quite-up-to-date version
of the generated file. Maybe ABSFL was in an earlier version of the CL
and was removed before checkin without regenerating the generated file?
In any case, update the generated file. Shouldn't cause a problem, as
that field isn't used in x86/ssa.go.
Change-Id: I3f0b7d41081ba3ce2cdcae385fea16b37d7de81b
Reviewed-on: https://go-review.googlesource.com/c/go/+/477096
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Wayne Zuo <wdvxdr@golangcn.org>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
If the -url flag is provided, when encountering a type checking error,
the compiler will also print a URL to a more detailed description of
the error and an example, if available.
Example uses:
go tool compile -url filename.go
go build -gcflags=-url pkg/path
For instance, a duplicate declaration of an identifier will report
https://pkg.go.dev/internal/types/errors#DuplicateDecl
We may refine the provided URL over time.
Change-Id: Iabe3008a49d9dd88bf690f99e4a4a5432dc08786
Reviewed-on: https://go-review.googlesource.com/c/go/+/476716
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
When corpusEntryData failed in workerClient.fuzz and
workerClient.minimize, the shared memory mutex wasn't properly given up,
which would cause a deadlock when worker.cleanup was called.
This was tickled by #59062, wherein the fuzz cache directory would be
removed during operation of the fuzzer, causing corpusEntryData to fail
because the entry files no longer existed.
Updates #51484
Change-Id: Iea284041c20d1581c662bddbbc7e12191771a364
Reviewed-on: https://go-review.googlesource.com/c/go/+/476815
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Roland Shoemaker <roland@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
I think I confused myself in CL 476335. The TTY check did fix the
problem with os.Stdout, but it was still possible to get the same
problem in other ways. I fixed that by making the splice call blocking,
but it turns out that doing that is enough to fix the TTY problem also.
So we can just remove the TTY check.
Fixes#59041
Change-Id: I4d7ca9dad8361001edb4cfa96bb29b1badb54df0
Reviewed-on: https://go-review.googlesource.com/c/go/+/477035
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
These error codes are returned on windows in case a particular functions
is not supported.
Updates #41198
Change-Id: Ic31755a131d4e7c96961ba54f5bb51026fc7a563
Reviewed-on: https://go-review.googlesource.com/c/go/+/476916
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
but this time, correctly.
children of Returns can have For/Range loops in them,
and those must be visited.
Includes test to verify that the optimization occurs,
and also that the problematic case that broke the original
optimization is now correctly handled.
Change-Id: If5a94fd51c862d4bfb318fec78456b7b202f3fcd
Reviewed-on: https://go-review.googlesource.com/c/go/+/472355
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The implementation for lockType, lock, unlock and isNotSupported is the
same on plan9 as on other platforms where filelocks are unsupported.
Change-Id: I8b9c0bdc429e23346ab9145ec3814622319427fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/476915
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
As suggested by Bryan, also update (Errno).Is on windows to include the
missing oserror cases that are covered on other platforms.
Quoting Bryan:
> Windows syscalls don't actually return those errors, but the dummy Errno
> constants defined on Windows should still have the same meaning as on
> Unix.
Updates #41198
Change-Id: I15441abde4a7ebaa3c6518262c052530cd2add4b
Reviewed-on: https://go-review.googlesource.com/c/go/+/476875
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
The LoongArch ELF psABI v2.00 revamped the relocation design, largely
moving to using the `pcalau12i + addi/ld/st` pair for PC-relative
addressing within +/- 32 bits. The "pcala" in `pcalau12i` stands for
"PC-aligned add"; the instruction's semantics happen to coincide with
arm64's `adrp`.
Add support for emitting this instruction as part of the relevant
addressing ops, for use with new reloc types later.
Updates #58784
Change-Id: Ic1747cd9745aad0d1abb9bd78400cd5ff5978bc8
Reviewed-on: https://go-review.googlesource.com/c/go/+/455016
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
Auto-Submit: Wayne Zuo <wdvxdr@golangcn.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Wayne Zuo <wdvxdr@golangcn.org>
Reviewed-by: xiaodong liu <teaofmoli@gmail.com>
Reviewed-by: Meidan Li <limeidan@loongson.cn>
TryBot-Result: Gopher Robot <gobot@golang.org>
The fuzzing cache for interesting inputs is shared across all
invocations of scripts by default. When 'go clean -fuzzcache' is called,
or fuzz targets in different scripts have the same names, we can get
race-y unexpected behavior.
Since there isn't a easy way to set just the fuzz cache directory (test
has the flag -test.fuzzcachedir, but it requires setting it on each call
to 'go test'), instead we just consistently set GOCACHE to point to a
directory in the WORK dir. As a byproduct this also prevents usage of a
shared build cache, so we see an increase in build time for these tests.
Updates #59062
Change-Id: Ie78f2943b94f3302c5bdf1f8a1e93b207853666a
Reviewed-on: https://go-review.googlesource.com/c/go/+/476755
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Auto-Submit: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Fixes#53747
Based on CL 416514
Change-Id: I1ff79c6290b06dfa8672a473045e8fe80c22afcf
GitHub-Last-Rev: 74fba9b309
GitHub-Pull-Request: golang/go#59013
Reviewed-on: https://go-review.googlesource.com/c/go/+/476015
Run-TryBot: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Per the updated go.dev/wiki/Deprecated, those APIs replaced by
crypto/ecdh (added in Go 1.20) can now be marked as deprecated
in Go 1.21.
Updates #52221
Updates #34648
Change-Id: Id0e11d7faa3a58a1716ce1ec6e2fff97bab96259
Reviewed-on: https://go-review.googlesource.com/c/go/+/459977
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Meant to check if the slice was empty, accidentally dumped the entire
slice to stdout...
Change-Id: I968cb2f20ffb006e4dcfea65a1bad794aac05d17
Reviewed-on: https://go-review.googlesource.com/c/go/+/476795
Auto-Submit: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Roland Shoemaker <roland@golang.org>
