Currently, run.go sets GOEXPERIMENT build tags based on the
*difference* from the baseline experiment configuration, rather than
the absolute experiment configuration. This differs from cmd/go. As a
result, if we set a baseline configuration and don't override it with
a GOEXPERIMENT setting, run.go won't set any GOEXPERIMENT build tags,
instead of setting the tags corresponding to the baseline
configuration.
Fix this by making compile -V=goexperiment produce the full
GOEXPERIMENT configuration, which run.go can then use to set exactly
the right set of build tags.
For #40724.
Change-Id: Ieda6ea62f1a1fabbe8d749d6d09c198fd5ca8377
Reviewed-on: https://go-review.googlesource.com/c/go/+/310171
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
We need to adjust baseline experiment configuration based on the
configured GOOS and GOARCH, so it can't live in goexperiment. Move it
to objabi.
Change-Id: I65f4ce56902c6c1a82735050773c58f2d1320cc6
Reviewed-on: https://go-review.googlesource.com/c/go/+/310169
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The shift amount should be masked to avoid rotation values
beyond the numer of bits. In this case, if the shift amount
is 0, it should rotate 0, not 32.
Fixes#45589
Change-Id: I1e764497a39d0ec128e29af42352b70c70b2ecc5
Reviewed-on: https://go-review.googlesource.com/c/go/+/310569
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>
Only complain about missing type; leave it to type-checking
to decide whether "..." is permitted in the first place.
Fixes#43674.
Change-Id: Icbc8f084e364fe3ac16076406a134354219c08d0
Reviewed-on: https://go-review.googlesource.com/c/go/+/310209
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This requires consolidating the register move operations into a
single case entry in asmout. These moves are also used to
sign/zero-extend register values.
Combine the three asmout cases for register moves. This allows
AMOVWZ and AMOVW to be handled with the same optab entries.
Likewise, remove the diagnostic error for non-zero constant
loads into R0 using the register move operations, it is not
possible to match this asmout case with a non-zero constant.
Finally, fix the load constant 0 via "MOV[BHW]{,Z} $0, Rx".
These now generate "li Rx, $0" instead of a zero/sign-extend
of the contents of R0.
Change-Id: Ia4a263661582f10feda27ee21cb121e05ea931dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/308190
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>
This is probably unlikely in practice, but when debugging alignment
related issues on ppc64 using very small text section splits, the elf
header could grow beyond the preallocated space and quietly stomp
on the first few text sections.
Change-Id: Ided58aa0b1e60f9da4b3cb277e4ebafcee4ec693
Reviewed-on: https://go-review.googlesource.com/c/go/+/307430
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
There are several assembly functions that transition from the Windows
ABI to the Go ABI. These all need to save all registers that are
callee-save in the Windows ABI and caller-save in the Go ABI and
prepare the register state for Go. However, they all do this slightly
differently and most of them don't save the necessary XMM registers
for this transition (which could corrupt them in the C caller).
Furthermore, now that we have a carefully specified Go ABI, it's clear
that none of these actually get all of the details 100% right.
So, unify this code into two macros in a shared header in
runtime/cgo/abi_amd64.h that handle all necessary registers and setup
and use these macros everywhere on Windows that handles transitions
from C to Go.
Change-Id: I62f41345a507aad1ca383814ac8b7e2a9ffb821e
Reviewed-on: https://go-review.googlesource.com/c/go/+/309769
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
CL 308931 ported several runtime assembly functions to ABIInternal so
that compiler-generated ABIInternal calls don't go through ABI
wrappers, but it missed the runtime assembly functions that are
actually defined in internal/bytealg.
This eliminates the cost of wrappers for the BleveQuery and
GopherLuaKNucleotide benchmarks, but there's still more to do for
Tile38.
0-base 1-wrappers
sec/op sec/op vs base
BleveQuery 6.507 ± 0% 6.477 ± 0% -0.46% (p=0.004 n=20)
GopherLuaKNucleotide 30.39 ± 1% 30.34 ± 0% ~ (p=0.301 n=20)
Tile38IntersectsCircle100kmRequest 1.038m ± 1% 1.080m ± 2% +4.03% (p=0.000 n=20)
For #40724.
Change-Id: I0b722443f684fcb997b1d70802c5ed4b8d8f9829
Reviewed-on: https://go-review.googlesource.com/c/go/+/310184
Trust: Austin Clements <austin@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
According the armv8-a specification, the destination register of the ADDS/ADDSW/
SUBS/SUBSW instructions can not be RSP, the current implementation does not
check this and encodes this wrong instruction format as a CMN instruction. This
CL adds a check and test cases for this situation.
Change-Id: I92cc2f8e17dbda70f0dce8fddf1ca6d5d7730589
Reviewed-on: https://go-review.googlesource.com/c/go/+/309989
Reviewed-by: eric fang <eric.fang@arm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: eric fang <eric.fang@arm.com>
Run-TryBot: eric fang <eric.fang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Change-Id: I28a1910890659aaa449ffd2a847cd4ced5a8600d
Reviewed-on: https://go-review.googlesource.com/c/go/+/310211
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Add in some missing global assignment ops to the list of globals ops
that should be traversed to look for generic function instantiations.
The most common other one for global assigments (and the relevant one
for this bug) is OAS2FUNC, but also look at global assigments with
OAS2DOTTYPE, OAS2MAPR, OAS2RECV, and OASOP.
Bonus small fix: get rid of -G=3 case in ir.IsAddressable. Now that we
don't call the old typechecker from noder2, we don't need this -G-3
check anymore.
Fixes#45547.
Change-Id: I75fecec55ea0d6f62e1c2294d4d77447ed9be6ae
Reviewed-on: https://go-review.googlesource.com/c/go/+/310210
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This test expects 'go mod tidy' to fail if the existing module graph
has a bad checksum. However, there is no intrinsic reason why 'go mod
tidy' should fail in that case: the module contains no packages, and
thus no imports, so 'go mod tidy' can justifiably remove all
requirements without regard to any errors that may have already been
present in the module graph.
Adding a source file that imports a package from the module with the
bad checksum should guarantee that 'go mod tidy' reports the checksum
eror.
For #36460
Change-Id: I59734ac524031288bc03a11f58eed5abe2db76b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/309334
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
In CL 307909 we generate code that spills pointer-typed argument
registers if it is part of an SSA-able aggregate. The current
code spill the register unconditionally. Sometimes it is
unnecessary, because it is already spilled, or it is never live.
This CL reworks the spill generation. We move it to the end of
compilation, after liveness analysis, so we have information about
if a spill is necessary, and only generate spills for the
necessary ones.
Change-Id: I8d60be9b2c47651aeda14f5e2d1bbd207c134b26
Reviewed-on: https://go-review.googlesource.com/c/go/+/309331
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
The debug call tests currently assume that the target Go function is
ABI0; this is clearly no longer true when we switch to the new ABI, so
make the tests set up argument register state in the debug call handler
and copy back results returned in registers.
A small snag in calling a Go function that follows the new ABI is that
the debug call protocol depends on the AX register being set to a
specific value as it bounces in and out of the handler, but this
register is part of the new register ABI, so results end up being
clobbered. Use R12 instead.
Next, the new desugaring behavior for "go" statements means that
newosproc1 must always call a function with no frame; if it takes any
arguments, it closes over them and they're passed in the context
register. Currently when debugCallWrap creates a new goroutine, it uses
newosproc1 directly and passes a non-zero-sized frame, so that needs to
be updated. To fix this, briefly use the g's param field which is
otherwise only used for channels to pass an explicitly allocated object
containing the "closed over" variables. While we could manually do the
desugaring ourselves (we cannot do so automatically because the Go
compiler prevents heap-allocated closures in the runtime), that bakes in
more ABI details in a place that really doesn't need to care about them.
Finally, there's an old bug here where the context register was set up
in CX, so technically closure calls never worked. Oops. It was otherwise
harmless for other types of calls before, but now CX is an argument
register, so now that interferes with regular calls, too.
For #40724.
Change-Id: I652c25ed56a25741bb04c24cfb603063c099edde
Reviewed-on: https://go-review.googlesource.com/c/go/+/309169
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Alessandro Arzilli <alessandro.arzilli@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Named.SetTParams sets the type parameters for a named type.
Named.Orig returns the original generic type an instantiated
type is derived from. Added a new field orig for that purpose
and renamed the already existing orig field to fromRHS.
Finally, updated various comments.
Change-Id: Ic9d173e42740422d195713d8bdc62a54dc8c5f54
Reviewed-on: https://go-review.googlesource.com/c/go/+/309832
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Now that go/ast changes have been guarded behind the typeparams build
tag, we no longer have coverage for tests involving generic code.
Add a new testing step to cmd/dist to run go/... and cmd/gofmt tests
using -tags=typeparams.
Comment out parser object resolution assertions that currently fail, and
which will be fixed by CL 304456.
Fixes#44933
Change-Id: I481dd4246a016f410307865b6c6c2bb3c8e6e3bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/310071
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>
Fixes this failure:
go test cmd/compile/internal/ssa -run TestStmtLines -v
=== RUN TestStmtLines
stmtlines_test.go:115: Saw too many (amd64, > 1%) lines without
statement marks, total=88263, nostmt=1930
('-run TestStmtLines -v' lists failing lines)
The failure has two causes.
One is that the first-line adjuster in code generation was relocating
"first lines" to instructions that would either not have any code generated,
or would have the statment marker removed by a different believed-good heuristic.
The other was that statement boundaries were getting attached to register
values (that with the old ABI were loads from the stack, hence real instructions).
The register values disappear at code generation.
The fixes are to (1) note that certain instructions are not good choices for
"first value" and skip them, and (2) in an expandCalls post-pass, look for
register valued instructions and under appropriate conditions move their
statement marker to a compatible use.
Also updates TestStmtLines to always log the score, for easier comparison of
minor compiler changes.
Updates #40724.
Change-Id: I485573ce900e292d7c44574adb7629cdb4695c3f
Reviewed-on: https://go-review.googlesource.com/c/go/+/309649
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The compiler currently emits an "*.args_stackmap" symbol for all
bodyless functions, so that asm functions will have the proper stack
map. At the moment the code in the compiler that emits args_stackmap
assumes ABI0; to avoid misleading stackmaps, turn off args_stackmap
generation for non-ABI0 asm functions.
Updates #40724.
Change-Id: Ia5e3528d56da5fb107e799bd658e52496ba4a331
Reviewed-on: https://go-review.googlesource.com/c/go/+/309790
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Change the assembler to enforce the requirement that ABIInternal
functions need to be NOSPLIT. At the moment all of the assembly
routines in the runtime that are defined as ABIInternal also
happen to be NOSPLIT, but this CL makes it mandatory.
Updates #40724.
Change-Id: Ief80d22de1782edb44b798fcde9aab8a93548722
Reviewed-on: https://go-review.googlesource.com/c/go/+/309789
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The 'go mod tidy' hint was truncated due to a typo in CL 293689,
and that particular case was not covered by any existing test.
Updates #36460
Updates #40775
Change-Id: Ib6fa872a9dfdafc4e9a112e8add2ff5aecd2dbd0
Reviewed-on: https://go-review.googlesource.com/c/go/+/310089
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This change moves next_gc and last_next_gc into gcControllerState under
the names heapGoal and lastHeapGoal respectively. These are
fundamentally GC pacer related values, and so it makes sense for them to
live here.
Partially generated by
rf '
ex . {
memstats.next_gc -> gcController.heapGoal
memstats.last_next_gc -> gcController.lastHeapGoal
}
'
except for updates to comments and gcControllerState methods, where
they're accessed through the receiver, and trace-related renames of
NextGC -> HeapGoal, while we're here.
For #44167.
Change-Id: I1e871ad78a57b01be8d9f71bd662530c84853bed
Reviewed-on: https://go-review.googlesource.com/c/go/+/306603
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>
For OMETHEXPR, the Name in the Selection needs to be properly
linked up to the method declaration. Use the same code we
already have for ODOTMETH and OCALLPART to do that.
Fixes#45503
Change-Id: I7d6f886d606bae6faad8c104f50c177f871d41c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/309831
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Dan Scales <danscales@google.com>
For the new export/import of node types, we were just missing setting
the types of the closure variables (which have the same types as the
captured variables) and the OCLOSURE node itself (which has the same
type as the Func node).
Re-enabled inlining of functions with closures.
Change-Id: I687149b061f3ffeec3244ff02dc6e946659077a9
Reviewed-on: https://go-review.googlesource.com/c/go/+/308974
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This avoids a dependency on a *Checker when we create type parameters
outside the type checker proper, e.g. in an importer. There may be
better solutions but this does the trick for now.
Change-Id: Icf22c934970cb04c88c2729555ae6a79ef5a2245
Reviewed-on: https://go-review.googlesource.com/c/go/+/309830
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
As we are taking its address, always zero it. In many cases the
temporary will be optimized out. But in case it does not (e.g. -N,
-race), this ensures it has the right liveness information.
May fix the noopt builder.
Change-Id: I3d5d617c276d2a1a1aaebff813b4cd60bc691592
Reviewed-on: https://go-review.googlesource.com/c/go/+/309771
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>
This fixes the build crash for
GOEXPERIMENT=regabi,regabiargs GOOS=windows go build syscall
Updates #40724.
Change-Id: I4400f6ff2e83e7e7e93ad5e58c6063b327532504
Reviewed-on: https://go-review.googlesource.com/c/go/+/309110
Trust: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This CL changes our approach to guarding type parameter functionality
and API. Previously, we guarded type parameter functionality with the
parser.parseTypeParams parser mode, and were in the process of hiding
the type parameter API behind the go1.18 build constraint.
These mechanisms had several limitations:
+ Requiring the parser.parseTypeParams mode to be set meant that
existing tooling would have to opt-in to type parameters in all
places where it parses Go files.
+ The parseTypeParams mode value had to be copied in several places.
+ go1.18 is not specific to typeparams, making it difficult to set up
the builders to run typeparams tests.
This CL addresses the above limitations, and completes the task of
hiding the AST API, by switching to a new 'typeparams' build constraint
and adding a new go/internal/typeparams helper package.
The typeparams build constraint is used to conditionally compile the new
AST changes. The typeparams package provides utilities for accessing and
writing the new AST data, so that we don't have to fragment our parser
or type checker logic across build constraints. The typeparams.Enabled
const is used to guard tests that require type parameter support.
The parseTypeParams parser mode is gone, replaced by a new
typeparams.DisableParsing mode with the opposite sense. Now, type
parameters are only parsed if go/parser is compiled with the typeparams
build constraint set AND typeparams.DisableParsing not set. This new
parser mode allows opting out of type parameter parsing for tests.
How exactly to run tests on builders is left to a follow-up CL.
Updates #44933
Change-Id: I3091e42a2e5e2f23e8b2ae584f415a784b9fbd65
Reviewed-on: https://go-review.googlesource.com/c/go/+/300649
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>
Following CL 309029, this CL does the same thing for map
functions (mapaccess, mapassign, mapdelete).
For simplicity, always wrap "defer delete(m, k)". With
regabidefers enabled, this call is wrapped in a closure and the
rewriting happens automatically. Without regabidefers, it may not
be wrapped for certain key types, and then we'd need special
handling of the delete (because earlier the order pass does not
handle it). And we will turn on defer wrapping by default anyway.
Change-Id: I30663b1aa8e1d6f98e1fb81bf8c0c0ce607ab80b
Reviewed-on: https://go-review.googlesource.com/c/go/+/309510
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>
This function is no longer used.
Eliminating this actually fixes several problems:
- It made assumptions about what registers memclrNoHeapPointers would
preserve. Besides being an abstraction violation and lurking
maintenance issue, this actively became a problem for regabi because
the call to memclrNoHeapPointers now happens through an ABI wrapper,
which is generated by the compiler and hence we can't easily control
what registers it clobbers.
- The amd64 implementation (at least), does not interact with the host
ABI correctly. Notably, it doesn't save many of the registers that
are callee-save in the host ABI but caller-save in the Go ABI.
- It interacts strangely with the NOSPLIT checker because it allocates
an entire M and G on its stack. It worked around this on arm64, and
happened to do things the NOSPLIT checker couldn't track on 386 and
amd64, and happened to be *4 bytes* below the limit on arm (so any
addition to the m or g structs would cause a NOSPLIT failure). See
CL 309031 for a more complete explanation.
Fixes#45530.
Updates #40724.
Change-Id: Ic70d4d7e1c17f1d796575b3377b8529449e93576
Reviewed-on: https://go-review.googlesource.com/c/go/+/309634
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
This replaces the externalthreadhandler-based implementation of
ctrlhandler with one based on compileCallback. This is a step toward
eliminating externalthreadhandler.
For #45530.
Change-Id: I2de2f2f37777af292db67ccf8057b7566aab81f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/309632
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Change-Id: Idce4eec2a4698a94aa7b40590dffb6bf9bd45342
Reviewed-on: https://go-review.googlesource.com/c/go/+/309571
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>
Currently, Go functions exported to cgo have some confusion around
ABIs that leads to crashes. The cmd/cgo-generated C code references an
exported Go wrapper function (which calls the underlying exported user
function). The linker resolves this reference to the ABI0 entry-point
to that Go wrapper function because all host object references are
currently assumed to be to version 0 of a symbol. This gets passed via
crosscall2 and winds its way to cgocallbackg1, which puts this ABI0
entry-point into a function value and calls it. Unfortunately,
function values always use the ABIInternal calling convention, so
calling this ABI0 entry-point goes poorly.
Fix this by threading definition ABIs through the cgo export mechanism
so the linker can resolve host object references (which have no
concept of multiple ABIs) to the correct Go symbol. This involves a
few pieces:
- The compiler extends the cgo_export_{static,dynamic} directives that
get passed on to the linker with symbol definition ABIs.
- The linker parses the ABIs in the cgo_export_{static,dynamic}
directives to look up the right symbol to apply export attributes to
and put in the dynexp list.
- For internal linking, the linker's Loader structure tracks the right
symbol (in particular the right ABI) to resolve host object
references to, and we use this in all of the host object loaders.
- For external linking, we mangle only the non-ABIInternal symbols
now, so the external linker is able to resolve the correct reference
from host objects to Go symbols.
Updates #40724.
Change-Id: I70a0b1610596768c3f473745fa1a3e630afbf1a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/309341
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Currently, setCgoAttr populates the cgo_export_{static,dynamic} maps
with symbol names of exported symbols, which are then re-looked-up by
deadcode and setupdynexp, which in turn puts the re-looked-up symbols
in ctxt.dynexp. setCgoAttr already looked up the Syms, so simplify all
of this by making setCgoAttr populate ctxt.dynexp directly and
eliminating the cgo_export_{static,dynamic} maps. Recording Syms
directly also sets us up to use correct symbol versions for these
exports, rather than just assuming version 0 for all lookups.
Since setupdynexp doesn't really do any "setting up" of dynexp any
more with this change, we fold the remaining logic from setupdynexp
directly into addexport, where it has better context anyway. This also
eliminates a sorting step, since we no longer do a non-deterministic
map iteration to build the dynexp slice.
For #40724.
Change-Id: I3e1a65165268da8c2bf50d7485f2624133433260
Reviewed-on: https://go-review.googlesource.com/c/go/+/309340
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Currently, both loadcgo and setCgoAttr do some processing of
cgo_export_static and cgo_export_dynamic cgo directives, which means
they both have to parse them. There's no reason to do this in loadcgo,
so move all directive processing to setCgoAttr.
For #40724.
Change-Id: Icb3cdf7ef3517e866dd220e40a5f5dec7fd47e2b
Reviewed-on: https://go-review.googlesource.com/c/go/+/309339
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
setCgoAttr takes a lookup function, but there's only a single call and
setCgoAttr already has access to the lookup function passed at that
call. Simplify setCgoAttr by eliminating the lookup parameter and
calling the lookup function directly.
For #40724.
Change-Id: Ib27c0fa2b88c387e30423365f7757e3ba02cf7d5
Reviewed-on: https://go-review.googlesource.com/c/go/+/309338
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This took me a while to figure out. Save the next person some trouble.
Change-Id: Ifab2d426f67c21b08ef225c79125805a9008e578
Reviewed-on: https://go-review.googlesource.com/c/go/+/309336
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Both OpArgXXXReg and LoweredGetClosurePtr must come very early,
because they carry registers that are technically live on entry.
But no need to impose ordering requirement between them.
Change-Id: Iee1db6239a75e5b381e0ad25ba5503169333217b
Reviewed-on: https://go-review.googlesource.com/c/go/+/309629
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
When using the GCC thread sanitizer, it links in additional
code which uses TLS, which causes us to exceed the range of
the 16 bit TLS relocation used by statically compiled go
code.
Rewrite objabi.R_POWER_TLS_LE to handle 32b offsets when
linking internally or externally into an ELF binary. The
elf relocation translation is changed to generate a pair
of R_PPC64_TPREL16_HA/LO relocations instead of a single
R_PPC64_TPREL16.
Likewise, updating the above exposed some behavioral differences
in gnu ld which can rewrite TLS sequences. It expects the
sequence to generate a valid TLS address, not offset. This was
exposed when compiling PIC code. The proper fix is to generate
the full TLS address in the destination register of the
"MOVD tlsaddr, $Rx" pseudo-op. This removes the need to insert
special objabi.R_POWER_TLS relocations elsewhere.
Unfortunately, XCOFF (used by aix) doesn't appear to support 32
bit offsets, so we rewrite this back into a 16b relocation when
externally linking a static binary.
Fixes#45040
Change-Id: I1ee9afd0b427cd79888032aa1f60d3e265073e1d
Reviewed-on: https://go-review.googlesource.com/c/go/+/302209
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
The object representing a module directive may have a "Deprecated"
field but not a "Version" field. Other objects representing module
versions have "Path" and "Version" fields but not "Deprecated".
For #40357
Change-Id: Iad8063dfa6f7ceea22981a8a8f99e65fa3b7ffa0
Reviewed-on: https://go-review.googlesource.com/c/go/+/309337
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Before register ABI, we always pass argument in memory, and the
compiler chooses interface conversion functions solely based on
the memory layout. As long as the two types have identical memory
layout, it is fine to mix and match, e.g. convT64 takes a uint64
argument, but it can be used for things like float64 or
struct { x [4]struct{}; y int64 }.
With register ABI, those types may be passed differently, e.g.
uint64 is passed in an integer register, float64 is passed in a
floating point register, the struct above is passed in memory.
I made a few attempts in the previous CLs to try to choose the
right function based on the argument type, but none of them is
really correct.
Instead, this CL changes it to always pass the argument in the
same type the runtime expects, and do conversion before the call
in the compiler. The conversion can be no-op (e.g. a named type
to its underlying type), direct (e.g. int64 to uint64), or
through memory (e.g. *(*uint64)(unsafe.Pointer(&arg))). This way,
the front end does not need to know the ABI. (It only needs to
know how to convert types, and it already does.)
TODO: do something similar for map functions.
Change-Id: I33fc780a47c3f332b765e09b5e527f52ea1d6b5c
Reviewed-on: https://go-review.googlesource.com/c/go/+/309029
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
This test is not run in short mode so it was getting
failures that didn't happen with default testing. See
the issue for details on the failures.
Fixes#45406
Change-Id: I51d97cc4c910fe3ba2bc0a12742023a57d101f44
Reviewed-on: https://go-review.googlesource.com/c/go/+/308935
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Paul Murphy <murp@ibm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
For function results, if in register, we allocate spill slots
within the frame like locals. Currently, even if we never spill
to it the slot is still allocated. This CL makes it not allocate
the slot if it is never used.
Change-Id: Idbd4e3096cfac6d2bdfb501d8efde48ee2191d7b
Reviewed-on: https://go-review.googlesource.com/c/go/+/309150
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
If we are assigning a global address to an object that is
immediately returned from runtime.newobject, we omit the write
barrier because we know that both the source (static address) and
the destination (zeroed memory) do not need to be tracked by the
GC. Currently, the code that matches runtime.newobject's result
is specific to ABI0 layout. Update the code to work with register
ABI as well.
Change-Id: I7ab0833c6f745329271881ee4169956928a3a948
Reviewed-on: https://go-review.googlesource.com/c/go/+/308709
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
If v is a Copy of x, we will rewrite v to x. If v has a name
associated to it, let the name associate to x.
Under register ABI, this helps associate in-register Arg values
to the parameters' names. (But does not address all cases.)
Change-Id: I47c779e56c9d0823a88890497e32326bc0290f82
Reviewed-on: https://go-review.googlesource.com/c/go/+/309330
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
The rule that inlines memmove expects SSA ops that calls memmove
with arguments in memory. This CL adds a version that matches
it with arguments in registers, so the optimization works for
both situations.
Change-Id: Ideb64f65b7521481ab2ca7c9975a6cf7b70d5966
Reviewed-on: https://go-review.googlesource.com/c/go/+/309332
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: David Chase <drchase@google.com>
Previously when the module cache specified by GOMODCACHE could not be
created an unhelpful message would be printed multiple times.
This happened because we were fetching several things in parallel then
failing to write them because we can't create the module cache.
We now check if the module cache can be created before fetching.
If not, the following message is printed:
go: could not create module cache
Fixes#45113
Change-Id: Ic9cec787411335edc7f4d0614fde7eaa8a957fb5
Reviewed-on: https://go-review.googlesource.com/c/go/+/304571
Trust: Julie Qiu <julie@golang.org>
Run-TryBot: Julie Qiu <julie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Austin Clements
Paul E. Murphy
Aofei Sheng
Robert Griesemer
eric fang
Keith Randall
Dan Scales
Bryan C. Mills
Cherry Zhang
Michael Anthony Knyszek
Rob Findley
David Chase
Than McIntosh
Ian Lance Taylor
Jay Conrod
Lynn Boger
Julie Qiu