The code that created DWARF debug var locations for input parameters
in the non-optimized case for regabi was not doing the right thing for
degenerate functions with infinite loops. Detect these cases and don't
try to emit the normal location data.
Fixes#45948.
Change-Id: I2717fc4bac2e03d5d850a6ec8a09ed05fed0c896
Reviewed-on: https://go-review.googlesource.com/c/go/+/316752
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
If the go command is executed on Linux in a deleted directory,
it fails. This behavior is reasonable for commands which depend on
the CWD, but it's unexpected for commands like `go version`.
This change delays initialization of a global CWD variable.
Fixed#34499
Change-Id: I7302fb84a3b7f5f149a123d277abd5b9b5bc95b2
Reviewed-on: https://go-review.googlesource.com/c/go/+/268261
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
I missed the 'go mod tidy' step in CL 316751 because I forgot to run
the cmd/internal/moddeps test in long mode. 😞
Updates #45932
Change-Id: Ic3f9b303ad5798ecd8cb044d4b8c766aa820bf69
Reviewed-on: https://go-review.googlesource.com/c/go/+/317129
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>
Fixes#45447
Change-Id: I1b1a0a844ee4345ced1a007bbe53db035183175f
Reviewed-on: https://go-review.googlesource.com/c/go/+/311529
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Updates #44933.
Change-Id: I0c4c2a54f67b47771f4fa59f11c47fa7b0dde799
Reviewed-on: https://go-review.googlesource.com/c/go/+/317029
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
In a lazy module, it is important that tidyRoots does not add any new
roots because the dependencies of non-roots are pruned out.
In an eager module, that property is not important (and does not hold
in general) because no dependencies are ever pruned out.
Fixes#45952
Change-Id: I5c95b5696b7112b9219e38af04e0dece7fb6e202
Reviewed-on: https://go-review.googlesource.com/c/go/+/316754
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>
For #45952
Change-Id: I90e895e2fd10bccd947f9ee5133f942fea218a07
Reviewed-on: https://go-review.googlesource.com/c/go/+/316753
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>
Currently if a signal lands on a non-Go thread that's handled by the Go
handler, Go will emit a message. However, unlike everywhere else in the
runtime, Go will not abort the process after, and the signal handler
will try to continue executing.
This leads to cascading failures and possibly even memory corruption.
For #45638.
Change-Id: I546f4e82f339d555bed295528d819ac883b92bc6
Reviewed-on: https://go-review.googlesource.com/c/go/+/316809
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
For #44513.
For #23011.
Change-Id: Ic092e38da3601a43d7e2110f500db4a6a6f845f5
Reviewed-on: https://go-review.googlesource.com/c/go/+/316889
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
When the expand_calls phase in the SSA backend lowers prolog OpArg
values into OpArgIntReg/OpArgFloatReg values, we don't always record
the assocation between the new lowered value and the parameter name.
This patch handles the simple case where a given parameter fits into
exactly one register; in this scenario it makes sense to manufacture a
new pseudo-slot for the value that points to the param, and install
the slot/value mapping in the NamedValues table for the function. More
work will be needed to deal with params that span multiple registers;
that will need to be addressed in a subsequent patch.
This change improves the parameter error rate "optargorder" benchmark
by about 7-8% (when run on the optargorder binary).
Updates #45945.
Change-Id: Ic9adbe20b6f91145d49651348818f0f5cba92b18
Reviewed-on: https://go-review.googlesource.com/c/go/+/316890
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This test deletes the running executable file, which is not safe
on Plan 9. The test was working by accident prior to commit 02ab8d1,
which must have changed the page reference ordering just enough to
cause a new demand page-in after deletion of the file.
Fixes#45941
Change-Id: Ic13d8032c21cee603e3afc3c5c4da6093fc37bf4
Reviewed-on: https://go-review.googlesource.com/c/go/+/316829
Reviewed-by: David du Colombier <0intro@gmail.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Trust: David du Colombier <0intro@gmail.com>
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
All build environment validation sets Error except for the
GOEXPERIMENT parser, which panics. Change it to also set Error so that
a bad GOEXPERIMENT doesn't cause everything that imports
internal/buildcfg to panic on init.
Change-Id: Ie9a506ef0978ecb410f2dcd784638f2167354175
Reviewed-on: https://go-review.googlesource.com/c/go/+/310970
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
TestSignalTrace can take a bit longer to run on some
ppc64{,le} machines. I was only able to reproduce the
timeout reliably on a POWER8/ppc64le ubuntu 16.04 host.
Bump the timeout to 5 seconds. This should be more than
sufficient for a test which occasionally takes a bit
longer to run on these builders.
Fixes#45773
Change-Id: I4177bb986561f714aabfa5b0ca44b1c90b1cd94f
Reviewed-on: https://go-review.googlesource.com/c/go/+/315049
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
If we're testing through dist, we're testing the implementation of Go,
so we're interested in any package failing with potential runtime
issues. In these cases, we'd like to have as much relevant detail as
possible, but currently runtime stack frames and goroutines are
suppressed due to the default GOTRACEBACK setting.
So, try to set GOTRACEBACK to system if it's unset. Check if it's unset
first so we don't override the user asking for a lower or higher level.
This change was brought up in the context of #45916, since there's an
apparent deadlock (or something!) in the runtime that appears when
running other code, but it's difficult to see exactly where it's
blocked. However, this change is very generally useful.
This change also runs scripted tests with GOTRACEBACK=system, upgrading
from GOTRACEBACK=all. Often, script tests can trigger failures deep in
the runtime in interesting ways because they start many individual Go
processes, so being able to identify points of interest in the runtime
is quite useful.
For #45916.
Change-Id: I3d50658d0d0090fb4c9182b87200d266c7f8f915
Reviewed-on: https://go-review.googlesource.com/c/go/+/316469
Trust: Michael Knyszek <mknyszek@google.com>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Since x/tools is now lazy, this removes a significant fraction of
otherwise-irrelevant dependencies from the go.sum file.
The remaining extraneous go.sum lines come from the dependency on
github.com/google/pprof. Since that module is outside of the Go
project proper, I do not plan to submit a PR to make it lazy until
after the Go 1.17 release.
For #36460
Updates #36905
Change-Id: I214492cf931fca797817124ecdcbccd4ebb7505b
Reviewed-on: https://go-review.googlesource.com/c/go/+/316452
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
The outdated comment in modfile.go was missed in CL 315409.
Upon a closer look at the test case in mod_go_version_vendor.txt, it
is almost completely redundant with the new test in
mod_vendor_goversion.txt. Make it completely redundant and remove it.
Updates #36876
Change-Id: Ibcd1f6b426460aaafbd6dc0be93078547904572b
Reviewed-on: https://go-review.googlesource.com/c/go/+/316209
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>
Because x/crypto is now lazy, this removes the remaining checksums for
older-than-selected dependencies from src/go.sum.
It also removes a significant fraction of the irrelevant checksums
from src/cmd/go.sum.
For #36460
Updates #36905
Change-Id: I33af5fc638aa1d1c66df3a1d86542912e95a7f50
Reviewed-on: https://go-review.googlesource.com/c/go/+/316451
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
Because x/text is now lazy, the go.sum file no longer needs a checksum
for the go.mod file for the outdated x/tools required by x/text.
For #36460
Updates #36905
Change-Id: Id7395e61909af3889c1615dc33139e5bb45504c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/316490
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
Even though x/mod is now lazy, this has no immediate effect on the
size of cmd/go.sum: all of the existing dependencies are still pulled
in via the dependency on x/tools, which is itself not yet lazy (that's
CL 315570).
For #36460
Updates #36905
Change-Id: I7bce5fe2596a2d71e4df08f5d5f4cb8dcdb8512c
Reviewed-on: https://go-review.googlesource.com/c/go/+/316489
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
We were already setting GIT_SSH_COMMAND (if unset) to explicitly
include 'ControlMaster=no' in order to disable connection pooling.
Now we also set 'BatchMode=yes' to suppress password prompts for
password-protected keys.
While we're here, we also set GCM_INTERACTIVE=never to suppress
similar prompts from the Git Credential Manager for Windows.
Fixes#44904
Change-Id: Iebb050079ff7dd54d5b944c459ae212e9e6f2579
Reviewed-on: https://go-review.googlesource.com/c/go/+/300157
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>
Lots of constant SSA values we put in the entry block so that
CSE can easily combine them. With -N, however, we don't run CSE, so
putting values in the entry block only serves to extend their lifetime
for no benefit.
Fixes#45897. The number of live SSA values per block goes from >5K to 22.
Memory use goes from ~3GB to ~400MB.
Change-Id: I620b423611790a900e0d4cd270eac5dbdddf2a2b
Reviewed-on: https://go-review.googlesource.com/c/go/+/316369
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
This is part of getting debugging into good shape
with the register ABI. (This may generate a backport
for 1.16, there was some regression there as well.)
This is not necessarily fully-baked yet; my goal is to
make it work "well enough" for actual debugging, then
revisit the metrics, which are currently ignorant
of registers used for passing parameters (currently,
rejects them as a valid option).
Updates #40724.
Change-Id: Ib649adf39f947b7b54895c5bf181cf48ca4d38a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/311689
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>
Follow CL 23967 and CL 24021 which did the same on linux and freebsd,
respectively.
Updates #13987
Updates #16028
Change-Id: I95b13d8ddde4cea1ef4fb7d655f1ad1a219d13aa
Reviewed-on: https://go-review.googlesource.com/c/go/+/315281
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
QuotedPrefix is similar to Unquote, but returns the quoted string verbatim
and ignores any data after the quoted string.
Fixes#45033
Change-Id: I9f69fe9e3e45cbe9e63581cf1b457facb625045d
Reviewed-on: https://go-review.googlesource.com/c/go/+/314775
Trust: Joe Tsai <joetsai@digital-static.net>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
The functions SwapPointer and CompareAndSwapPointer can be used to
interact with unsafe.Pointer, however generally it is prefered to work
with Value, due to its safer interface. As such, they have been added
along with glue logic to maintain invariants Value guarantees.
To meet these guarantees, the current implementation duplicates much of
the Store function. Some of this is due to inexperience with concurrency
and desire for correctness, but the lack of generic programming
functionality does not help.
Fixes#39351
Change-Id: I1aa394b1e70944736ac1e19de49fe861e1e46fba
Reviewed-on: https://go-review.googlesource.com/c/go/+/241678
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This adds a new lock protecting "tmpl".
This is a copy of https://golang.org/cl/257817 by Andreas Fleig,
updated for current tip, and updated to start running the
html/template TestEscapeRace test.
Thanks to @bep for providing the test case.
Fixes#39807
Change-Id: Ic8874484290283a49116812eeaffb8608346dc70
Reviewed-on: https://go-review.googlesource.com/c/go/+/316669
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Following CL 313230, this is for internal/syscall/unix package.
Updates #45702.
Change-Id: Ie6d8c1923dfeae56896212393c5c2a6e257648d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/316649
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Since we have int8 to int64 min max and uint8 to uint64 max constants,
we should probably have some for the word size types too. This change
also adds tests to validate the correctness of all integer limit
values.
Fixes#28538
Change-Id: Idd25782e98d16c2abedf39959b7b66e9c4c0c98b
Reviewed-on: https://go-review.googlesource.com/c/go/+/247058
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Robert Griesemer <gri@golang.org>
These new methods provide support for cases where performance is a
primary concern. For example, copying files from an existing zip to a
new zip without incurring the decompression and compression overhead.
Using an optimized, external compression method and writing the output
to a zip archive. And compressing file contents in parallel and then
sequentially writing the compressed bytes to a zip archive.
TestWriterCopy is copied verbatim from https://github.com/rsc/zipmergeFixes#34974
Change-Id: Iade5bc245ba34cdbb86364bf59f79f38bb9e2eb6
Reviewed-on: https://go-review.googlesource.com/c/go/+/312310
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Carlos Amedee <carlos@golang.org>
At this time, the golang.org/s/release process arranges such that the
api/go1.n.txt file is created when a Go 1.N Beta 1 release is being cut.
The API check is currently configured so that tests don't fail visibly
even if api/go1.n.txt becomes a subset of the actual API additions in
the upcoming Go 1.N release as long as 'go version' has "devel" in it.
The first time that 'go version' output drops the "devel" substring
during testing is after the release-branch.go1.N branch is created
as part of the process to cut a Go 1.N Release Candidate 1 release.
The month or so between Beta 1 and RC 1 is well into the freeze and
deliberate API changes are rare and very intentional. There seems to
be agreement that it's healthy to make the API check stricter during
that time period. Doing so will ensure that api/go1.n.txt cannot get
stale after creation without anyone noticing, and may catch CLs that
don't have the intended diff on the API.
This CL changes behavior to be simple and clear: from the moment
an api/go1.n.txt file corresponding to the current Go version in
development is added to the tree, silent API additions stop being
permitted.
This CL also moves the magical "override the value of -allow_new flag
if runtime.Version() contains 'devel' string" behavior from cmd/api
command to the run.go script that calls it, making the CLI of cmd/api
itself less surprising.
Fixes#43956.
Change-Id: I89468207573f7ccdbc9f12625dcdd3ef2bcf8f10
Reviewed-on: https://go-review.googlesource.com/c/go/+/315350
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
As a side effect, this also upgrades x/sys to the version currently
required by the latest x/net.
Because x/net is now lazy, it no longer requires checksums for
older-than-selected versions of x/sys, x/term, and x/text.
For #36460
Updates #36905
Change-Id: I242815e202aa7d482fc3983a6717bece10ea8111
Reviewed-on: https://go-review.googlesource.com/c/go/+/316251
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Even though x/term is now lazy, this has no overall effect (yet) on
the contents of cmd/go.sum, because the dependency that would be
pruned out (an old version of x/sys) is still transitively required
through x/crypto, x/sys, and/or x/tools.
Once those modules are also lazy (CL 316109, CL 316111, and CL 315570
respectively), the extra go.sum entries for x/sys will drop out.
For #36460
Updates #36905
Change-Id: I79e715328f7c417ea20ae8fe4f8e0e3eb71ee6c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/316250
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
In the event allocSpan returned a nil, this would crash.
Cleaned up the code and comments slightly, too.
Change-Id: I6231d4b4c14218e6956b4a97a205adc3206f59ec
Reviewed-on: https://go-review.googlesource.com/c/go/+/316429
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
CL 312214 added unsafe.{Add,Slice}, which may appears in expression that
evaluating requires function calls. "mayCall" does not handle that
case, causing linux-amd64-noopt builder failed.
Fixes#45917
Change-Id: I900aefb702122480be621355def3d2c20eadbe70
Reviewed-on: https://go-review.googlesource.com/c/go/+/316170
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: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Assignment between input parameters causes them to have more than
one "Name", and running this backwards from names to values can end
up confusing (conflating) parameter spill slots.
Around 105a6e9518, this cases a stack overflow running
go test -race encoding/pem
because two slice parameters spill (incorrectly) into the same
stack slots (in the AB?I-defined parameter spill area).
This also tickles a failure in cue, which turned out to be
easier to isolate.
Fixes#45851.
Updates #40724.
Change-Id: I39c56815bd6abb652f1ccbe83c47f4f373a125c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/313212
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>
If the cleaned path did not match the requested path, ServeMux.Handler
would return a Location header which reflected the hostname in the
request, possibly leading to an incorrect redirect. Instead the
Location header should be relative, like the other cases in
ServeMux.Handler.
Change-Id: I2c220d925e708061bc128f0bdc96cca7a32764d3
Reviewed-on: https://go-review.googlesource.com/c/go/+/313950
Trust: Roland Shoemaker <roland@golang.org>
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
When regabi is used sorting by stack offset will not preserve the order
of function arguments. Trust that variables are already ordered
correctly when creating debug_info entries.
Fixes#45720
Change-Id: I1dbdd185975273f70244a23302d34f082347603d
Reviewed-on: https://go-review.googlesource.com/c/go/+/315280
Reviewed-by: Than McIntosh <thanm@google.com>
Trust: Jeremy Faller <jeremy@golang.org>
Fix up a slightly stale comment in the part of ssa generation that
zeros ambiguously live variables: with the advent of the register ABI,
the ir.Func "Dcl" slice is no longer entirely sorted by frame offset,
although this is still the case for the local vars in Dcl.
Change-Id: I633f43d16f0d4e0b444193a6edb6b2aa1154eea7
Reviewed-on: https://go-review.googlesource.com/c/go/+/316309
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>
This edge can happen when forcegchelper() calls
goparkunlock(&forcegc.lock, ...) while holding the forcegc lock.
goparkunlock() eventually calls park_m(). In park_m(), traceGoPark()
(which leads to (*traceStackTable).put() and acquires the traceStackTab
lock) can be called before the forcegc lock is released.
Fixes#45774
Change-Id: If0fceab596712eb9ec0b9b47326778bc0ff80913
Reviewed-on: https://go-review.googlesource.com/c/go/+/316029
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Trust: Carlos Amedee <carlos@golang.org>
Currently we have two code paths of writing the text segment. They
are semantically the same:
- if we split text sections, we write all ".text" sections as
text and the the rest as data.
- if we do not split text sections, we write the first section
as text and the rest as data. The first section is named ".text"
and is the only one in this case.
Unify the code.
Change-Id: Ic639eed625615be3c8a8d41f5b47e901552f587a
Reviewed-on: https://go-review.googlesource.com/c/go/+/316049
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
For ABI0 assembly functions that have Go declarations, generate
traceback argument info and attach it to the assembly functions.
So we can print argument in tracebacks if e.g. assembly function
panics.
Only do this for ABI0 functions, as for ABIInternal assembly
functions it is likely that they never spill arguments to memory.
Change-Id: I7e601ccd9aded5e6af2f02be975bf81ff9948f4d
Reviewed-on: https://go-review.googlesource.com/c/go/+/315870
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>
Currently, when "..." argument is passed to non-variadic function, the
compiler may skip that check, but continue checking whether the number
of arguments matches the function signature.
That causes the sanity check which was added in CL 255241 trigger.
Instead, we should report an invalid use of "...", which matches the
behavior of new type checker and go/types.
Fixes#45913
Change-Id: Icbb254052cbcd756bbd41f966c2c8e316c44420f
Reviewed-on: https://go-review.googlesource.com/c/go/+/315796
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>
When creating programs with large text sections on ppc64le,
trampolines are needed for calls that are too far; however
they are not created if the code is generated such that the TOC
register r2 is initialized and maintained in the code because
then the external linker can create the trampolines. Previously
the function DynlinkingGo was used to determine this but in the
case where plugins are used, this could return true even though
r2 is not valid.
To fix this problem I've added a new function r2Valid which returns
true when the build options indicate that the r2 is
initialized and maintained. Because of the ways that
DynlinkingGo is used I wanted to maintain its previous
behavior.
Fixes#45850
Change-Id: I6d902eba6ad41757aa6474948b79acdbd479cb38
Reviewed-on: https://go-review.googlesource.com/c/go/+/315289
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
