Ray Wu [Tue, 20 Apr 2021 17:41:37 +0000 (10:41 -0700)]
cmd/go: show warnings about symlinks only for patterns containing ...
Go commands show a warning message any time a pattern is expanded and a
symlink to a directory is encountered. For monorepo with non Go projects
using symlinks underneath, the output of go commands could be spammed by
this warning.
This commit includes the behavior change to only print this warning when
there's a pattern containing ... .
Fixes #35941
Change-Id: I094da2628bcd47b86fee8c6529d1066aa013a43b
Reviewed-on: https://go-review.googlesource.com/c/go/+/311890
Run-TryBot: Caleb Spare <cespare@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> Reviewed-by: Michael Matloob <matloob@golang.org>
Trust: Michael Matloob <matloob@golang.org>
ptrace1 must be nosplit because it is called from
forAndExecInChild. It was marked nosplit in the generated code
but not in the generator. CL 313230 regenerated the code and lost
the nosplit mark. This CL restores it.
Rob Findley [Thu, 1 Apr 2021 16:23:22 +0000 (12:23 -0400)]
go/scanner: optimize scanIdentifier
While profiling parsing, I noticed that scanIdentifier was extremely
hot, and could be optimized: it is responsible for a significant
fraction of scanning and had a lot of unnecessary branching, bounds
checks, and function calls.
This CL implements some of those optimizations, while trying to strike a
balance between optimization and readability. It achieves this by
optimizing for the common case of ASCII identifiers, falling back on the
slower scan when encountering the first non-ASCII character.
Change-Id: If78380004248e3ea75cfc78eb7f38f528124dced
Reviewed-on: https://go-review.googlesource.com/c/go/+/308611
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
Dan Scales [Tue, 27 Apr 2021 00:52:53 +0000 (17:52 -0700)]
cmd/compile: fix handling of ir.CurFunc during stenciling
The transform functions (specifically transformArgs, which is used from
transformCall/transformReturn) require that ir.CurFunc is set correctly.
Since transformCall() is used on the call of an instantiated generic
function, we need to set ir.CurFunc correctly in stencil(). Also,
correctly save/restore ir.CurFunc in genericSubst().
Without this fix, ir.CurFunc can be nil when we call TransformCall()
from stencil(), which leads to some temp variables being added
incorrectly to ir.TodoFunc (which leads to the fatal panic in the
issue).
Fixes #45722
Change-Id: Iddf4a67d28f2100dde8cde5dbc9ca1e00dad6089
Reviewed-on: https://go-review.googlesource.com/c/go/+/313869
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Change-Id: Ibce07f8f36f7c64f7022ce656f8efbec5dff3f82
Reviewed-on: https://go-review.googlesource.com/c/go/+/313829 Reviewed-by: Robert Griesemer <gri@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Rob Findley [Wed, 7 Apr 2021 21:43:09 +0000 (17:43 -0400)]
go/scanner: improve variety in benchmarks for file scanning
BenchmarkScanFile was scanning scanner.go, which makes comparison
difficult for a CL modifying that file. That file is also is not
necessarily representative syntax.
Add a few additional files as subtests to provide a larger variety of
metrics.
Change-Id: Ib78303c2546debd84a0b5478ae438ba891d9e6e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/308610
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
Rob Findley [Tue, 30 Mar 2021 12:26:24 +0000 (08:26 -0400)]
go/parser: add benchmarks for syntax-only parsing and object resolution
Change-Id: I73d1b2d18ab4051443d66c60df493d1163d0ba3f
Reviewed-on: https://go-review.googlesource.com/c/go/+/306150
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
os: don't check non-nil err twice in Symlink on windows
Change-Id: I398d324723025b559fdca783fc334de9be68f2d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/314030
Trust: Tobias Klauser <tobias.klauser@gmail.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Michael Anthony Knyszek [Wed, 21 Apr 2021 23:50:58 +0000 (23:50 +0000)]
runtime/metrics: add tiny allocs metric
Currently tiny allocations are not represented in either MemStats or
runtime/metrics, but they're represented in MemStats (indirectly) via
Mallocs. Add them to runtime/metrics by first merging
memstats.tinyallocs into consistentHeapStats (just for simplicity; it's
monotonic so metrics would still be self-consistent if we just read it
atomically) and then adding /gc/heap/tiny/allocs:objects to the list of
supported metrics.
Change-Id: Ie478006ab942a3e877b4a79065ffa43569722f3d
Reviewed-on: https://go-review.googlesource.com/c/go/+/312909
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>
Ian Lance Taylor [Tue, 27 Apr 2021 00:27:58 +0000 (17:27 -0700)]
syscall: restore signal mask after setting foreground process group
Fixes #37217
Change-Id: I0151bb77fc4c4552d1b19c31d784943b72f84b80
Reviewed-on: https://go-review.googlesource.com/c/go/+/313653
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Rob Findley [Tue, 27 Apr 2021 02:25:56 +0000 (22:25 -0400)]
go/types: don't panic when checking a ListExpr in exprInternal
As an alternative to CL 312149, add a catch-all error message in
exprInternal when encountering a ListExpr, rather than panicking.
We still might want something like CL 312149 to improve the error
message or recovery from bad indexing.
Change-Id: I865f7cc4eefa4a3b7bd8f3100df96d0144e1712f
Reviewed-on: https://go-review.googlesource.com/c/go/+/313909
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
Paul E. Murphy [Mon, 5 Apr 2021 18:40:48 +0000 (13:40 -0500)]
cmd/link: enforce larger alignment on split ppc64 text sections
When laying out, we lazily increase the alignment for text sections
as symbols are found requiring more. This works if the start of
the virtual address (VA) for the section is greater than or equal
to the alignment required by any symbols placed in this section.
The minimum alignment of the section is only known after all
symbols are placed. The starting VA of this section is adjusted
upwards in ld.(*Link).address to meet the requested alignment.
This is a problem if the starting VA of the text section is not
already aligned. This can happen when the final symbol placed
into the previous section results in an insufficiently aligned
start VA of the next text section.
To workaround this, additional text sections are split, and both
the starting VA, and alignment of the section are aligned up to
match the known worst case alignment.
64B is chosen as the worst case alignment for all ppc64 targets,
as it will respect PCALIGN and eventually prefixed instructions
which will be introduced in the future.
Likewise, the xcoff size calculations need to be improved to
handle padding bytes when function symbols have been aligned.
This is done by tracking the largest valid VA offset encountered
when placing symbols.
Change-Id: Iefef09a1ee7c963fb8dfce2288a084a95cb77fca
Reviewed-on: https://go-review.googlesource.com/c/go/+/307431
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
The code for generating a long constant versus generating an address
(either via a relocation, or known offset) should be handled in the
same place.
Resolve this by classifying memory arguments as C_LACON (a long
address constant) instead of C_LCON (a long constant).
Likewise, reorder AMOVD/AMOVW optab entries to keep similar
classifications near each other. An extra optab entry for
DWORD is also added to continue handling C_LACON arguments
correctly.
Change-Id: I5ce28400492a071f615125a9b8d260826f1600d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/312296
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com> Reviewed-by: Carlos Eduardo Seo <carlos.seo@linaro.org>
Trust: Carlos Eduardo Seo <carlos.seo@linaro.org>
Alex Brainman [Sun, 25 Apr 2021 08:26:30 +0000 (18:26 +1000)]
runtime: replace --buildmode with -buildmode in tests
While debugging issue #45638, I discovered that some tests were using
--buildmode command line parameter instead of -buildmode.
The --buildmode parameter is handled properly by the flag package - it
is read as -buildmode. But we should correct code anyway.
Updates #45638
Change-Id: I75cf95c7d11dcdf4aeccf568b2dea77bd8942352
Reviewed-on: https://go-review.googlesource.com/c/go/+/313351
Trust: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
Alex Brainman [Mon, 26 Apr 2021 07:56:10 +0000 (17:56 +1000)]
runtime: add missing import "C" in TestLibraryCtrlHandler
CL 211139 added TestLibraryCtrlHandler. But the CL left out import "C"
line in the test file that is supposed to be build with Cgo.
While debugging issue #45638, I discovered that the DLL built during
TestLibraryCtrlHandler does not have Dummy function. Adding import "C"
makes Dummy function appear in DLL function list.
TestLibraryCtrlHandler does not actually calls Dummy function. So I
don't see how this change affects issue #45638, but still let's make
this code correct.
Updates #45638
Change-Id: Ibab8fed29ef2ae446d0815842cf0bd040a5fb943
Reviewed-on: https://go-review.googlesource.com/c/go/+/313350
Trust: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
• Consolidate 'if ld.AllowErrors' conditions into an 'ld.errorf'
method.
• Rename SilenceErrors to SilencePackageErrors and clarify its
documentation. (There is currently no way to silence errors in the
module graph. Perhaps we should add one, but for now let's at least
clarify the existing behavior.)
• Move 'tidy -v' verbose logging into LoadPackages, where other
logging happens.
• Make checkMultiplePaths a loader method (since it only matters
during package loading anyway).
• Check package and module-graph errors in loadFromRoots instead of
LoadPackages. These checks were previously omitted on the
ImportFromFiles path, which seems likely to be a bug. (We now
suppress package errors explicitly in ImportFromFiles, which at
least makes the bug more explicit.)
This somewhat simplifies the code structure in preparation for
the lazy-mode tidy implementation.
For #36460
Change-Id: I3ce3586c6934989d5194f00f99e7cc4423cf767f
Reviewed-on: https://go-review.googlesource.com/c/go/+/313229
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Matloob <matloob@golang.org>
Rob Findley [Mon, 26 Apr 2021 23:23:05 +0000 (19:23 -0400)]
go/types: walk all imports when determining package name ambiguity
CL 209578 disambiguated paths among imported packages, but as
demonstrated in #43119, formatted types may reference packages that are
not directly imported.
Fix this by recursively walking all imports to determine whether there
is any ambiguity in the import graph. This might result in
over-qualification of names, but it is straightforward and should
eliminate any ambiguity.
In general this should be fine, but might introduce risk of infinite
recursion in the case of an importer bug, or performance problems for
very large import graphs. Mitigate the former by tracking seen packages,
and the latter by only walking the import graph once an error has been
produced.
Fixes #43119
Change-Id: If874f050ad0e808db8e354c2ffc88bc6d64fd277
Reviewed-on: https://go-review.googlesource.com/c/go/+/313035
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
syscall: on linux use accept4 in Accept, fall back to accept
Android seems to block the accept syscall in newer versions. Use accept4
instead on kernel versions that support it (Linux 2.6.28 and newer) and
fall back to accept on ENOSYS.
Fixes #45767
Change-Id: If190ace0e0213207fdaf6eeb79a5543ef18456de
Reviewed-on: https://go-review.googlesource.com/c/go/+/313769
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Robert Griesemer [Mon, 26 Apr 2021 19:50:44 +0000 (12:50 -0700)]
cmd/compile/internal/types2: respect IgnoreFuncBodies for function literals
Updates #45783.
Change-Id: Id552a60f262e2da62125acd6aec0901a82f5a29a
Reviewed-on: https://go-review.googlesource.com/c/go/+/313650
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Matthew Dempsky [Sat, 24 Apr 2021 09:12:55 +0000 (02:12 -0700)]
cmd/compile: workaround inlining of closures with type switches
Within clovar, n.Defn can also be *ir.TypeSwitchGuard. The proper fix
here would be to populate m.Defn and have it filled in too, but we
already leave it nil in inlvar. So for consistency, this CL does the
same in clovar too.
Eventually inl.go should be rewritten to fully respect IR invariants.
Fixes #45743.
Change-Id: I8b38e5d8b2329ad242de97670f2141f713954d28
Reviewed-on: https://go-review.googlesource.com/c/go/+/313289
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dan Scales <danscales@google.com>
Trust: Dan Scales <danscales@google.com>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
cmd/go/internal/modload: use (*loadPkg).mod only to indicate the module from which the package was loaded
The (*loadPkg).mod field normally indicates the module from which the
package was loaded. However, if the package was missing, we previously
used the mod field to instead store the module from which we intend to
load the package next time around.
That sort of dual use makes the semantics (and synchronization) of the
mod field much more complex to reason about. For example, it would be
nice to have the invariant that the mod field is always one of the
modules in the overall build list, or one of the modules selected in
the overall module graph. Similarly, it would be nice to have the
invariant that the version indicated by the mod field can coexist with
(without upgrading) all of the other versions indicated in the mod
fields of other packages.
This repurposing of the mod field appears to be solely in the service
of storing the module when resolving missing imports. To keep
conceptually-separate fields separate, I have changed
resolveMissingImports to store a slice of package–module pairs,
instead of just packages that need to be revisited.
This may increase allocation pressure slightly if we have many
unresolved packages, but most packages are not unresolved, and it
seems worth the cost to use a little extra memory if it means we can
reason more clearly about the (quite complex) behaviors of the module
loader.
For #36460
Change-Id: Ic434df0f38185c6e9e892c5e9ba9ff53b3efe01f
Reviewed-on: https://go-review.googlesource.com/c/go/+/312930
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Michael Matloob <matloob@golang.org>
runtime: use abi.FuncPCABI0 for libc syscall wrappers
In CL 288092 we made Darwin syscall wrappers as ABIInternal, so
their addresses taken from Go using funcPC are the actual function
entries, not the wrappers.
As we introduced internal/abi.FuncPCABIxxx intrinsics, use that.
And change the assembly functions back to ABI0.
Michael Anthony Knyszek [Fri, 23 Apr 2021 22:20:55 +0000 (22:20 +0000)]
runtime: fix scavenge min fraction constant floor division
Currently there's a minor bug where the constant for the min fraction of
time spent scavenging is rounded down to zero. I don't think this
affects anything in practice because this case is exceedingly rare and
extreme, but currently it doesn't properly prevent the pacing parameters
from getting out of hand in these extreme cases.
Fixes #44036.
Change-Id: I7de644ab0ecac33765c337a736482a0966882780
Reviewed-on: https://go-review.googlesource.com/c/go/+/313249 Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Ian Lance Taylor [Fri, 23 Apr 2021 19:03:48 +0000 (12:03 -0700)]
cmd/go: don't add generated SWIG C++ files to CompiledGoFiles
Also include SWIG C++ files in cgo hash.
For #28749
Fixes #37098
Change-Id: I6d912db2788200c2abdf328e382d4fbefda0a9ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/313131
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
Ruslan Andreev [Wed, 10 Mar 2021 11:31:59 +0000 (19:31 +0800)]
sync: improve sync.Pool object stealing
This CL provide abilty to randomly select P to steal object from its
shared queue. In order to provide such ability randomOrder structure
was copied from runtime/proc.go.
It should reduce contention in firsts Ps and improve balance of object
stealing across all Ps. Also, the patch provides new benchmark
PoolStarvation which force Ps to steal objects.
Benchmarks:
name old time/op new time/op delta
Pool-8 2.16ns ±14% 2.14ns ±16% ~ (p=0.425 n=10+10)
PoolOverflow-8 489ns ± 0% 489ns ± 0% ~ (p=0.719 n=9+10)
PoolStarvation-8 7.00µs ± 4% 6.59µs ± 2% -5.86% (p=0.000 n=10+10)
PoolSTW-8 15.1µs ± 1% 15.2µs ± 1% +0.99% (p=0.001 n=10+10)
PoolExpensiveNew-8 1.25ms ±10% 1.31ms ± 9% ~ (p=0.143 n=10+10)
[Geo mean] 2.68µs 2.68µs -0.28%
name old p50-ns/STW new p50-ns/STW delta
PoolSTW-8 15.0k ± 1% 15.1k ± 1% +0.92% (p=0.000 n=10+10)
name old p95-ns/STW new p95-ns/STW delta
PoolSTW-8 16.2k ± 3% 16.4k ± 2% ~ (p=0.143 n=10+10)
name old GCs/op new GCs/op delta
PoolExpensiveNew-8 0.29 ± 2% 0.30 ± 1% +2.84% (p=0.000 n=8+10)
name old New/op new New/op delta
PoolExpensiveNew-8 8.07 ±11% 8.49 ±10% ~ (p=0.123 n=10+10)
syscall, etc.: use abi.FuncPCABI0 for libc syscall wrappers
In CL 288092 we made Darwin syscall wrappers as ABIInternal, so
their addresses taken from Go using funcPC are the actual function
entries, not the wrappers.
As we introduced internal/abi.FuncPCABIxxx intrinsics, use that.
And change the assembly functions back to ABI0.
Do it on OpenBSD as well, as OpenBSD and Darwin share code
generator.
Change-Id: I408120795f7fc826637c867394248f8f373906bd
Reviewed-on: https://go-review.googlesource.com/c/go/+/313230
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
Than McIntosh [Wed, 21 Apr 2021 20:21:30 +0000 (16:21 -0400)]
cmd/compile: spos handling fixes to improve prolog debuggability
With the new register ABI, the compiler sometimes introduces spills of
argument registers in function prologs; depending on the positions
assigned to these spills and whether they have the IsStmt flag set,
this can degrade the debugging experience. For example, in this
function from one of the Delve regression tests:
we wind up with a prolog containing two spill instructions, the first
with line 14, the second with line 13. The end result for the user
is that if you set a breakpoint in foo and run to it, then do "step",
execution will initially stop at L14, then jump "backwards" to L13.
The root of the problem in this case is that an ArgIntReg pseudo-op is
introduced during expand calls, then promoted (due to lowering) to a
first-class statement (IsStmt flag set), which in turn causes
downstream handling to propagate its position to the first of the register
spills in the prolog.
To help improve things, this patch changes the rewriter to avoid
moving an "IsStmt" flag from a deleted/replaced instruction to an
Arg{Int,Float}Reg value, and adds Arg{Int,Float}Reg to the list of
opcodes not suitable for selection as statement boundaries, and
suppresses generation of additional register spills in defframe() when
optimization is disabled (since in that case things will get spilled
in any case).
This is not a comprehensive/complete fix; there are still cases where
we get less-than-ideal source position markers (ex: issue 45680).
Updates #40724.
Change-Id: Ica8bba4940b2291bef6b5d95ff0cfd84412a2d40
Reviewed-on: https://go-review.googlesource.com/c/go/+/312989
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Cherry Zhang <cherryyz@google.com>
Michael Anthony Knyszek [Fri, 23 Apr 2021 18:11:52 +0000 (18:11 +0000)]
runtime: simplify TestSelectStackAdjust
Currently this test attempts to trigger a concurrent GC in a very
indirect way, but the way it does so is extremely error-prone. This test
is virtually always prone to flaking based on test order. For example if
the test that executed immediately before this one made a big heap but
didn't clean it up, then this test could easily fail to trigger a GC.
I was able to prove this with a small reproducer.
This roundabout way of triggering a GC is also way overkill for this
test. It just wants to get goroutines in a select and shrink their
stacks. Every GC will schedule a stack for shrinking if it can.
Replace all the complicated machinery with a single runtime.GC call.
I've confirmed that the test consistently triggers a stack shrink,
noting that both shrinkstack's copystack call is made and that
syncadjustsudogs (the relevant function that's being indirectly tested)
are both called.
Fixes #44610.
Change-Id: Ib1c091e0d1475bf6c596f56dc9b85eaea366fc73
Reviewed-on: https://go-review.googlesource.com/c/go/+/313109
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>
misc/cgo/testso, misc/cgo/testsovar: fix for Windows
At least in mingw-clang it is not permitted to just name a .dll
on the command line. You must name the corresponding import
library instead, even though the dll is used when the executable
is run.
This fixes misc/cgo/testso and misc/cgo/testsovar on windows/arm64.
This code is needed for use with cgo proper
(as opposed to hand-written DLL calls, which
we always use but only exercise cgo execution,
not cgo linking).
llvm-mingw's lld produces an invalid windows/arm64 executable
when presented with relocations that are out of order
(the relocation for each function is emitted for two different
locations, so we end up with two sorted streams roughly
interlaced, not one sorted stream).
Sorting should not break other systems, so sort always.
cmd/link: fix PE section attributes for windows/arm64
The clang-mingw toolchain on windows/arm64 expects
.text to NOT be listed as containing initialized data and
.dwarf* to be listed as containing initialized data.
Neither is true today, resulting in the go .text and .dwarf*
not being merged with the system .text and .dwarf*.
Having multiple .text and .dwarf* sections confuses all
kinds of tools.
debug/dwarf: skip over zero-length compilation units
DWARF sections generated by mingw-clang seem to include these
(not often - only one out of many in the binary that I am looking at).
Skipping over them, everything parses correctly.
This makes TestDefaultLinkerDWARF pass on windows/arm64.
The cmd/link check of the objabi header was a bit lax because
historically the assembler has not included the full version string.
And the assembler didn't do that because it didn't have access to it:
that was buried inside the compiler.
But now that we have cmd/internal/objabi, all the tools have full
access to the expected string, and they can use it, which simplifies
the cmd/link consistency check.
This means that F must not be declared separately from _cgo_export.h:
any code that wants to refer to F must use #include "_cgo_export.h".
Unfortunately, the cgo prologue itself (the commented code before import "C")
cannot include "_cgo_export.h", because that file is itself produced from the
cgo Go sources and therefore cannot be a dependency of the cgo Go sources.
This CL rewrites misc/cgo/test to avoid redeclaring exported functions.
Most of the time, this is not a significant problem: just move the code
that needs the header into a .c file, perhaps with a wrapper exposed
to the cgo Go sources.
The one case that is potentially problematic is f7665, which is part of
the test for golang.org/issue/7665. That bug report explicitly identified
a bug in referring to the C name for an exported function in the same
Go source file as it was exported function. That is now impossible,
at least on Windows/ARM64, so the test is modified a bit and possibly
does not test what the original bug was. But the original bug should
be long gone: that part of the compiler has been rewritten.
Change-Id: I0d14d9336632f0e5e3db4273d9d32ef2cca0298d
Reviewed-on: https://go-review.googlesource.com/c/go/+/312029
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
When ABI wrappers are used, there are cases where in Go code we
need the PC of the defined function instead of the ABI wrapper.
Currently we work around this by define such functions as
ABIInternal, even if they do not actually follow the internal ABI.
This CL introduces internal/abi.FuncPCABIxxx functions as compiler
intrinsics, which return the underlying defined function's entry
PC if the argument is a direct reference of a function of the
expected ABI, and reject it if it is of a different ABI.
As a proof of concept, change runtime.goexit back to ABI0 and use
internal/abi.FuncPCABI0 to retrieve its PC.
Updates #44065.
Change-Id: I02286f0f9d99e6a3090f9e8169dbafc6804a2da6
Reviewed-on: https://go-review.googlesource.com/c/go/+/304232
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
Matthew Dempsky [Fri, 23 Apr 2021 19:18:59 +0000 (12:18 -0700)]
cmd/compile: generalize fix for lvalue-init evaluation
The previous fix to ensure early evaluation of lvalue-init statements
(CL 312632) added it after we'd already peeled away any array-OINDEX
expressions. But those might have init statements too, so we need to
do this earlier actually and perhaps more than once.
Longer term, lvalue expressions shouldn't have init statements anyway.
But rsc and I both spent a while looking into this earlier in the dev
cycle and couldn't come up with anything reasonable.
Fixes #45706.
Change-Id: I2d19c5ba421b3f019c62eec45774c84cf04b30ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/313011
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
cmd/go/internal/modload: remove the addedModuleFor map
At one point this map checked for infinite loops during package iteration.
The last write to the map was mistakenly removed in CL 251445.
However, looking at the code before that change, the map-based
termination strategy was never quite right to begin with: it checked
whether we had ever added any module for the given package, not
whether we had already added the module being proposed right now. (For
packages within nested modules, we could try adding multiple different
modules for a given package without looping.)
Moreover, the "looping trying to add package" failure message was only
marginally helpful. Users are capable of noticing that an invocation
of the 'go' command is taking too long, and will report a bug for an
infinite loop just as readily as a "looping trying to add package"
error.
We could try to add this tracking back in, but it's no substitute for
a proper proof of convergence, and the code is simpler without it.
Instead I'm going to add a proper proof of convergence — or, barring
that, a more accurate and useful check for failure to converge. In the
meantime, this invariantly-empty map isn't doing anybody any good.
For #36460
Change-Id: I2c111d4b4bf59159af0d7e62d1c0ef4ce0a43a71
Reviewed-on: https://go-review.googlesource.com/c/go/+/312929
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Matloob <matloob@golang.org>
math/rand: make the security warning clearer and more prominent
It is still a common misconception that math/rand can be used for
security-sensitive work if seeded with crypto/rand
(lazyledger/lazyledger-core#270). It can not.
cmd/compile: make sure ascompatee walk lhs init statements
CL 281152 improved ascompatee by removing the call to safeExpr on lhs.
But we forgot that lhs int statements, if any, must be walked prior
saving subexpressions, which cause the bug in #45706.
Fixes #45706
Change-Id: I0064315056ef4ca92ebf3c332c2e3a9bb2b26f68
Reviewed-on: https://go-review.googlesource.com/c/go/+/312632
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
David Chase [Wed, 21 Apr 2021 14:28:27 +0000 (10:28 -0400)]
cmd/go: make build cache tag sensitive to GOSSADIR; remove unused
GOSSADIR is a useful compiler flag for debugging.
Removed GO_SSA_PHI_LOC_CUTOFF, it is no longer mentioned in the compiler.
Change-Id: I3600f4c6ded95c9d34b85a6f0da6ba89b17a13ec
Reviewed-on: https://go-review.googlesource.com/c/go/+/312290
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
Michael Pratt [Fri, 7 Aug 2020 16:28:35 +0000 (16:28 +0000)]
runtime,runtime/metrics: add metric to track scheduling latencies
This change adds a metric to track scheduling latencies, defined as the
cumulative amount of time a goroutine spends being runnable before
running again. The metric is an approximations and samples instead of
trying to record every goroutine scheduling latency.
This change was primarily authored by mknyszek@google.com.
Change-Id: Ie0be7e6e7be421572eb2317d3dd8dd6f3d6aa152
Reviewed-on: https://go-review.googlesource.com/c/go/+/308933
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
Currently, when copying definition node of an inlined var, we do not
update var Defn field to point to new copied node. That causes all
inlined vars point to the same Defn, and ir.StaticValue can not find
inlined var in the lhs of its definition.
clovar creates new ONAME node for local variables or params of closure
inside inlined function, by copying most of the old node fields. So the
new Node.Defn is not modified, its lhs still refer to old node
instead of new one.
To fix this, we need to do two things:
- In subst.clovar, set a dummy Defn node for inlvar
- During subst.node, when seeing OAS/OAS2 nodes, after substituting, we
check if any node in lhs has the dummy Defn, then set it to the current
OAS/OAS2 node.
Fixes #45606
Change-Id: Ib517b753a7643756dcd61d36deae60f1a0fc53c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/312630
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
For go statement, the wrapper closure needs to esacpe because it
runs asynchronously. Currently, it is not allowed for closures to
escape in the runtime. We have worked around this in the runtime,
so it doesn't "go" any function with arguments and so doesn't
need wrapping. If it ever does, it is not that we can have the
closure not escape, which may lead to miscompilation. Instead,
make the closure escape (which will fail the compilation). In the
future we may allow go'd closure to escape in the runtime.
Than McIntosh [Thu, 22 Apr 2021 22:34:57 +0000 (18:34 -0400)]
cmd/compile: fix bug in defer wrapping
The defer wrapping feature added to the compiler's "order" phase
creates temporaries into which it copies defer arguments. If one of
these temps is large enough that we place it into the defer closure by
address (as opposed to by value), then the temp in question can't be
reused later on in the order phase, nor do we want a VARKILL
annotation for it at the end of the current block scope.
Test written by Cherry.
Updates #40724.
Change-Id: Iec7efd87ec5a3e3d7de41cdcc7f39c093ed1e815
Reviewed-on: https://go-review.googlesource.com/c/go/+/312869
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
Matthew Dempsky [Thu, 22 Apr 2021 22:38:33 +0000 (15:38 -0700)]
cmd/compile/internal/types2: add unsafe.Add and unsafe.Slice
This is a port of CL 312212, CL 312591 (except check_test.go), and
CL 312790 to types2.
Updates #19367.
Updates #40481.
Change-Id: I58ba0b0dad157baba3f82c909d5eb1268b931be4
Reviewed-on: https://go-review.googlesource.com/c/go/+/312511
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
Matthew Dempsky [Wed, 21 Apr 2021 10:29:18 +0000 (03:29 -0700)]
go/types: implement unsafe.Add and unsafe.Slice
Updates #19367.
Updates #40481.
Change-Id: Id2b2d2e3e716f91f0dd9e5102689a1ba90a819e4
Reviewed-on: https://go-review.googlesource.com/c/go/+/312213
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
Matthew Dempsky [Wed, 21 Apr 2021 07:12:02 +0000 (00:12 -0700)]
spec: add unsafe.Add and unsafe.Slice
Updates #19367.
Updates #40481.
Change-Id: I578066ad68d2cd6bea50df1a534cf799e4404a7f
Reviewed-on: https://go-review.googlesource.com/c/go/+/312212
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
Matthew Dempsky [Thu, 22 Apr 2021 19:42:33 +0000 (12:42 -0700)]
go/types: suppress index-out-of-bounds error on Unknown constants
Follow up to CL 312591, which was stumping rfindley and I for a
while. Credit to him for figuring out a repro and explaining the
correct solution.
Change-Id: Ib8578bba05f60fc41d382c34c5266d815441e7a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/312790
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
Matthew Dempsky [Thu, 22 Apr 2021 01:22:35 +0000 (18:22 -0700)]
go/types: cleanup and fix Checker.index
A couple minor spec compliance issues: constant, typed index operands
must still be representable as type "int", but should also be recorded
as their original type.
Fixes #45667.
Change-Id: Iefeb29f20a8e48350af83a62c9ae0e92198c5ef7
Reviewed-on: https://go-review.googlesource.com/c/go/+/312591
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com> Reviewed-by: Robert Griesemer <gri@golang.org>
Egon Elbre [Tue, 20 Apr 2021 14:38:54 +0000 (17:38 +0300)]
os: depend on Readlink only when necessary
Currently Readlink gets linked into the binary even when Executable is
not needed.
This reduces a simple "os.Stdout.Write([]byte("hello"))" by ~10KiB.
Previously the executable path was read during init time, because
deleting the executable would make "Readlink" return "(deleted)" suffix.
There's probably a slight chance that the init time reading would return
it anyways.
Updates #6853
Change-Id: Ic76190c5b64d9320ceb489cd6a553108614653d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/311790
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Michael Pratt [Wed, 7 Apr 2021 16:01:44 +0000 (12:01 -0400)]
runtime: skip work recheck for non-spinning Ms
When an M transitions from spinning to non-spinning state, it must
recheck most sources of work to avoid missing work submitted between its
initial check and decrementing sched.nmspinning (see "delicate dance"
comment).
Ever since the scheduler rewrite in Go 1.1 (golang.org/cl/7314062), we
have performed this recheck on all Ms before stopping, regardless of
whether or not they were spinning.
Unfortunately, there is a problem with this approach: non-spinning Ms
are not eligible to steal work (note the skip over the stealWork block),
but can detect work during the recheck. If there is work available, this
non-spinning M will jump to top, skip stealing, land in recheck again,
and repeat. i.e., it will spin uselessly.
The spin is bounded. This can only occur if there is another spinning M,
which will either take the work, allowing this M to stop, or take some
other work, allowing this M to upgrade to spinning. But the spinning is
ultimately just a fancy spin-wait.
golang.org/issue/43997 discusses several ways to address this. This CL
takes the simplest approach: skipping the recheck on non-spinning Ms and
allowing them to go to stop.
Results for scheduler-relevant runtime and time benchmarks can be found
at https://perf.golang.org/search?q=upload:20210420.5.
The new BenchmarkCreateGoroutinesSingle is a characteristic example
workload that hits this issue hard. A single M readies lots of work
without itself parking. Other Ms must spin to steal work, which is very
short-lived, forcing those Ms to spin again. Some of the Ms will be
non-spinning and hit the above bug.
With this fixed, that benchmark drops in CPU usage by a massive 68%, and
wall time 24%. BenchmarkNetpollBreak shows similar drops because it is
unintentionally almost the same benchmark (create short-living Gs in a
loop). Typical well-behaved programs show little change.
We also measure scheduling latency (time from goready to execute). Note
that many of these benchmarks are very noisy because they don't involve
much scheduling. Those that do, like CreateGoroutinesSingle, are
expected to increase as we are replacing unintentional spin waiting with
a real park.
Fixes #43997
Change-Id: Ie1d1e1800f393cee1792455412caaa5865d13562
Reviewed-on: https://go-review.googlesource.com/c/go/+/310850
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
cmd/go: add a source file in the multiple-paths module in TestScript/mod_tidy_replace
This situation is analogous to CL 309334: the test expects 'go mod
tidy' to fail due to a module used for more than one path in the build
list, but doesn't actually contain any packages or imports — so no
module is necessarily used at all, and the error only occurs if we
report it prematurely.
For #36460
Change-Id: I5ccecf30f280895eba913a8d62571872b75e710d
Reviewed-on: https://go-review.googlesource.com/c/go/+/312098
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Matloob <matloob@golang.org>
Cherry Zhang [Fri, 15 Jan 2021 22:58:41 +0000 (17:58 -0500)]
cmd/compile, runtime: add metadata for argument printing in traceback
Currently, when the runtime printing a stack track (at panic, or
when runtime.Stack is called), it prints the function arguments
as words in memory. With a register-based calling convention,
the layout of argument area of the memory changes, so the
printing also needs to change. In particular, the memory order
and the syntax order of the arguments may differ. To address
that, this CL lets the compiler to emit some metadata about the
memory layout of the arguments, and the runtime will use this
information to print arguments in syntax order.
Previously we print the memory contents of the results along with
the arguments. The results are likely uninitialized when the
traceback is taken, so that information is rarely useful. Also,
with a register-based calling convention the results may not
have corresponding locations in memory. This CL changes it to not
print results.
Previously the runtime simply prints the memory contents as
pointer-sized words. With a register-based calling convention,
as the layout changes, arguments that were packed in one word
may no longer be in one word. Also, as the spill slots are not
always initialized, it is possible that some part of a word
contains useful informationwhile the rest contains garbage.
Instead of letting the runtime recreating the ABI0 layout and
print them as words, we now print each component separately.
Aggregate-typed argument/component is surrounded by "{}".
For example, for a function
F(int, [3]byte, byte) int
when called as F(1, [3]byte{2, 3, 4}, 5), it used to print
F(0x1, 0x5040302, 0xXXXXXXXX) // assuming little endian, 0xXXXXXXXX is uninitilized result
Now prints
F(0x1, {0x2, 0x3, 0x4}, 0x5).
Note: the liveness tracking of the spill splots has not been
implemented in this CL. Currently the runtime just assumes all
the slots are live and print them all.
Paul E. Murphy [Fri, 16 Apr 2021 20:15:17 +0000 (15:15 -0500)]
cmd/asm: fix RLDCR const1,reg,const2,reg on ppc64
The extended opcode field (XO) is generated incorrectly. OPVCC
assumes an X-form like layout for the XO field. MD-form insns
also have an XO field, but it is both smaller and in a different
bit position.
This hasn't been noticed since const1 == 0 matches as a register
argument instead of a constant, thus it is unlikely anyone has
attempted to assemble this instruction with a non-zero shift
argument.
Likewise, update all other MD-form instructions using OPVCC
to use the new OPMD function.
Change-Id: Id81fa2727fb701431911a05492c2038415ad0a4d
Reviewed-on: https://go-review.googlesource.com/c/go/+/310851
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com> Reviewed-by: Carlos Eduardo Seo <carlos.seo@linaro.org>
cgocallback calls cgocallbackg after switching the stack. Call it
indirectly to bypass the linker's nosplit check.
Apparently (at least on Windows) cgocallbackg can use quite a bit
stack space in a nosplit chain. We have been running over the
nosplit limit, or very close to the limit. Since it switches
stack in cgocallback, it is not meaningful to count frames above
cgocallback and below cgocallbackg together. Bypass the check.
For #45658.
Change-Id: Ie22017e3f82d2c1fcc37336696f2d02757856399
Reviewed-on: https://go-review.googlesource.com/c/go/+/312669
Trust: Cherry Zhang <cherryyz@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Rob Findley [Wed, 21 Apr 2021 03:25:12 +0000 (23:25 -0400)]
go/types: re-enable a commented out test
This test was unnecessarily commented out in CL 312190: re-enable it and
update its assertions.
Change-Id: Ic08563e25c9b05a8e35d67690f5d27a761133266
Reviewed-on: https://go-review.googlesource.com/c/go/+/312097
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
Rob Findley [Wed, 21 Apr 2021 03:10:09 +0000 (23:10 -0400)]
go/types: combine two loops (cleanup of TODO)
This is an exact port of CL 307949 to go/types.
Change-Id: I796f3030a86d76deb80e58bb547460b586480911
Reviewed-on: https://go-review.googlesource.com/c/go/+/312096
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
cmd/compile: add restrictions on the shift amount range of arm64 various instructions
For arm64 constant shift instructions, e.g., LSL(immediate), they use
only the low 6 bits. To conform the semantics of the hardware instructions,
this CL comments in ARM64OPS.go about restricted AuxInt ranges for the
various instructions involved.
Ian Lance Taylor [Wed, 21 Apr 2021 23:44:59 +0000 (16:44 -0700)]
runtime: don't run TestCrashDumpsAllThreads in parallel
It sometimes seems to time out on slow systems, perhaps due to
being run at the same time as a lot of other work.
Also move the code to testdata/testprog, so that we don't have to
build it separately.
I hope that this
Fixes #35356
Change-Id: I875b858fa23836513ae14d3116461e22fffd5352
Reviewed-on: https://go-review.googlesource.com/c/go/+/312510
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Rob Findley [Wed, 21 Apr 2021 02:59:59 +0000 (22:59 -0400)]
go/types: combine all type inference in a single function
This is a port of CL 306170 to go/types, adjusted for the different
positioning API.
Some of the error positions in tests had to be adjusted, but I think the
new locations are better.
Change-Id: Ib157fbb47d7483e3c6302bd57f5070bd74602a36
Reviewed-on: https://go-review.googlesource.com/c/go/+/312191
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
Michael Anthony Knyszek [Wed, 21 Apr 2021 20:45:44 +0000 (20:45 +0000)]
runtime: call nanotimeQPC from nanotime1 normally
Currently we call runtimeQPC as ABIInternal because it shaves off 24
bytes by not having an extra wrapper, and at the time we were exceeding
the nosplit stack limit in some cases.
However, this code was written before we had the regabiargs GOEXPERIMENT
flag, and wasn't properly flagged. Naturally, with regabiargs enabled,
it leads to garbage being returned, because it needs to store
runtimeQPC's result to the stack.
We didn't notice this because today runtimeQPC is only used in Wine, not
on any native Windows platform.
Back when I wrote this code, it appeared to be necessary on even native
Windows, but it turns out that's not true anymore. Turn it back into a
native call through a wrapper.
For #40724.
Change-Id: Ia2e5901965ef46c5f299daccef49952026854fe6
Reviewed-on: https://go-review.googlesource.com/c/go/+/312429
Trust: Michael Knyszek <mknyszek@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Andrew G. Morgan [Sat, 27 Mar 2021 02:27:22 +0000 (19:27 -0700)]
syscall: syscall.AllThreadsSyscall signal handling fixes
The runtime support for syscall.AllThreadsSyscall() functions had
some corner case deadlock issues when signal handling was in use.
This was observed in at least 3 build test failures on ppc64 and
amd64 architecture CGO_ENABLED=0 builds over the last few months.
The fixes involve more controlled handling of signals while the
AllThreads mechanism is being executed. Further details are
discussed in bug #44193.
The all-threads syscall support is new in go1.16, so earlier
releases are not affected by this bug.
Fixes #44193
Change-Id: I01ba8508a6e1bb2d872751f50da86dd07911a41d
Reviewed-on: https://go-review.googlesource.com/c/go/+/305149 Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Michael Pratt <mpratt@google.com>
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Change-Id: Id72353e2771eba2efbb1544d5f0be65f8a9f0433
Reviewed-on: https://go-review.googlesource.com/c/go/+/311380
Run-TryBot: Carlos Eduardo Seo <carlos.seo@linaro.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Carlos Eduardo Seo <carlos.seo@linaro.org>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Rob Findley [Wed, 21 Apr 2021 02:27:15 +0000 (22:27 -0400)]
go/types: simplify Checker.Call
This is a direct port of CL 306171 to go/types.
Change-Id: I6f0102c76bad3f1d939074fc4c59f772dd417498
Reviewed-on: https://go-review.googlesource.com/c/go/+/312190
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>