Softfloat mode with register ABI is not implemented yet. In
particular, we did not rewrite the float types in AuxCalls to
integer types, so arguments are still passed in floating point
registers, which do not exist in softfloat mode. To make it work
I think we may want to reorder softfloat pass with expand_calls
pass. We also need to rewrite the OpArgFloatRegs for the spilling
of non-SSA-able arguments, which may involve renumbering interger
arguments. Maybe in softfloat mode we want to just define the
ABI with 0 float registers. They are not fundamentally hard, but
may be not worth doing for the moment, as we don't use softfloat
mode on AMD64 anyway.
Run the test with noregabiargs. Also in the compiler reject
-d=softfloat if regabiargs is enabled.
Change-Id: I8cc0c2cfa88a138bc1338ed8710670245f1bd2cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/308710
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
CL 302231 added some optimization rules with instructions CSETM, CSINC,
CSINV, and CSNEG, but did not deal with the situation where flag is
constant, resulting in some cases that could be more optimized cannot
be optimized, and the FlagConstant value is passed to codegen pass. This
CL adds these missing rules.
Fixes#45359
Change-Id: I700608cfb9a6a768a18d1fd5d374d7e92aa6f838
Reviewed-on: https://go-review.googlesource.com/c/go/+/307650
Reviewed-by: eric fang <eric.fang@arm.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Alberto Donizetti <alb.donizetti@gmail.com>
Run-TryBot: eric fang <eric.fang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: eric fang <eric.fang@arm.com>
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
The math to invert the input index was wrong.
Fixes#45323
Change-Id: I7c68cac280e8f01a9c806ecb0f195f169267437e
Reviewed-on: https://go-review.googlesource.com/c/go/+/306431
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: fannie zhang <Fannie.Zhang@arm.com>
Reviewed-by: David Chase <drchase@google.com>
In CL 305672 we preserve the pointer type of a store by just not
decomposing it. But this can be problematic when the source of
the store is a direct interface aggregate type (e.g.
struct { x map[int]int }.
In this CL we take a different approach: we preserve the store
type when generating the new store, but also decompose the source.
Fixes#45344.
Change-Id: If5dd496458dee95aa649c6d106b96a6cdcf3e60d
Reviewed-on: https://go-review.googlesource.com/c/go/+/306669
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>
Under certain circumstances, the existing rules for bit operations can
produce code that writes beyond its intended bounds. For example,
consider the following code:
func repro(b []byte, addr, bit int32) {
_ = b[3]
v := uint32(b[0]) | uint32(b[1])<<8 | uint32(b[2])<<16 | uint32(b[3])<<24 | 1<<(bit&31)
b[0] = byte(v)
b[1] = byte(v >> 8)
b[2] = byte(v >> 16)
b[3] = byte(v >> 24)
}
Roughly speaking:
1. The expression `1 << (bit & 31)` is rewritten into `(SHLL 1 bit)`
2. The expression `uint32(b[0]) | uint32(b[1])<<8 | uint32(b[2])<<16 |
uint32(b[3])<<24` is rewritten into `(MOVLload &b[0])`
3. The statements `b[0] = byte(v) ... b[3] = byte(v >> 24)` are
rewritten into `(MOVLstore &b[0], v)`
4. `(ORL (SHLL 1, bit) (MOVLload &b[0]))` is rewritten into
`(BTSL (MOVLload &b[0]) bit)`. This is a valid transformation because
the destination is a register: in this case, the bit offset is masked
by the number of bits in the destination register. This is identical
to the masking performed by `SHL`.
5. `(MOVLstore &b[0] (BTSL (MOVLload &b[0]) bit))` is rewritten into
`(BTSLmodify &b[0] bit)`. This is an invalid transformation because
the destination is memory: in this case, the bit offset is not
masked, and the chosen instruction may write outside its intended
32-bit location.
These changes fix the invalid rewrite performed in step (5) by
explicitly maksing the bit offset operand to `BT(S|R|C)(L|Q)modify`. In
the example above, the adjusted rules produce
`(BTSLmodify &b[0] (ANDLconst [31] bit))` in step (5).
These changes also add several new rules to rewrite bit sets, toggles,
and clears that are rooted at `(OR|XOR|AND)(L|Q)modify` operators into
appropriate `BT(S|R|C)(L|Q)modify` operators. These rules catch cases
where `MOV(L|Q)store ((OR|XOR|AND)(L|Q) ...)` is rewritten to
`(OR|XOR|AND)(L|Q)modify` before the `(OR|XOR|AND)(L|Q) ...` can be
rewritten to `BT(S|R|C)(L|Q) ...`.
Overall, compilecmp reports small improvements in code size on
darwin/amd64 when the changes to the compiler itself are exlcuded:
file before after Δ %
runtime.s 536464 536412 -52 -0.010%
bytes.s 32629 32593 -36 -0.110%
strings.s 44565 44529 -36 -0.081%
os/signal.s 7967 7959 -8 -0.100%
cmd/vendor/golang.org/x/sys/unix.s 81686 81678 -8 -0.010%
math/big.s 188235 188253 +18 +0.010%
cmd/link/internal/loader.s 89295 89056 -239 -0.268%
cmd/link/internal/ld.s 633551 633232 -319 -0.050%
cmd/link/internal/arm.s 18934 18928 -6 -0.032%
cmd/link/internal/arm64.s 31814 31801 -13 -0.041%
cmd/link/internal/riscv64.s 7347 7345 -2 -0.027%
cmd/compile/internal/ssa.s 4029173 4033066 +3893 +0.097%
total 21298280 21301472 +3192 +0.015%
Change-Id: I2e560548b515865129e1724e150e30540e9d29ce
GitHub-Last-Rev: 9a42bd29a5
GitHub-Pull-Request: golang/go#45242
Reviewed-on: https://go-review.googlesource.com/c/go/+/304869
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
This test is verifying that setting or unsetting an environment
variable in Go via the "os" package makes that change visible to the C
getenv function. The test has been failing on Windows since CL 304569;
it isn't clear to me whether it was running at all before that point.
On Windows the getenv and _putenv C functions are not thread-safe,
so Go's os.Setenv and os.Getenv use the SetEnvironmentVariable and
GetEnvironmentVariable system calls instead. That seems to work fine
in practice; however, changes via SetEnvironmentVariable are
empirically not visible to the C getenv function on certain versions
of Windows.
The MSDN getenv documentation¹ states that ‘getenv operates only on
the data structures accessible to the run-time library and not on the
environment “segment” created for the process by the operating system.
Therefore, programs that use the envp argument to main or wmain may
retrieve invalid information.’ That may be related to what we're
seeing here.
(https://github.com/curl/curl/issues/4774 describes this same behavior
observed in the curl project.)
¹https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/getenv-wgetenv?view=msvc-160#remarks
Updates #36705
Change-Id: I222792f75c650f32c5025b0fa3edab232ff66353
Reviewed-on: https://go-review.googlesource.com/c/go/+/304669
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Change-Id: I868eeb79edaba9e3afc1407ae18b89daf7e67037
Reviewed-on: https://go-review.googlesource.com/c/go/+/304570
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This requires us to add a fake argument to issue36705.go so that the
test driver will build it with "go run" rather than "go tool compile".
Change-Id: Id08b97d898ee3e9d6c1fbb072a0a9317ed9faedd
Reviewed-on: https://go-review.googlesource.com/c/go/+/304569
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
We need to be careful that when doing value graph surgery, we not
re-substitute a value that has already been substituted. That can lead
to confusing a previous iteration's value with the current iteration's
value.
The simple fix in this CL just aborts the optimization if it detects
intertwined phis (a phi which is the argument to another phi). It
might be possible to keep the optimization with a more complicated
CL, but:
1) This CL is clearly safe to backport.
2) There were no instances of this abort triggering in
all.bash, prior to the test introduced in this CL.
Fixes#45175
Change-Id: I2411dca03948653c053291f6829a76bec0c32330
Reviewed-on: https://go-review.googlesource.com/c/go/+/304251
Trust: Keith Randall <khr@golang.org>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Change-Id: Icfa204761045b72a8ea173fd55eddf1f0e58d819
Reviewed-on: https://go-review.googlesource.com/c/go/+/304253
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Temporarily disable a questionable test case in fixedbugs/bug193.go
and enable the test as a whole. See the issues below for details.
Updates #45114.
Updates #45117.
Change-Id: I1de6f8d79b592eeeec139cd92b6c9cac56a9a74b
Reviewed-on: https://go-review.googlesource.com/c/go/+/303094
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Based on https://golang.org/cl/284256 for go/types.
Brings this code more in line with go/types.
Adjusted various tests to match new error messages which
generally are now better: for assignment errors, instead
of a generic "cannot convert" we now say "cannot use"
followed by a clearer reason as to why not.
Major differences to go/types with respect to the changed
files:
- Some of the new code now returns error codes, but they
are only used internally for now, and not reported with
errors.
- go/types does not "convert" untyped nil values to target
types, but here we do. This is unchanged from how types2
handled this before this CL.
Change-Id: If45336d7ee679ece100f6d9d9f291a6ea55004d8
Reviewed-on: https://go-review.googlesource.com/c/go/+/302757
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Now that we can set GOEXPERIMENT at build time, we no longer need
-d=fieldtrack in the compiler to enabled field tracking at build time.
Switch the one test that uses -d=fieldtrack to use GOEXPERIMENT
instead so we can eliminate this debug flag and centralize on
GOEXPERIMENT.
Updates #42681.
Change-Id: I14c352c9a97187b9c5ec8027ff672d685f22f543
Reviewed-on: https://go-review.googlesource.com/c/go/+/302969
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Change-Id: Ie52d70d2ae8a21acacf0745a4093650b03ac43f9
Reviewed-on: https://go-review.googlesource.com/c/go/+/302371
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
For #44383
Change-Id: I3610105dad3574e210e226d3ba80a4ba5a7eeaa6
Reviewed-on: https://go-review.googlesource.com/c/go/+/300789
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
In the ppc64 ISA DS form loads and stores are restricted to offset
fields that are a multiple of 4. This is currently handled with checks
in the rules that generate MOVDload, MOVWload, MOVDstore and
MOVDstorezero to prevent invalid instructions from getting to the
assembler.
An unhandled case was discovered which led to the search for a better
solution to this problem. Now, instead of checking the offset in the
rules, this will be detected when processing these Ops in
ssaGenValues in ppc64/ssa.go. If the offset is not valid, the address
of the symbol to be loaded or stored will be computed using the base
register + offset, and that value used in the new base register.
With the full address in the base register, the offset field can be
zero in the instruction.
Updates #44739
Change-Id: I4f3c0c469ae70a63e3add295c9b55ea0e30ef9b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/299789
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The compiler currently has problem that some imported type is missing
size calculation. The problem is not triggered until CL 283313 merged,
due to the compiler can compile the functions immediately when it sees
them, so during SSA generation, size calculation is still ok.
CL 283313 makes the compiler always push functions to compile queue,
then drain from it for compiling function. During this process, the
types calculation size is disabled, so calculating size during SSA now
make the compiler crashes.
To fix this, we can just always calculate type size during typechecking,
when importing type from other packages.
Fixes#44732
Change-Id: I8d00ea0b5aadd432154908280e55d85c75f3ce92
Reviewed-on: https://go-review.googlesource.com/c/go/+/299689
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: Dan Scales <danscales@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
CL 280456 introduced a new store combining rule. On the LHS some
of the Aux and AuxInt of the stores are not specified, therefore
ignored during the matching. The rule is only correct if they
match. This CL adds explict match.
TODO: maybe we want the rule matcher require Aux/AuxInt to be
always specified on the LHS (using _ to explicitly ignore)? Or
maybe we want it to match the zero value if not specified? The
current approach is error-prone.
Fixes#44823.
Change-Id: Ic12b4a0de63117f2f070039737f0c905f28561bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/299289
Trust: Cherry Zhang <cherryyz@google.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Invalid constant was already reported by noder, so don't re-check in
typecheck, which lead to compiler crashing.
Updates #43311
Change-Id: I48e2f540601cef725c1ff628c066ed15d848e771
Reviewed-on: https://go-review.googlesource.com/c/go/+/298713
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>
Same as CL 294031, but for OTYPESW.
Updates #43311
Change-Id: I996f5938835baff1d830c17ed75652315106bdfd
Reviewed-on: https://go-review.googlesource.com/c/go/+/298712
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>
The invalid interface type will be reported already, so don't expand
that invalid one, which causes the compiler crashes.
Updates #43311
Change-Id: Ic335cfa74f0b9fcfd0929dc5fd31d9156a8f5f5c
Reviewed-on: https://go-review.googlesource.com/c/go/+/298710
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>
CheckReturn uses fn.Type() unconditionally, so for invalid function,
fn.Type() will be nil, causes the compiler crashes.
Updates #43311
Change-Id: I4420dd296c72ea83986b38fbf2c7f51fa59757c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/298709
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>
Otherwise, if -d=panic was set, check2 will treat already reported
error as internal compiler error.
For #43311Fixes#44445
Change-Id: I5dbe06334666df21d9107396b9dcfdd905aa1e44
Reviewed-on: https://go-review.googlesource.com/c/go/+/294850
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>
After CL 272654, the compiler now use go/constant.Value to represent
constant nodes. That makes ir.ConstantValue requires node type to
correctly return value for untyped int node. But untyped int node can
have nil type after typechecked, e.g: using int value as key for
map[string]int, that makes the compiler crashes.
To fix it, just don't add the invalid key to constSet, since when
it's not important to report duplicated keys when they aren't valid.
For #43311Fixes#44432
Change-Id: I44d8f2b95f5cb339e77e8a705a94bcb16e62beb9
Reviewed-on: https://go-review.googlesource.com/c/go/+/294034
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 syntax.Parse returns error, noder.file will be nil. Currently, we
continue accessing it regardlessly and depend on gc.hidePanic to hide
the panic from user.
Instead, we should gracefully handle the error in LoadPackage, then exit
earlier if any error occurred.
Updates #43311
Change-Id: I0a108ef360bd4f0cc9f481071b8967355e1513af
Reviewed-on: https://go-review.googlesource.com/c/go/+/294030
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>
On import, make sure that an empty closure is represented as a single
empty block statement. Otherwise, the closure is dropped. Block
statements are not exported explicitly, so must recreate on import.
Fixes#44330
Change-Id: I061598f0f859dd71d2d0cbd10c77cdd81525d1f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/297569
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
In CL 253457, we did the same fix for direct function calls. But for
method calls, the receiver argument also need to be passed through the
wrapper function, which we are not doing so the compiler crashes with
the code in #44415.
It will be nicer if we can rewrite OCALLMETHOD to normal OCALLFUNC, but
that will be for future CL. The passing receiver argument to wrapper
function is easier for backporting to go1.16 branch.
Fixes#44415
Change-Id: I03607a64429042c6066ce673931db9769deb3124
Reviewed-on: https://go-review.googlesource.com/c/go/+/296490
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
ComputeAddrtaken needs to descend into closures, now that imported
bodies can include closures. The bug was that we weren't properly
setting Addrtaken for a variable inside a closure inside a function that
we were importing.
For now, still disable inlining of functions with closures for -G mode.
I'll enable it in a later change -- there are just a few fixes related
to the fact that we don't need to set Ntype for closure functions.
Added a test derived from the cilium repro in the issue.
Fixes#44370
Change-Id: Ida2a403636bf8740b471b3ad68b5474951811e19
Reviewed-on: https://go-review.googlesource.com/c/go/+/296649
Run-TryBot: Dan Scales <danscales@google.com>
Trust: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This reverts commit CL 294849.
Reason for revert: this doesn't actually fix the issue, as revealed
by the noopt builder's failures.
Change-Id: Ib4ea9ceb4d75e46b3b91ec348b365fd8c83316ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/296629
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The code for delayed declaration of inlined result parameters only
handles non-empty return statements. This is generally okay, because
we already early declare if there are any (non-blank) named result
parameters.
But if a user writes a function with only blank result parameters and
with exactly one return statement, which is empty, then they could end
up hitting the dreaded "Value live at entry" ICE.
This CL fixes the issue by ensuring we always early declare inlined
result parameters if there are any empty return statements.
Fixes#44355.
Change-Id: I315f3853be436452883b1ce31da1bdffdf24d506
Reviewed-on: https://go-review.googlesource.com/c/go/+/293293
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
In CL 253457, we did the same fix for direct function calls. But for
method calls, the receiver argument also need to be passed through the
wrapper function, which we are not doing so the compiler crashes with
the code in #44415.
As we already rewrite t.M(...) into T.M(t, ...) during walkCall1, to fix
this, we can do the same trick in wrapCall, so the receiver argument
will be treated as others.
Fixes#44415
Change-Id: I396182983c85d9c5e4494657da79d25636e8a079
Reviewed-on: https://go-review.googlesource.com/c/go/+/294849
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
bug511.dir/b.go:10:14: error: reference to undefined field or method 'M'
Change-Id: I9f96dc5c7254b310bc3e15b0bc588d62718cb4b2
Reviewed-on: https://go-review.googlesource.com/c/go/+/292009
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
CL 274294 improved findTypeLoop but also fixed a new found bug on master
branch. This Cl adds test cases for this.
Updates #44266
Change-Id: Ie4a07a3487758a1e4ad2f2847dcde975b10d2a77
Reviewed-on: https://go-review.googlesource.com/c/go/+/292889
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
For import of functions with closures, the connections among closure
variables are constructed on-the-fly via CaptureName(). For multiple
nested closures, we need to temporarily set r.curfn to each closure we
construct, so that the processing of closure variables will be correct
for any nested closure inside that closure.
Fixes#44335
Change-Id: I34f99e2822250542528ff6b2232bf36756140868
Reviewed-on: https://go-review.googlesource.com/c/go/+/294212
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
One CFGs that shortcircuit looks for is:
p q
\ /
b
/ \
t u
The test case creates a CFG like that in which p == t.
That caused the compiler to generate a (short-lived) invalid phi value.
Fix this with a relatively big hammer: Disallow single-length loops entirely.
This is probably overkill, but it such loops are very rare.
This doesn't change the generated code for anything in std.
It generates worse code for the test case:
It no longer compiles the entire function away.
Fixes#44465
Change-Id: Ib8cdcd6cc9d7f48b4dab253652038ace24eae152
Reviewed-on: https://go-review.googlesource.com/c/go/+/295130
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
It was fixed by CL 294289, for #44378.
This is a different style of test that uses
line directives instead of extremely long lines.
Fixes#38698.
Change-Id: I50a1585030978b35fffa9981d6ed96b99216dc3e
Reviewed-on: https://go-review.googlesource.com/c/go/+/295129
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
DWARF generation uses variable source positions (file/line/col) as a
way to uniquely identify locals and parameters, as part of the process
of matching up post-optimization variables with the corresponding
pre-optimization versions (since the DWARF needs to be in terms of the
original source constructs).
This strategy can run into problems when compiling obfuscated or
machine-generated code, where you can in some circumstances wind up
with two local variables that appear to have the same name, file,
line, and column. This patch changes DWARF generation to skip over
such duplicates as opposed to issuing a fatal error (if an
obfuscation tool is in use, it is unlikely that a human being will be
able to make much sense of DWARF info in any case).
Fixes#44378.
Change-Id: I198022d184701aa9ec3dce42c005d29b72d2e321
Reviewed-on: https://go-review.googlesource.com/c/go/+/294289
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
By default, when typechecking a closure, tcClosure() creates a new
closure function. This should really be done separate from typechecking.
For now, we explicitly avoid creating a new closure function when
typechecking an inline body (in ImportedBody). However, the heuristic
for determining when we are typechecking an inline body was not correct
for double nested closures in an inline body, since CurFunc will then be
the inner closure, which has a body.
So, use a simple global variable to indicate when we typechecking an
inline body. The global variable is fine (just like ir.CurFunc), since
the front-end runs serially.
Fixes#44325
Change-Id: If2829fe1ebb195a7b1a240192b57fe6f04d1a36b
Reviewed-on: https://go-review.googlesource.com/c/go/+/294211
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
When generating DWARF inlined info records, it's possible to have a
local function whose only callsites are inlined away, meaning that we
emit an abstract function DIE but no regular subprogram DIE. When
emitting DWARF scope info we need to handle this case (specifically
when scoping PCs, check for the case that the func in question has
been entirely deleted).
Fixes#44344.
Change-Id: I9f5bc692f225aa4c5c23f7bd2e50bcf7fe4fc5f3
Reviewed-on: https://go-review.googlesource.com/c/go/+/293309
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
This is a port of CL 287494 to go/types. The additional checks in
test/fixedbugs are included, though they won't be executed by go/types.
Support for errorcheckdir checks will be added to go/types in a later
CL.
Change-Id: I37e202ea5daf7d7b8fc6ae93a4c4dbd11762480f
Reviewed-on: https://go-review.googlesource.com/c/go/+/290570
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This enables another test.
Change-Id: I80763b97d939e225158a083299b2e0d189268bc7
Reviewed-on: https://go-review.googlesource.com/c/go/+/289569
Trust: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
