Originally, overloading -d=inlfuncswithclosures=0 to enable quirks
mode was convenient because toolstash -cmp doesn't provide a way to
pass different gcflags to the installed vs stashed toolchains. Prior
to unified IR being merged, the stashed toolchain wouldn't know about
or accept any unified-specific flags.
However, this concern is no longer applicable since unified IR has
been merged, and the TestUnifiedCompare test can easily specify
different flag sets for the baseline and experiment build configs.
This CL adds a new -d=unifiedquirks flag to enable quirks mode, so
that it's possible to test unified IR with -d=inlfuncswithclosures=0
without also affecting a bunch of other compilation details.
Change-Id: Id1932f332822622aa8617278e82ec6d1a53b1b46
Reviewed-on: https://go-review.googlesource.com/c/go/+/329733
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This patch reinstates a fix for PowerPC with regard to making VDSO calls
while receiving a signal, and subsequently crashing. The crash happens
because certain VDSO calls can modify the r30 register, which is where g
is stored. This change was reverted for PowerPC because r30 is supposed
to be a non-volatile register. This is true, but that only makes a
guarantee across function calls, but not "within" a function call. This
patch was seemingly fine before because the Linux kernel still had hand
rolled assembly VDSO function calls, however with a recent change to C
function calls it seems the compiler used can generate instructions
which temporarily clobber r30. This means that when we receive a signal
during one of these calls the value of r30 will not be the g as the
runtime expects, causing a segfault.
You can see from this assembly dump how the register is clobbered during
the call:
(the following is from a 5.13rc2 kernel)
```
Dump of assembler code for function __cvdso_clock_gettime_data:
0x00007ffff7ff0700 <+0>: cmplwi r4,15
0x00007ffff7ff0704 <+4>: bgt 0x7ffff7ff07f0 <__cvdso_clock_gettime_data+240>
0x00007ffff7ff0708 <+8>: li r9,1
0x00007ffff7ff070c <+12>: slw r9,r9,r4
0x00007ffff7ff0710 <+16>: andi. r10,r9,2179
0x00007ffff7ff0714 <+20>: beq 0x7ffff7ff0810 <__cvdso_clock_gettime_data+272>
0x00007ffff7ff0718 <+24>: rldicr r10,r4,4,59
0x00007ffff7ff071c <+28>: lis r9,32767
0x00007ffff7ff0720 <+32>: std r30,-16(r1)
0x00007ffff7ff0724 <+36>: std r31,-8(r1)
0x00007ffff7ff0728 <+40>: add r6,r3,r10
0x00007ffff7ff072c <+44>: ori r4,r9,65535
0x00007ffff7ff0730 <+48>: lwz r8,0(r3)
0x00007ffff7ff0734 <+52>: andi. r9,r8,1
0x00007ffff7ff0738 <+56>: bne 0x7ffff7ff07d0 <__cvdso_clock_gettime_data+208>
0x00007ffff7ff073c <+60>: lwsync
0x00007ffff7ff0740 <+64>: mftb r30 <---- RIGHT HERE
=> 0x00007ffff7ff0744 <+68>: ld r12,40(r6)
```
What I believe is happening is that the kernel changed the PowerPC VDSO
calls to use standard C calls instead of using hand rolled assembly. The
hand rolled assembly calls never touched r30, so this change was safe to
roll back. That does not seem to be the case anymore as on the 5.13rc2
kernel the compiler *is* generating assembly which modifies r30, making
this change again unsafe and causing a crash when the program receives a
signal during these calls (which will happen often due to async
preempt). This change happened here:
https://lwn.net/ml/linux-kernel/235e5571959cfa89ced081d7e838ed5ff38447d2.1601365870.git.christophe.leroy@csgroup.eu/.
I realize this was reverted due to unexplained hangs in PowerPC
builders, but I think we should reinstate this change and investigate
those issues separately:
f4ca3c1e0aFixes#46803
Change-Id: Ib18d7bbfc80a1a9cb558f0098878d41081324b52
GitHub-Last-Rev: c3002bcfca
GitHub-Pull-Request: golang/go#46767
Reviewed-on: https://go-review.googlesource.com/c/go/+/328110
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Apparently, TestMorestack is still flaky on darwin/arm64 builder
after CL 307730. Let it spend more time in copying the stack.
With this CL, on my Apple M1 machine it passes reliably in short
mode for 1000 runs, and reliably gets 250+ samples in the 5-second
interval in long mode.
May fix#46755.
Change-Id: I07b36c1cf63ad35f7820e1f8e837e29376a37b2a
Reviewed-on: https://go-review.googlesource.com/c/go/+/329869
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Documents the mode added in CL 306149 to skip object resolution.
Fixes#46298
Change-Id: I6a14aaa00790f9f7e4e4ba17033355f5e878d74b
Reviewed-on: https://go-review.googlesource.com/c/go/+/329009
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>
CL 280634 remove Sym.Importdef, so ipkg in importsym is not used
anymore. So we can remove it from importsym and all other import*
functions, which just call importsym internally.
Change-Id: I15b9d11c4445dbe40982f7ff2a33a2116705e790
Reviewed-on: https://go-review.googlesource.com/c/go/+/329573
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>
So making it less verbose and clearer to the reader what that check means.
Change-Id: I41587aab399e63600356c5cecec64978048bed36
Reviewed-on: https://go-review.googlesource.com/c/go/+/329571
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>
We've observed some occasional os-arch specific timeouts
in signal.TestSignalTrace(). While the main purpose of a
short timeout is to ensure the passing tests complete
quickly, the unexpected failure path can tolerate waiting
longer (the test is not intended to test how slow or
overloaded the OS is at the time it is run).
Fixes#46736
Change-Id: Ib392fc6ce485a919612784ca88ed76c30f4898e2
Reviewed-on: https://go-review.googlesource.com/c/go/+/329502
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: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
The new RGBA64At method is equivalent to the existing At method (and the
new SetRGBA64 method is equivalent to the existing Set method in the
image/draw package), but they can avoid allocations from converting
concrete color types to the color.Color interface type.
Also update api/go1.17.txt and doc/go1.17.html
Fixes#44808
Change-Id: I8671f3144512b1200fa373840ed6729a5d61bc35
Reviewed-on: https://go-review.googlesource.com/c/go/+/311129
Trust: Nigel Tao <nigeltao@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
This CL adds a longtest test to make sure -d=unified=1 produces output
identical to -d=unified=0.
Change-Id: I2c5d38f67dbc8fecd8332a91ba7cae22225b090c
Reviewed-on: https://go-review.googlesource.com/c/go/+/329429
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
I wrote code that relied on this API, but I misunderstood the original
description of the "more" result. As a consequence, my code always
stopped one frame early.
This CL expands the documentation to be more explicit and specifically
call out my confusion (i.e., that the "more" result indicates whether
the *next* Next call will return a valid Frame, and not whether this
call did).
Change-Id: If135f8f8c05425073d45377c4179e4f79e6bd6ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/329389
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Otherwise, in c-archive or c-shared mode, there is the chance of
getting a SIGPROF just after the signal handler is removed but before
profiling is disabled, in which case the program will die.
Fixes#46498
Change-Id: I5492beef45fec9fb9a7f58724356d6aedaf799ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/329290
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Change-Id: I876933370a6bcb6586eda9d8fc28a081bf31b1cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/328511
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
While at it, also rename "useUnifiedIR" to "unified", to be consistent
with "-d=unified" and "GOEXPERIMENT=unified".
Change-Id: I48ffdb4b36368343893b74f174608f5f59278249
Reviewed-on: https://go-review.googlesource.com/c/go/+/328989
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>
This CL extends the unified export data format's existing sync
mechanism to save writer stacks, controlled by the -d=syncframes debug
flag. This allows readers to provide more details when reporting
desync errors, which should simplify development of the data format
and the various reader/writer implementations.
For example, CL 328051 updated reader and writer, but missed making a
similar change to the linker (fix in CL 328054). Re-reviewing the CL
in isolation after the failure, it was not immediately obvious what
was going wrong. But the pair of stack traces below identifies exactly
what happened: it should have updated linker.relocFuncExt to write out
the new sync marker too.
```
data sync error: package "internal/abi", section 6, index 4, offset 536
found UseReloc, written at:
/home/mdempsky/wd/go/src/cmd/compile/internal/noder/encoder.go:221: (*encoder).reloc +0x44
/home/mdempsky/wd/go/src/cmd/compile/internal/noder/linker.go:214: (*linker).relocFuncExt +0x580
/home/mdempsky/wd/go/src/cmd/compile/internal/noder/linker.go:233: (*linker).relocTypeExt +0x234
/home/mdempsky/wd/go/src/cmd/compile/internal/noder/linker.go:161: (*linker).relocObj +0x2198
/home/mdempsky/wd/go/src/cmd/compile/internal/noder/linker.go:64: (*linker).relocIdx +0x196
expected ImplicitTypes, reading at:
/home/mdempsky/wd/go/src/cmd/compile/internal/noder/reader.go:796: (*reader).implicitTypes +0x36
/home/mdempsky/wd/go/src/cmd/compile/internal/noder/reader.go:810: (*reader).addBody +0x81
/home/mdempsky/wd/go/src/cmd/compile/internal/noder/reader.go:727: (*reader).funcExt +0x542
/home/mdempsky/wd/go/src/cmd/compile/internal/noder/reader.go:651: (*reader).method +0x324
/home/mdempsky/wd/go/src/cmd/compile/internal/noder/reader.go:557: (*pkgReader).objIdx +0x2704
```
Change-Id: I911193edd2a965f81b7459f15fb613a773584685
Reviewed-on: https://go-review.googlesource.com/c/go/+/328909
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
CL 328336 introduced two new packages that the runtime and other
low-level packages depend on. Include them as targets to copy in this
test with other such packages.
Fixes the dev.typeparams longtest builders.
Change-Id: Ia886f0264962a68acd06ebca002eef8515f06487
Reviewed-on: https://go-review.googlesource.com/c/go/+/329251
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This is port of CL 328053 for types2 to go/type.
The change is identical, but for some tweaks to the error positions in
tests.
Updates #46749
Change-Id: I8d34c5b1669e59e4ec7d91f81dcf655b2bfd89a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/328869
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Left a couple of tests with old notation so that we keep testing it
while the notation is still supported.
Change-Id: Ia6a3e7911af87eaccc7b06189c10f79789575a98
Reviewed-on: https://go-review.googlesource.com/c/go/+/328256
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Unified includes a check to make sure that types2 memory has been
garbage collected, but it relies on precise finalization, which we
provide (for dynamically allocated objects, at least) but isn't
guaranteed by the Go spec. In particular, Go 1.4 doesn't provide this.
The check is strictly unnecessary and only exists to make sure we
don't regress and start holding onto types2 memory accidentally. So
just disable the check during bootstrap builds.
Change-Id: Ie54fe53b2edba02c0b0b1e5ae39d81be8a0ace8d
Reviewed-on: https://go-review.googlesource.com/c/go/+/329269
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
runtime/pprof has a more complete list of platforms with broken
profiling than I used in cmd/pprof in https://golang.org/cl/325809.
Duplicate that list in cmd/pprof and clean it up a bit in runtime/pprof
for easier reference.
Change-Id: I8f2580aac223de9b73cfff4355f49916f7b76493
Reviewed-on: https://go-review.googlesource.com/c/go/+/329149
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Currently, callMethod has some ABI translation code that is not agnostic
of endianness. This change rectifies that by adding a method to
internal/abi.RegArgs for safely returning an offset into a register slot
that's endianness-dependent.
No tests for this because it's just best-effort. There's no actual way
to test this because we don't support a register ABI on any big endian
architectures yet.
Change-Id: Ic68d9ee1bfdea0fc2992d467d749e2b083e92de3
Reviewed-on: https://go-review.googlesource.com/c/go/+/328348
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Change-Id: Ia0da5e5d1e8d20327690cb53c9df067401f3428c
Reviewed-on: https://go-review.googlesource.com/c/go/+/328812
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Change-Id: I522263eb5112b78639340b83d92e80a13f738bd4
Reviewed-on: https://go-review.googlesource.com/c/go/+/328811
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Change-Id: Ibc8381662242c6754f34edce9c0ad81681f55940
Reviewed-on: https://go-review.googlesource.com/c/go/+/329192
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Lots of constants in these packages start with Goarch and Goos, which is
redundant. Instead, add the "Is" prefix to make the constant clearer,
and to differentiate from the arch family constants.
Change-Id: Id92c1d3e911296a72949f8c9d649f142e7dc9d17
Reviewed-on: https://go-review.googlesource.com/c/go/+/328343
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Change-Id: I1209904326b1563e12d9c7d19a12a10c72d1dbcb
Reviewed-on: https://go-review.googlesource.com/c/go/+/329191
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
I left a TODO to decide whether to add 'go get' arguments as indirect
(as we have in the past), or to make them direct. I considered both
options, and decided to keep the indirect default because it is easier
(and less invasive) for users to fix.
Updates #45979
Change-Id: I1f23a88db59a01bdd9e6fe48c2fffc8a3b55145a
Reviewed-on: https://go-review.googlesource.com/c/go/+/328971
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>
Change-Id: I01e079b95f71b01edaf049d49a0993a7ed39c7bf
Reviewed-on: https://go-review.googlesource.com/c/go/+/328810
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This change extracts the GOOS and GOARCH specific constants from
runtime/internal/sys into packages that are available to the entire
standard library.
This change does not yet update the runtime and associated packages to
use them, and instead adds constants to runtime/internal/sys to forward
the constants defined by these new packages.
Change-Id: I14d574b8d7bfe599ad25da29dc1b39716e35a734
Reviewed-on: https://go-review.googlesource.com/c/go/+/328336
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
https://golang.org/cl/318049 replaced driver.ObjFile.Base with
driver.ObjFile.ObjAddr. We don't support shared libraries, so these
should be no-op, but CL 318049 accidentally failed to account from the
change in no-op behavior from returning 0 to passing through addr.
Fixes#46636
Change-Id: Iab82224c7db722a1e257ec6e305218e22114d0a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/325809
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Setting `-gcflags=all=-d=unified` works for normal builds/tests, but
seems to have trouble with the test/run.go regress tests. So add a
GOEXPERIMENT knob to allow another way to turn on unified IR
construction, which plays better with all.bash.
While here, update two existing test expectations that currently fail
during GOEXPERIMENT=unified ./all.bash:
1. misc/cgo/errors/testdata/err2.go is testing column positions, and
types2 gets one case slightly better, and another case slightly
worse. For now, the test case is updated to accept both.
2. fixedbugs/issue42284.go is added to the list of known failures,
because it fails for unified IR. (It's an escape analysis test, and
escape analysis is working as expected; but unified is formatting an
imported constant value differently than the test's regexp expects.)
Updates #46786.
Change-Id: I40a4a70fa1b85ac87fcc85a43687f5d81e011ec0
Reviewed-on: https://go-review.googlesource.com/c/go/+/328215
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Only use safe characters of the test name for the os.MkdirTemp pattern.
This currently includes the alphanumeric characters and ASCII
punctuation characters known not to interact with globs.
Fixes#46624
Change-Id: I402c34775b943fed9b97963c52f79245cc16dc1d
Reviewed-on: https://go-review.googlesource.com/c/go/+/326010
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
