Fixes#70175
Change-Id: I13767d951455854b03ad6707ff9292cfe9097ee9
Reviewed-on: https://go-review.googlesource.com/c/go/+/624377
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
Change the description of an operand x that has a named type of sorts
by providing a description of the type structure (array, struct, slice,
pointer, etc).
For instance, given a (variable) operand x of a struct type T, the
operand is mentioned as (new):
x (variable of struct type T)
instead of (old):
x (variable of type T)
This approach is also used when a basic type is renamed, for instance
as in:
x (value of uint type big.Word)
which makes it clear that big.Word is a uint.
This change is expected to produce more informative error messages.
Fixes#69955.
Change-Id: I544b0698f753a522c3b6e1800a492a94974fbab7
Reviewed-on: https://go-review.googlesource.com/c/go/+/621458
Reviewed-by: Alan Donovan <adonovan@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This change improves error message for recursive types.
Currently, compilation of the [following program](https://go.dev/play/p/3ef84ObpzfG):
package main
type T1[T T2] struct{}
type T2[T T1] struct{}
returns an error:
./prog.go:3:6: invalid recursive type T1
./prog.go:3:6: T1 refers to
./prog.go:4:6: T2 refers to
./prog.go:3:6: T1
With the patch applied the error message looks like:
./prog.go:3:6: invalid recursive type T1
./prog.go:3:6: T1 refers to T2
./prog.go:4:6: T2 refers to T1
Change-Id: Ic07cdffcffb1483c672b241fede4e694269b5b79
GitHub-Last-Rev: cd042fdc38
GitHub-Pull-Request: golang/go#69574
Reviewed-on: https://go-review.googlesource.com/c/go/+/614084
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Tim King <taking@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Currently, on Mach-O, the Go linker doesn't generate LC_UUID in
internal linking mode. This causes some macOS system tools unable
to track the binary, as well as in some cases the binary unable
to access local network on macOS 15.
This CL makes the linker start generate LC_UUID. Currently, the
UUID is generated if the -B flag is specified. And we'll make it
generate UUID by default in a later CL. The -B flag is currently
for generating GNU build ID on ELF, which is a similar concept to
Mach-O's UUID. Instead of introducing another flag, we just use
the same flag and the same setting. Specifically, "-B gobuildid"
will generate a UUID based on the Go build ID.
For #68678.
Cq-Include-Trybots: luci.golang.try:gotip-darwin-amd64_14,gotip-darwin-arm64_13
Change-Id: I90089a78ba144110bf06c1c6836daf2d737ff10a
Reviewed-on: https://go-review.googlesource.com/c/go/+/618595
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ingo Oeser <nightlyone@googlemail.com>
Reviewed-by: Than McIntosh <thanm@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Use the new SwissTable-based map in internal/runtime/maps as the basis
for the runtime map when GOEXPERIMENT=swissmap.
Integration is complete enough to pass all.bash. Notable missing
features:
* Race integration / concurrent write detection
* Stack-allocated maps
* Specialized "fast" map variants
* Indirect key / elem
For #54766.
Cq-Include-Trybots: luci.golang.try:gotip-linux-ppc64_power10,gotip-linux-amd64-longtest-swissmap
Change-Id: Ie97b656b6d8e05c0403311ae08fef9f51756a639
Reviewed-on: https://go-review.googlesource.com/c/go/+/594596
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The expand-calls pass assumed that tail calls were always done in the
entry block. That used to be true, but with tail calls in wrappers
(enabled by CL 578235) and libfuzzer instrumentation, that is no
longer the case. Libfuzzer instrumentation adds an IF statement to the
start of the wrapper function.
Fixes#69825
Change-Id: I9ab7133691d8235f9df128be39bff154b0b8853b
Reviewed-on: https://go-review.googlesource.com/c/go/+/619075
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@google.com>
CL 615915 simplified test for issue 69434, using gcflags maymorestack to
force stack moving, making program failed with invalid stack pointer.
However, it seems that this maymorestack is broken on riscv64. At least
gotip-linux-riscv64 is currently broken.
This CL fixes this problem by using the initial approach, growing stack
size big enough to force stack moving.
Updates #69434Fixes#69714
Cq-Include-Trybots: luci.golang.try:gotip-linux-riscv64
Change-Id: I95255fba884a200f75bcda34d58e9717e4a952ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/616698
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
CL 584596 "-range<N>" suffix to the name of closure generated for a
rangefunc loop body. However, this breaks the condition that escape
analysis uses for checking whether a closure contains within function,
which is "F.funcN" for outer function "F" and closure "funcN".
Fixing this by adding new "-rangeN" to the condition.
Fixes#69434Fixes#69507
Change-Id: I411de8f63b69a6514a9e9504d49d62e00ce4115d
Reviewed-on: https://go-review.googlesource.com/c/go/+/614096
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Fixes#24755
Change-Id: I00b276c5c2acb227d42a069d1af6027e4b499d31
Reviewed-on: https://go-review.googlesource.com/c/go/+/613115
Auto-Submit: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Tim King <taking@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Fixes#20027
Change-Id: Ia616d43c0affa7b927ddfb53755072c94ba27917
Reviewed-on: https://go-review.googlesource.com/c/go/+/612618
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Tim King <taking@google.com>
In rare situations, like during same-sized grows, the source map for
maps.Clone may be overloaded (has more than 6.5 entries per
bucket). This causes the runtime to allocate a larger bucket array for
the destination map than for the source map. The maps.Clone code
walks off the end of the source array if it is smaller than the
destination array.
This is a pretty simple fix, ensuring that the destination bucket
array is never longer than the source bucket array. Maybe a better fix
is to make the Clone code handle shorter source arrays correctly, but
this fix is deliberately simple to reduce the risk of backporting this
fix.
Fixes#69110
Change-Id: I824c93d1db690999f25a3c43b2816fc28ace7509
Reviewed-on: https://go-review.googlesource.com/c/go/+/609757
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Enables V2 unified IR bitstreams when GOEXPERIMENT aliastypeparams
are enabled.
Allows pkgbits.NewPkgEncoder to set the output version.
Reenables support for writing V0 streams.
Updates #68778
Updates #68526
Change-Id: I590c494d81ab7db148232ceaba52229068d1e986
Reviewed-on: https://go-review.googlesource.com/c/go/+/608595
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Change the rules for how //go:build "file versions" are applied: instead
of considering whether a file version is an upgrade or downgrade from
the -lang version, always use max(fileVersion, go1.21). This prevents
file versions from downgrading the version below go1.21. Before Go 1.21
the //go:build version did not have the meaning of setting the file's
langage version.
This fixes an issue that was appearing in GOPATH builds: Go 1.23.0
started providing -lang versions to the compiler in GOPATH mode (among
other places) which it wasn't doing before, and it set -lang to the
toolchain version (1.23). Because the -lang version was greater than
go1.21, language version used to compile the file would be set to the
//go:build file version. //go:build file versions below 1.21 could cause
files that could previously build to stop building.
For example, take a Go file with a //go:build line specifying go1.10.
If that file used a 1.18 feature, that use would compile fine with a Go
1.22 toolchain. But it would produce an error when compiling with the
1.23.0 toolchain because it set the language version to 1.10 and
disallowed the 1.18 feature. This breaks backwards compatibility: when
the build tag was added, it did not have the meaning of restricting the
language version.
For #68658
Change-Id: I6cedda81a55bcccffaa3501eef9e2be6541b6ece
Reviewed-on: https://go-review.googlesource.com/c/go/+/607955
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Adds a -gomodversion flag to testdir. This sets the go version
in generated go.mod files. This is just runindir tests at the moment.
This is a building block so that tests can be written for exported
type parameterized aliases (like reproducing #68526).
This also adds a test that uses this feature. A type parameterized
alias is used so aliastypeparams and gotypesalias must be enabled.
gotypesalias is enabled by the go module version. The alias is not
exported and will not appear in exportdata. The test shows the
package containing the alias can be imported. This encapsulates
the level of support of type parameterized aliases in 1.23.
Updates #68526
Updates #68778
Change-Id: I8e20df6baa178e1d427d0fff627a16714d9c3b18
Reviewed-on: https://go-review.googlesource.com/c/go/+/604102
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Austin Clements <austin@google.com>
This reverts CL 603895
Reason for revert: We've decided to change the logic for how upgrades are done and want to submit the new logic in a self contained CL that can be cherry-picked onto release-branch.go1.23
Change-Id: I366af8e95ce1de7311b0385a23f9dd3df175745a
Reviewed-on: https://go-review.googlesource.com/c/go/+/605675
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Changes the type inference error message so that the position is
proceeded by a space. cmd/go rewrites the output of gc to replace
absolute paths at the beginning of lines and those proceeded by a
space or a tab to relative paths.
Updates testdir to do the same post processing on the output
of tests as cmd/go.
Fixes#68292
Change-Id: Ie109b51143e68f6e7ab4cd19064110db0e609a7e
Reviewed-on: https://go-review.googlesource.com/c/go/+/603097
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Only honor //go:build language version downgrades if the version
specified is 1.21 or greater. Before 1.21 the version in //go:build
lines didn't have the meaning of setting the file's language version.
This fixes an issue that was appearing in GOPATH builds: Go 1.23 started
providing -lang versions to the compiler in GOPATH mode (among other
places) which it wasn't doing before.
For example, take a go file with a //go:build line specifying go1.10.
If that file used a 1.18 feature, that use would compile fine with a Go
1.22 toolchain. But, before this change, it would produce an error when
compiling with the 1.23 toolchain because it set the language version to
1.20 and disallowed the 1.18 feature. This breaks backwards
compatibility: when the build tag was added, it did not have the meaning
of restricting the language version.
Fixes#68658
Change-Id: I4ac2b45a981cd019183d52ba324ba8f0fed93a8e
Reviewed-on: https://go-review.googlesource.com/c/go/+/603895
Reviewed-by: Robert Griesemer <gri@google.com>
Commit-Queue: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Matloob <matloob@golang.org>
Local facts can get us to unsatisfiable because there is an
unconditional panic in the block. That shouldn't declare the whole
block as unreachable, because we do still need to enter it to get
that panic.
Fixes#68816
Change-Id: I9220edb46089690702d2eb61d112815c7ac91f16
Reviewed-on: https://go-review.googlesource.com/c/go/+/604118
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
I think I introduced #68809 when rewriting the prove pass, by
introducing an off-by-one error here:
https://go-review.googlesource.com/c/go/+/599096/5/src/cmd/compile/internal/ssa/prove.go
lines 872-874.
The min++ is already handled in one of the two following cases with
the (r&eq==0) condition. Move the min++ to just the other case.
Fixes#68809
Change-Id: Iffae99e29219c94aaf584cd7ae247289fa604a00
Reviewed-on: https://go-review.googlesource.com/c/go/+/604100
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Apparently people don't tend to pass untyped constant expressions
to panic.
For #68734
Change-Id: I6fff8137a0f001391de9e61860b67026a9db08c2
Reviewed-on: https://go-review.googlesource.com/c/go/+/603096
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Commit-Queue: Ian Lance Taylor <iant@google.com>
This CL adds a "deadlocals" pass, which runs after inlining and before
escape analysis, to prune any unneeded local variables and
assignments. In particular, this helps avoid unnecessary Addrtaken
markings from unreachable closures.
Deadlocals is sensitive to "_ = ..." as a signal of explicit
use for testing. This signal occurs only if the entire
left-hand-side is "_" targets; if it is
`_, ok := someInlinedFunc(args)`
then the first return value is eligible for dead code elimination.
Use this (`_ = x`) to fix tests broken by deadlocals elimination.
Includes a test, based on one of the tests that required modification.
Matthew Dempsky wrote this, changing ownership to allow rebases, commits, tweaks.
Fixes#65158.
Old-Change-Id: I723fb69ccd7baadaae04d415702ce6c8901eaf4e
Change-Id: I1f25f4293b19527f305c18c3680b214237a7714c
Reviewed-on: https://go-review.googlesource.com/c/go/+/600498
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: David Chase <drchase@google.com>
Commit-Queue: David Chase <drchase@google.com>
The typechecker is assuming that alias instances cannot be reached from
a named type. However, when type parameters on aliases are permited, it
can happen.
This CL changes the typechecker to propagate the correct named instance
is being expanded.
Updates #46477Fixes#68580
Change-Id: Id0879021f4640c0fefe277701d5096c649413811
Reviewed-on: https://go-review.googlesource.com/c/go/+/601115
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Follow up review in CL 597535.
Updates #54846
Change-Id: Idf586552a22bbc6710c0888f046df0a5d1f0ce4a
Reviewed-on: https://go-review.googlesource.com/c/go/+/597537
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
By using cgo.Incomplete to represent not-in-heap type.
While at it, also removing the type conversions tests, since they could
not be present without //go:notinheap pragma.
Fixes#54846
Change-Id: I5ee2a4b6498d4100c9770ed7bd62f52623e42526
Reviewed-on: https://go-review.googlesource.com/c/go/+/597536
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
So the bounds check which are eliminated during late fuse pass could be
detected correctly.
Fixes#67329
Change-Id: Id7992fbb8c26e0d43e7db66a0a3a2c0d9ed937a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/598635
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Runtime functions, e.g. internal/abi.NoEscape, should not be
instrumented with checkptr. But if they are inlined into a
checkptr-enabled function, they will be instrumented, and may
result in a check failure.
Let the compiler not inline runtime functions into checkptr-
enabled functions.
Also undo the change in the strings package in CL 598295, as the
compiler handles it now.
Fixes#68511.
Updates #68415.
Change-Id: I78eb380855ac9dd53c1a1a628ec0da75c3e5a1a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/599435
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
The function is called in nosplit context already.
Fixes#68525
Change-Id: I8b9e324335b7c605d5a20cacdd58df09b7a7cf52
Reviewed-on: https://go-review.googlesource.com/c/go/+/599675
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
When shapifying recursive instantiated types, the compiler ends up
leaving the type as-is if it already has been a shape type. However, if
both of type arguments are interfaces, and one of them is a recursive
one, it ends up being shaped as-is, while the other is shaped to its
underlying, causing mismatch in function signature.
Fixing this by shapifying an interface type as-is, if it is fully
instantiated and already been a shape type.
Fixes#65362Fixes#66663
Change-Id: I839d266e0443b41238b1b7362aca09adc0177362
Reviewed-on: https://go-review.googlesource.com/c/go/+/559656
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
CL 573955 added internal/abi:NoEscape function, and use it in strings
builder copyCheck code.
However, internal/abi is a runtime package, which can not be built with
-d=checkptr flag yet. This causes incorrect inlining decision, since
NoEscape must not be inlined when -d=checkptr is used.
Fixing this by re-introducing noescape wrapper.
Fixes#68415
Change-Id: I776cab4c9e9e4b3e58162dcce6ec025cb366bdee
Reviewed-on: https://go-review.googlesource.com/c/go/+/598295
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Jorropo <jorropo.pgm@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Fixes#68322
This reverts commit ad377e906a.
Change-Id: Ifa4811e2c679d789cc830dbff5e50301410e24d0
Reviewed-on: https://go-review.googlesource.com/c/go/+/596516
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Commit-Queue: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
CL 327651 rewrites a, b = f() to use temporaries when types are not
identical. That would leave OAS2 node appears in body of init function
for global variables initialization. The staticinit pass is not updated
to handle OAS2 node, causing ICE when compiling global variables.
To fix this, handle OAS2 nodes like other OAS2*, since they mostly
necessitate dynamic execution anyway.
Fixes#68264
Change-Id: I1eff8cc3e47035738a2c70d3169e35ec36ee9242
Reviewed-on: https://go-review.googlesource.com/c/go/+/596055
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
CL 418101 changes Unified IR writer to force mixed tag/case to have
common type, emitting the implicit conversion if any of the case values
are not assignable to the tag value's type.
However, the Go spec definition of equality is non-transitive for
channels stored in interfaces, causing incorrect behavior with channel
values comparison.
To fix it, don't emit the implicit conversions if tag type is channel.
Fixes#67190
Change-Id: I9a29d9ce3c7978f0689e9502ba6f15660c763d16
Reviewed-on: https://go-review.googlesource.com/c/go/+/594575
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Than McIntosh <thanm@google.com>
v = ... compute some value, which zeros top 32 bits ...
w = zero-extend v
We want to remove the zero-extension operation, as it doesn't do anything.
But if v is typed as a signed value, and it gets spilled/restored, it
might be re-sign-extended upon restore. So the zero-extend isn't actually
a NOP when there might be calls or other reasons to spill in between v and w.
Fixes#68227
Change-Id: I3b30b8e56c7d70deac1fb09d2becc7395acbadf8
Reviewed-on: https://go-review.googlesource.com/c/go/+/595675
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Joedian Reid <joedian@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Type parameters on aliases are now allowed after #46477 accepted.
Updates #46477Fixes#68054
Change-Id: Ic2e3b6f960a898163f47666e3a6bfe43b8cc22e2
Reviewed-on: https://go-review.googlesource.com/c/go/+/593715
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Robert Griesemer <gri@google.com>
In an attempt to address issue #65790 (confusing error messages),
quoting of names was introduced for some (but not all) names used
in error messages.
That CL solved the issue at hand at the cost of extra punctuation
(the quotes) plus some inconsistency (not all names were quoted).
This CL removes the quoting again in favor or adding a qualifying noun
(such as "name", "label", "package", "built-in" etc.) before a user-
specified name where needed.
For instance, instead of
invalid argument to `max'
we now say
invalid argument to built-in max
There's still a chance for confusion. For instance, before an error
might have been
`sadly' not exported by package X
and now it would be
name sadly not exported by package X
but adverbs (such as "sadly") seem unlikely names in programs.
This change touches a lot of files but only affects error messages.
Fixes#67685.
Change-Id: I95435b388f92cade316e2844d59ecf6953b178bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/589118
Auto-Submit: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
The posBaseMap is used to identify a file's syntax tree node
given a source position. The position is mapped to the file
base which is then used to look up the file node in posBaseMap.
When posBaseMap is initialized, the file position base
is not the file base if there's a line directive before
the package clause. This can happen in cgo-generated files,
for instance due to an import "C" declaration.
If the wrong file position base is used during initialization,
looking up a file given a position will not find the file.
If a version error occurs and the corresponding file is
not found, the old code panicked with a null pointer exception.
Make sure to consistently initialize the posBaseMap by factoring
out the code computing the file base from a given position.
While at it, check for a nil file pointer. This should not happen
anymore, but don't crash if it happens (at the cost of a slightly
less informative error message).
Fixes#67141.
Change-Id: I4a6af88699c32ad01fffce124b06bb7f9e06f43d
Reviewed-on: https://go-review.googlesource.com/c/go/+/586238
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Robert Griesemer <gri@google.com>
CL 579935 disabled usage of Alias types in the compiler, and tracks
the problem with issue #66873. The test case in #65893 passes now
with the current tip. This CL adds a test case to ensure there is no
regression once Alias types are enabled for the compiler.
Updates #66873Fixes#65893
Change-Id: I51b51bb13ca59549bc5925dd95f73da40465556d
Reviewed-on: https://go-review.googlesource.com/c/go/+/568455
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
This CL fixes an initialization loop during IR construction, that
stems from IR lacking first-class support for aliases. As a
workaround, we avoid publishing alias declarations until the RHS type
expression has been constructed.
Thanks to gri@ for investigating while I was out.
Fixes#66873.
Change-Id: I11e0d96ea6c357c295da47f44b6ec408edef89b7
Reviewed-on: https://go-review.googlesource.com/c/go/+/585399
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
When we optimize append(s, make([]T, n)...), we have to be careful
not to pass &s[0] + len(s)*sizeof(T) as the argument to memclr, as that
pointer might be past-the-end. This can only happen if n is zero, so
just special-case n==0 in the generated code.
Fixes#67255
Change-Id: Ic680711bb8c38440eba5e759363ef65f5945658b
Reviewed-on: https://go-review.googlesource.com/c/go/+/584116
Reviewed-by: Austin Clements <austin@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
... if the architecture can't do unaligned loads.
We already handle this in a few places, but this particular place
was added in CL 399542 and missed this additional restriction.
Fixes#67160
Change-Id: I45988f11ff3ed45df1c4da3f0931ab1fdb22dbfe
Reviewed-on: https://go-review.googlesource.com/c/go/+/583175
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Derek Parker <parkerderek86@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
[This is a partial roll-forward of CL 553055, the main change here
is that the stack slot overlap operation is flagged off by default
(can be enabled by hand with -gcflags=-d=mergelocals=1) ]
Preliminary compiler support for merging/overlapping stack slots of
local variables whose access patterns are disjoint.
This patch includes changes in AllocFrame to do the actual
merging/overlapping based on information returned from a new
liveness.MergeLocals helper. The MergeLocals helper identifies
candidates by looking for sets of AUTO variables that either A) have
the same size and GC shape (if types contain pointers), or B) have the
same size (but potentially different types as long as those types have
no pointers). Variables must be greater than (3*types.PtrSize) in size
to be considered for merging.
After forming candidates, MergeLocals collects variables into "can be
overlapped" equivalence classes or partitions; this process is driven
by an additional liveness analysis pass. Ideally it would be nice to
move the existing stackmap liveness pass up before AllocFrame
and "widen" it to include merge candidates so that we can do just a
single liveness as opposed to two passes, however this may be difficult
given that the merge-locals liveness has to take into account
writes corresponding to dead stores.
This patch also required a change to the way ssa.OpVarDef pseudo-ops
are generated; prior to this point they would only be created for
variables whose type included pointers; if stack slot merging is
enabled then the ssagen code creates OpVarDef ops for all auto vars
that are merge candidates.
Note that some temporaries created late in the compilation process
(e.g. during ssa backend) are difficult to reason about, especially in
cases where we take the address of a temp and pass it to the runtime.
For the time being we mark most of the vars created post-ssagen as
"not a merge candidate".
Stack slot merging for locals/autos is enabled by default if "-N" is
not in effect, and can be disabled via "-gcflags=-d=mergelocals=0".
Fixmes/todos/restrictions:
- try lowering size restrictions
- re-evaluate the various skips that happen in SSA-created autotmps
Updates #62737.
Updates #65532.
Updates #65495.
Change-Id: Ifda26bc48cde5667de245c8a9671b3f0a30bb45d
Reviewed-on: https://go-review.googlesource.com/c/go/+/575415
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
CL 395541 made staticopy safe, stop applying the optimization once
seeing an expression that may modify global variables. However, it
misses the case for OASOP expression, causing the static init
mis-recognizes the modification and think it's safe.
Fixing this by adding missing OASOP case.
Fixes#66585
Change-Id: I603cec018d3b5a09825c14e1f066a0e16f8bde23
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/575216
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This reverts CL 553055.
Reason for revert: causes crypto/ecdsa failures on linux ppc64/s390x builders
Change-Id: I9266b030693a5b6b1e667a009de89d613755b048
Reviewed-on: https://go-review.googlesource.com/c/go/+/575236
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Than McIntosh <thanm@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Preliminary compiler support for merging/overlapping stack
slots of local variables whose access patterns are disjoint.
This patch includes changes in AllocFrame to do the actual
merging/overlapping based on information returned from a new
liveness.MergeLocals helper. The MergeLocals helper identifies
candidates by looking for sets of AUTO variables that either A) have
the same size and GC shape (if types contain pointers), or B) have the
same size (but potentially different types as long as those types have
no pointers). Variables must be greater than (3*types.PtrSize) in size
to be considered for merging.
After forming candidates, MergeLocals collects variables into "can be
overlapped" equivalence classes or partitions; this process is driven
by an additional liveness analysis pass. Ideally it would be nice to
move the existing stackmap liveness pass up before AllocFrame
and "widen" it to include merge candidates so that we can do just a
single liveness as opposed to two passes, however this may be difficult
given that the merge-locals liveness has to take into account
writes corresponding to dead stores.
This patch also required a change to the way ssa.OpVarDef pseudo-ops
are generated; prior to this point they would only be created for
variables whose type included pointers; if stack slot merging is
enabled then the ssagen code creates OpVarDef ops for all auto vars
that are merge candidates.
Note that some temporaries created late in the compilation process
(e.g. during ssa backend) are difficult to reason about, especially in
cases where we take the address of a temp and pass it to the runtime.
For the time being we mark most of the vars created post-ssagen as
"not a merge candidate".
Stack slot merging for locals/autos is enabled by default if "-N" is
not in effect, and can be disabled via "-gcflags=-d=mergelocals=0".
Fixmes/todos/restrictions:
- try lowering size restrictions
- re-evaluate the various skips that happen in SSA-created autotmps
Fixes#62737.
Updates #65532.
Updates #65495.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest
Change-Id: Ibc22e8a76c87e47bc9fafe4959804d9ea923623d
Reviewed-on: https://go-review.googlesource.com/c/go/+/553055
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This reverts CL 575175.
Reason for revert: causes crypto/ecdh failures on longtest builders.
Change-Id: Ieed326fedf91760ac73095a42ba0237cf969843b
Reviewed-on: https://go-review.googlesource.com/c/go/+/575316
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Than McIntosh <thanm@google.com>
CL 395541 made staticopy safe, stop applying the optimization once
seeing an expression that may modify global variables.
However, if a call expression was inlined, the analyzer mis-recognizes
and think that the expression is safe. For example:
var x = 0
var a = f()
var b = x
are re-written to:
var x = 0
var a = ~r0
var b = 0
even though it's not safe because "f()" may modify "x".
Fixing this by recognizing OINLCALL and mark the initialization as
not safe for staticopy.
Fixes#66585
Change-Id: Id930c0b7e74274195f54a498cc4c5a91c4e6d84d
Reviewed-on: https://go-review.googlesource.com/c/go/+/575175
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Than McIntosh <thanm@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
