We need an extra case in convertToDictionary. In the case of an operand
which is an interface and converting to an empty interface, we don't
want to get the run-time type from the dictionary (which would be the
run-time type of the interface). We want to do a type-assert to the
empty interface.
Change-Id: I414247210168153151272fab198bfe82ad7b1567
Reviewed-on: https://go-review.googlesource.com/c/go/+/342009
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Currently, for hidden closures, we always push them to compile queue
during typechecking. If the hidden closure is discarded from the outer
function body during deadcode, any desugaring phase after deadcode won't
be applied to the closure. Thus, some un-expected OPs are passed to
downstream passes, which they can't handle, the compiler goes boom!
To fix this, we keep track of discarded hidden closures during deadcode
pass, and won't compile them then.
Fixes#47712
Change-Id: I078717d5d1f4f2fa39cbaf610cfffbb042e70ceb
Reviewed-on: https://go-review.googlesource.com/c/go/+/342350
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>
Capturing dictionary closure variables is ok.
Fixes#47684
Change-Id: I049c87117915e0c5a172b9665bfac2f91064b2d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/342050
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
We use "build" for tests in the main package with a main function.
We use "compile" for tests that are not in the main package.
Change-Id: I9876b55a9e4672277483fd24e69058d439c66658
Reviewed-on: https://go-review.googlesource.com/c/go/+/334329
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
The first version of CL 340609 for gofrontend passed all existing tests,
but not this one.
For #42076
Change-Id: I6491e2f186091bdae140b7f7befa511806a6478a
Reviewed-on: https://go-review.googlesource.com/c/go/+/340950
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
For #47131
Change-Id: Ie2d5a2bd3dceec607544c43e6dc68bd5ea353091
Reviewed-on: https://go-review.googlesource.com/c/go/+/335172
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Change-Id: I9bba21a64d7e9f42395b6fcdf8aa3ca01cf131dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/340912
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Add the respective check and add missing bodies to tests.
Use {} as body for functions that don't return a result.
Use { panic(0) } as body for functions that return a result.
For #47069.
Change-Id: Ia5d7525c9c036baf8a955d13bff448401e08235e
Reviewed-on: https://go-review.googlesource.com/c/go/+/340911
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
In the cases where we do an early call to typecheckaste() in noder to
expose CONVIFACE nodes, we need a preceding call to transformArgs().
This is needed to allow typecheckaste() to run correctly, in the case of
f(g()), where g has multiple return values.
I also cleaned up the code a bit and commented the code in Call(), and
we do the call to typecheckaste() in several more cases.
In stencil.go:stencil(), I moved the transformCall earlier for the
OCALLMETH/ODOTMETH case, just as I did in my previous CL for
OCALL/OFUNCINST. By doing this, transformArgs no longer needs to deal
with the extra dictionary args. Therefore, I was able to simply
transformArgs() to look like typecheckargs() again, and make use of
RewriteMultiValue directly.
Updates #47514
Change-Id: I49eb82ac05707e50c2e2fb03e39458a70491d406
Reviewed-on: https://go-review.googlesource.com/c/go/+/340531
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Add a new dynamicType node, which is used as a case entry when
the type being switched to is generic.
Change-Id: Ice77c6f224b8fdd3ff574fdf4a8ea5f6c7ddbe75
Reviewed-on: https://go-review.googlesource.com/c/go/+/339429
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Simplify the implementation of interface conversions in the compiler.
Don't pass fields that aren't needed (the data word, usually) to the runtime.
For generics, we need to put a dynamic type in an interface. The new
dataWord function is exactly what we need (the type word will come
from a dictionary).
Change-Id: Iade5de5c174854b65ad248f35c7893c603f7be3d
Reviewed-on: https://go-review.googlesource.com/c/go/+/340029
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
For make with a type parameter argument, the structural type of
the type parameter's constraint determines what make is making.
Change-Id: I3b48f8ce3236b7624e0638b5f5be208c5915c987
Reviewed-on: https://go-review.googlesource.com/c/go/+/339899
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Closures inside generic functions were being added to the g.target.Decls
list during noding, just like other closures. We remove generic
functions/methods from g.target.Decls, so they don't get compiled
(they're only available for export and stenciling). Most closures inside
generic functions/methods were similarly being removed from
g.target.Decls, because they have a generic parameter. But we need to
ensure no closures in generic function/methods are left remaining in
g.target.Decls, since we don't want them transformed and compiled.
So, we set a flag in (*irgen) that records when we are noding a
top-level generic function/method, and don't add any closures to
g.target.Decls when the flag is true.
Updates #47514
Change-Id: Id66b4c41d307ffa8f54cab6ce3646ade81606862
Reviewed-on: https://go-review.googlesource.com/c/go/+/340258
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
This CL resolves several known issues and TODOs.
- Represent type sets with term lists and using term list abstractions.
- Represent Unions internally as a list of (syntactical) terms.
Use term operations to print terms and detect overlapping union
entries.
- Compute type sets corresponding to unions lazily, on demand.
- Adjust code throughout.
- Adjusted error check in test/typeparam/mincheck.dir/main.go
to make test pass.
Change-Id: Ib36fb7e1d343c2b6aec51d304f0f7d1ad415f999
Reviewed-on: https://go-review.googlesource.com/c/go/+/338310
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
In this case, we can't use an itab for doing a bound call, since we're
converting from an interface to an interface. We do a static or dynamic
type assert in new function assertToBound().
The dynamic type assert in assertToBound() is only needed if a bound is
parameterized. In that case, we must do a dynamic type assert, and
therefore need a dictionary entry for the type bound (see change in
getGfInfo). I'm not sure if we can somehow limit this case, since using
an interface as a type arg AND having the type bound of the type
arg be parameterized is a very unlikely case.
Had to add the TUNION case to parameterizedBy1() (which is only used for
extra checking).
Added a bunch of these test cases to 13.go, which now passes.
Change-Id: Ic22eed637fa879b5bbb46d36b40aaad6f90b9d01
Reviewed-on: https://go-review.googlesource.com/c/go/+/339898
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Put shape types in the top level package called ".shape".
Name them using the serialization of the shape name, instead of
the .shapeN names.
This allows the linker to deduplicate instantiations across packages.
Not sure that this is entirely correct, as shapes in this package
may reference other packages (e.g. a field of a struct). But it seems
to work for now.
For the added test, when you look at the resulting binary (use the -k
option with run.go) it has only one instantiation of F, and 4 call sites:
$ objdump -d a.exe | grep _a\.F
1053cb0: e8 8b 00 00 00 callq 139 <_a.F[.shape.*uint8]>
1053ce9: e8 52 00 00 00 callq 82 <_a.F[.shape.*uint8]>
_a.F[.shape.*uint8]:
1053d90: e8 ab ff ff ff callq -85 <_a.F[.shape.*uint8]>
1053dc9: e8 72 ff ff ff callq -142 <_a.F[.shape.*uint8]>
Change-Id: I627f7e50210aabe4a10d0e2717d87b75ac82e99b
Reviewed-on: https://go-review.googlesource.com/c/go/+/339595
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Previously, softfloat mode does not work with register ABI, mainly
because the compiler doesn't know how to pass floating point
arguments and results. According to the ABI it should be passed in
FP registers, but there isn't any in softfloat mode.
This CL makes it work. When softfloat is used, we define the ABI
as having 0 floating point registers (because there aren't any).
The integer registers are unchanged. So floating point arguments
and results are passed in memory.
Another option is to pass (the bit representation of) floating
point values in integer registers. But this complicates things
because it'd need to reorder integer argument registers.
Change-Id: Ibecbeccb658c10a868fa7f2dcf75138f719cc809
Reviewed-on: https://go-review.googlesource.com/c/go/+/327274
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Except unsafe.Pointer. It has a different Kind, which makes it trickier.
Change-Id: I12582afb6e591bea35da9e43ac8d141ed19532a3
Reviewed-on: https://go-review.googlesource.com/c/go/+/338749
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
First baby step to sharing the underlying implementation among several types.
Change-Id: I6a156176d2b7f0131a87285a03b881ce380c26ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/338610
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Rewrite a method expression such as 'T.String' (where T is type param
and String is part of its type bound Stringer) as:
func(rcvr T, other params...) {
return Stringer(rcvr).String(other params...)
}
New function buildClosure2 to create the needed closure. The conversion
Stringer(rcvr) uses the dictionary in the outer function.
For a method expression like 'Test[T].finish' (where finish is a method
of Test[T]), we can already deal with this in buildClosure(). We just
need fix transformDot() to allow the method lookup to fail, since shapes
have no methods on them. That's fine, since for any instantiated
receiver type, we always use the methods on the generic base type.
Also removed the OMETHEXPR case in the main switch of node(), which
isn't needed any (and removes one more potential unshapify).
Also, fixed two small bugs with handling closures that have generic
params or generic captured variables. Need to set the instInfo for the
closure in the subst struct when descending into a closure during
genericSubst() and was missing initializing the startItabConv and gfInfo
fields in the closure info.
Change-Id: I6dadedd1378477936a27c9c544c014cd2083cfb7
Reviewed-on: https://go-review.googlesource.com/c/go/+/338129
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Introduce new dynamic dottype operations which take a dynamic
instead of static type to convert to.
Change-Id: I5824a1fea056fe811b1226ce059e1e8da1baa335
Reviewed-on: https://go-review.googlesource.com/c/go/+/337609
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
This CL renames blank functions in the test/ directory so that they
don't rely on the compiler doing anything more than typechecking them.
In particular, I ran this search to find files that used blank
functions and methods:
$ git grep -l '^func.*\b_(' | xargs grep -n '^' | grep '\.go:1:' | grep -v '// errorcheck$'
I then skipped updating a few files:
* blank.go
* fixedbugs/issue11699.go
* fixedbugs/issue29870.go
These tests specifically check that blank functions/methods work.
* interface/fail.go
Not sure the motivation for the blank method here, but it's empty
anyway.
* typeparam/tparam1.go
Type-checking test, but uses "-G" (to use types2 instead of typecheck).
Updates #47446.
Change-Id: I9ec1714f499808768bd0dcd7ae6016fb2b078e5e
Reviewed-on: https://go-review.googlesource.com/c/go/+/338094
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>
We don't usually reformat the test directory, but all of the files in
test/typeparam are syntactically valid. I suspect the misformattings
here are because developers aren't re-installing gofmt with
-tags=typeparams, not intentionally exercising non-standard
formatting.
Change-Id: I3767d480434c19225568f3c7d656dc8589197183
Reviewed-on: https://go-review.googlesource.com/c/go/+/338093
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Fix the cons.go missing method error. Mark all the methods of
instantiated interface types as used. We could try to record all the
exact methods used for generic interface types, but for now, just mark
all the methods as used so that their methods are not dead-code
eliminated.
Change-Id: I35685eda82476244371379b97691a1b8506ef0f7
Reviewed-on: https://go-review.googlesource.com/c/go/+/337349
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Change-Id: I5eb03ae349925f0799dd866e207221429bc9fb3c
Reviewed-on: https://go-review.googlesource.com/c/go/+/337353
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This is a partial port of https://golang.org/cl/330629, containing
only the actual bug fix and adjustements to another test file.
The respective test case has not been ported yet as it requires
some bigger adjustments.
For #46905
Change-Id: Ibd20658b8a31855da20cf56e24bcce9560656ca0
Reviewed-on: https://go-review.googlesource.com/c/go/+/336350
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Conflicts:
- src/cmd/compile/internal/ssagen/ssa.go
CL 336629 touched code that had already been removed on dev.typeparams.
Merge List:
+ 2021-07-26 ecaa6816bf doc: clarify non-nil zero length slice to array pointer conversion
+ 2021-07-26 1868f8296e crypto/x509: update iOS bundled roots to version 55188.120.1.0.1
+ 2021-07-25 849b791129 spec: use consistent capitalization for rune literal hex constants
+ 2021-07-23 0914646ab9 doc/1.17: fix two dead rfc links
+ 2021-07-22 052da5717e cmd/compile: do not change field offset in ABI analysis
Change-Id: Ie570ec3f6a3241e0495e39e8a73b3a09a9368605
This CL changes fixedbugs/issue30862.go into a "runindir" test so that
it can use '-goexperiment fieldtrack' and test that //go:nointerface
works with cmd/compile. In particular, this revealed that -G=3 and
unified IR did not handle it correctly.
This CL also fixes unified IR's support for //go:nointerface and adds
a test that checks that //go:nointerface, promoted methods, and
generics all interact as expected.
Updates #47045.
Change-Id: Ib8acff8ae18bf124520d00c98e8915699cba2abd
Reviewed-on: https://go-review.googlesource.com/c/go/+/332611
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
HasShape needs a TINTER case.
Add a test for x.(T) in various situations. Needs the fix above.
Also remove ONEW unshapify case. It is ok for ONEW to have a shape
type, as it will just be passed to mallocgc, or possibly used as a
stack object type, both of which are ok.
Change-Id: Ibddf8f5c8c254d32cb5ebcaca7dc94b4c00ab893
Reviewed-on: https://go-review.googlesource.com/c/go/+/337231
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Fixes -G=3 issue with issue44688.go.
Change-Id: Ie98c0cbd48683dedd115332043f14c8f3160f46c
Reviewed-on: https://go-review.googlesource.com/c/go/+/337029
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
This fix the case where a type param or derived type is converted to a
non-empty interface. Previously, we were converting to an empty
interface and then using DOTTYPE to convert to the correct non-empty
interface. In that case, we can get the needed itab directly from the
dictionary. This is needed for correctness from shapes, if the
destination interface is parameterized, else we will incorrectly convert
to the shape version of the interface.
Creating/writing an itab can involve generating wrappers for a bunch of
methods, which may use dictionaries. So, all the
dictionaries/instantiations are being generated on the fly and have
recursive relationships, it is simplest to finish creating/writing the
itabs at the end of the stenciling phase. So, we create a list of the
dictionaries which need to be completed by writing out their itab
entries.
The existing tests ordered.go, ifaceconv.go, and issue44688.go make use
of this optimization.
Got itab conversions for bound calls working, except for 13.go.
Also, want to get rid of the concretify, but I think we need more info
on the Bound from types2.
Change-Id: If552958a7b8a435500d6cc42c401572c367b30d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/336993
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Currently, the ABI analysis assigns parameter/result offsets
to the fields of function *Type. In some cases, we may have
an ABI0 function reference and an ABIInternal reference share
the same function *Type. For example, for an ABI0 function F,
"f := F" will make f and (ABI0) F having the same *Type. But f,
as a func value, should use ABIInternal. Analyses on F and f will
collide and cause ICE.
Also, changing field offsets in ABI analysis has to be done very
carefully to avoid data races. It has been causing
trickiness/difficulty.
This CL removes the change of field offsets in ABI analysis
altogether. The analysis result is stored in ABIParamAssignment,
which is the only way to access parameter/result stack offset now.
Fixes#47317.
Fixes#47227.
Change-Id: I23a3e081a6cf327ac66855da222daaa636ed1ead
Reviewed-on: https://go-review.googlesource.com/c/go/+/336629
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Than McIntosh <thanm@google.com>
CL 330670 simplified usemethod, but dropped the previous condition to
ensure the function have 1 or 2 result. This CL restore that condition,
and also add a test for it.
Change-Id: I434e3736785b43ceea0b386d8d9d01ad78a4ccd2
Reviewed-on: https://go-review.googlesource.com/c/go/+/336609
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 makes two related changes:
1. It uses 'go env -json' to query the environment configuration,
rather than attempting to manually reconstruct the values that cmd/go
is going to use.
2. It changes the -goexperiment flag to *extend* any ambient
GOEXPERIMENT configuration. Notably, this means that '-goexperiment
fieldtrack' now tests fieldtracking in conjunction with any other
experiments (e.g., unified IR). Tests that want to test an exact
GOEXPERIMENT config should use '-goexperiment none,foo' instead.
Change-Id: I96a97198209e540e934fe7035110c3ae3a8f0e6a
Reviewed-on: https://go-review.googlesource.com/c/go/+/332610
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>
Removed a case in transformCall() where we were setting a type on n,
which isn't needed, since noder2 already set the type of n. More
importantly, we are losing information, since the type of the results
may be a shape type, but the actual type of call is the known type
from types2, which may be a concrete type (in this case Zero[MyInt]).
That concrete type will then be used correctly if the concrete result is
converted to an interface.
If we are inlining the call to Zero[MyInt], we need to add an implicit
CONVNOP operation, since we are going to use the result variable
directly, which has a shape type. So, add an implicit CONVNOP to
remember that the known type is the concrete type.
Also cleaned up 14.go a bit, so it is more understandable. Renamed type
T to AnyInt, since T is used elsewhere as a type parameter. Reformatted
Zero function and added a comment.
Change-Id: Id917a2e054e0bbae9bd302232853fa8741d49b64
Reviewed-on: https://go-review.googlesource.com/c/go/+/336430
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
METHVALUE in a generic function (that is not called) was not causing
buildClosure() to be called and therefore not using dictionaries. Also,
had to add an extra check to make sure that if we have a FUNCINST
node above a METHVALUE, we only call buildClosure once.
Change-Id: I49756152fc343e5ac1c449e697960fc2a0f482ae
Reviewed-on: https://go-review.googlesource.com/c/go/+/336429
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
types2 will have already proved the expression's type is compatible, so
just assign the one const to have the same type as the operand.
Fixes#47258.
Change-Id: If0844e6bf6d0a5e6b11453b87df71353863ccc5d
Reviewed-on: https://go-review.googlesource.com/c/go/+/336009
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
The builtins.go test is derived from
cmd/compile/internal/types2/testdata/check/builtins.go2, after removing
the error cases. Added a few extra tests for len/cap/append.
Fixed one bug, which is that DELETE operations can't be transformed if
their argument is a typeparam. Also, the tranform of LEN/CAP calls does
not need to be delayed. Removed out-date references to the old
typechecker in the comments.
Change-Id: If7a21506a7ff63ff7c8e87ccd614ef4ff3a0d3c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/336010
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
We'll have to revisit eventually, but disabling for now.
Change-Id: Ic34cfe451939d61884079bb125b9290db1e05e47
Reviewed-on: https://go-review.googlesource.com/c/go/+/335829
Run-TryBot: Keith Randall <khr@golang.org>
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
CL 330330 moved logic for wrapping go/defer from order to esacpe
analysis. It introduced a bug involves go/defer statement with ABI0
functions.
Consider this following code:
package p
//go:cgo_unsafe_args
func g(*int) (r1 struct{}) {
return
}
func f() {
defer g(new(int))
}
g is a cgo-like generated function with ABI0. While compiling g, we set
the offset per ABI0.
The function f is rewritten into:
func f() {
_0, _1 := g, new(int)
defer func() { _0(_1) }()
}
The temporary _0 hold function value with the same type as g, but with
class PAUTO. Thus ssagen/ssa.go:state.call cannot handle it and use
ABIDefault to set the offset, causes the offset of r1 changed
CL 330332 intended to optimize code generated for wrapping function, by
rewriting the wrapper function into:
func f() {
_0 := new(int)
defer func() { g(_0) }()
}
So it fixed the bug unintentionally.
This CL add regression test for this bug, and also add a comment to
explain while not wrapping declared function is important.
Updates #47227
Change-Id: I75c83d1d9cc7fd4699e6b218a295d0c0a10ef471
Reviewed-on: https://go-review.googlesource.com/c/go/+/334882
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>
In CL 326211 a change was made to switch "go.map.zero" symbols from
non-pkg DUPOK symbols to hashed symbols. The intent of this change was
ensure that in cases where there are multiple competing go.map.zero
symbols feeding into a link, the largest map.zero symbol is selected.
The change was buggy, however, and resulted in duplicate symbols in
the final binary (see bug cited below for details). This duplication
was relatively benign for linux/ELF, but causes duplicate definition
errors on Windows.
This patch switches "go.map.zero" symbols back from hashed symbols to
non-pkg DUPOK symbols, and updates the relevant code in the loader to
ensure that we do the right thing when there are multiple competing
DUPOK symbols with different sizes.
Fixes#47185.
Change-Id: I8aeb910c65827f5380144d07646006ba553c9251
Reviewed-on: https://go-review.googlesource.com/c/go/+/334930
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
When comparing a value whose type is a type parameter to an interface,
we need to convert that type parameter to an interface using the dictionary
entries.
Change-Id: I409c9e36e376fe4ef8163407d0fd4e84496d5b65
Reviewed-on: https://go-review.googlesource.com/c/go/+/334150
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
- set correct position for closure capture variable in (*irgen).use()
(issue20250.go) Also, evaluate rhs, lhs in that order in assignment
statements to match noder1 (affects ordering of closure variables).
- make sure to set Assign flag properly in (*irgen).forStmt() for range
variables which are map accesses (issue9691.go)
- make sure CheckSize() is call on the base type for top-level types
converted by (*irgen).typ() that are pointer types (issue20174.go and
issue37837.go)
- deal with parentheses properly in validation function
(*irgen).validate() (issue17270.go)
- avoid HasNil call on type TTYPEPARAM - types2 typechecker will have
already checked validity of the typeparam having nil value (new test
issue39755.go)
Change-Id: Ie68004d964698aea047e19e7dcd79b297e9d47ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/334733
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Rather than removing "any" from the universe scope, keep it predeclared
but provide a better error message.
While at it, remove some unnecessary type assertions.
Change-Id: I10603274282ea6afc107f703ab194f32bd334dd1
Reviewed-on: https://go-review.googlesource.com/c/go/+/334911
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The compiler is relying on Sym.Def field to lookup symbol package in
DotImportRefs map. But the Sym.Def field is clear whenever the compiler
finish processing a file. If the dot import happen in file A, then the
redeclaration happen in file B, then the symbol lookup in file B will
see a nil Sym.Def, that cause the compiler crashes.
To fix this, we can interate over DotImportRefs and check for matching
symbol name and return the corresponding package. Though this operation
can be slow, but it only happens in invalid program, when printing error
message, so it's not worth to optimize it further.
Fixes#47201
Change-Id: I4ca1cb0a8e7432b19cf71434592a4cbb58d54adf
Reviewed-on: https://go-review.googlesource.com/c/go/+/334589
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>
For #47127.
Change-Id: Ie979ff56ae7c2dd0e5ce0ff39588f98ae68b5ee9
Reviewed-on: https://go-review.googlesource.com/c/go/+/334151
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Change-Id: I45189468553e83390fd2640b5708c60a7852fbb5
Reviewed-on: https://go-review.googlesource.com/c/go/+/333713
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Call SetPos() in g.expr() so it is available for any new nodes.
Print out the actual type for a composite literal in exprFmt() if
available, else use Ntype if available. Seems generally useful, since
the type name is always more useful than just 'composite literal'.
Fixes a bunch of cases that are excluded in run.go for -G=3.
Change-Id: I40b9bba88027ea4f36d419e3989e7f14891bea04
Reviewed-on: https://go-review.googlesource.com/c/go/+/334609
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
In the case that a generic function/method f does a method call on a
type param allowed by its bound, an instantiation of f may do a direct
method call of a concrete type or a method call defined on a generic
type, depending on whether the passed type in a concrete type or an
instantiated type with the appropriate method defined. See the test case
boundmethod.go added to this change.
In order to keep the dictionary format the same for all instantiations
of a generic function/method, I decided to have an optional
sub-dictionary entry for "bounds" calls. At the point that we are
creating the actual dictionary, we can then fill in the needed
sub-dictionary, if the type arg is an instantiated type, or a zeroed
dictionary entry, if type arg is not instantiated and the method will be
on a concrete type.
In order to implement this, I now fill in n.Selection for "bounds"
method calls in generic functions as well. Also, I need to calculate
n.Selection correctly during import for the case where it is now set -
method calls on generic types, and bounds calls on typeparams.
With this change, the dictionaries/sub-dictionaries are correct for
absdiff.go. The new test boundmethod.go illustrates the case where the
bound sub-dict entry is not used for a dictionary for stringify[myint],
but is used for a dictionary for stringify[StringInt[myint]].
Change-Id: Ie2bcb971b7019a9f1da68c97eb03da2333327457
Reviewed-on: https://go-review.googlesource.com/c/go/+/333456
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
types2 currently ignores pragmas, so it does not catch a conversion
error when converting a pointer to a type which is NOT marked notinheap
to a pointer to a convertible type, but which is marked notinheap.
So, we specifically check for this error in transformConv() and report
it during noder2.
Change-Id: I6e9c9ee29f53fa5e490c1ac8306e2191db59eeb4
Reviewed-on: https://go-review.googlesource.com/c/go/+/333369
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Conflicts:
- src/runtime/runtime2.go
On master, CL 317191 fixed the mentions of gc/reflect.go in comments
to reflectdata/reflect.go; but on dev.typeparams, CL 325921 fixed
that the same comment to reflect that deferstruct actually ended up
in ssagen/ssa.go.
Merge List:
+ 2021-07-08 296ddf2a93 net: filter bad names from Lookup functions instead of hard failing
+ 2021-07-08 ce76298ee7 Update oudated comment
+ 2021-07-08 2ca44fe221 doc/go1.17: linkify time.UnixMilli and time.UnixMicro
+ 2021-07-07 5c59e11f5e cmd/compile: remove special-casing of blank in types.sconv{,2}
+ 2021-07-07 b003a8b1ae cmd/compile: optimize types.sconv
+ 2021-07-07 11f5df2d67 cmd/compile: extract pkgqual from symfmt
+ 2021-07-07 991fd381d5 cmd/go: don't lock .mod and .sum files for read in overlay
+ 2021-07-07 186a3bb4b0 cmd/go/internal/modfetch/codehost: skip hg tests if no hg binary is present
+ 2021-07-07 00c00558e1 cmd/go/internal/modload: remove unused functions
+ 2021-07-07 f264879f74 cmd/go/internal/modload: fix an apparent typo in the AutoRoot comment
+ 2021-07-07 c96833e5ba doc: remove stale comment about arm64 port
Change-Id: I849046b6d8f7421f60323549f3f763ef418bf9e7
1.go, 12.go: similar to calculating type sizes, we delay computing
instantiations during import until we get up to a top-level type, in
order to make sure recursive types are complete. But we should always
delay calculating sizes when we delay instantiating types, since
otherwise we may try to calculate the size of an incomplete type. So,
needed to add Defer/ResumeCheckSize in (*importReader).typ where we also
defer instantiations. (iimport.go)
2.go: when doing type substition, we have to handle named, parameterized
basic types i.e. the type has a type parameter even though the
underlying type is a basic type that doesn't depend on the parameter.
(subr.go)
3.go: for go 1.18, we allow arbitrary types in interfaces. We had
already allowed union types and tilde types, but didn't allow regular
non-interface types in Go 1.17 for compatibility. Just skip an error
in the case of 1.18. (size.go)
5.go: types2 and types1 differ in how they print out interfaces. types1
puts a space between "interface" and "{", types2 does not. So, since
some typenames come from types2 and some from types1, we need to remove
the space when printing out type arguments. (iimport.go/subr.go)
9.go: in subst.node(), we were missing the KeyExpr case where a node has
no type. The assertion is just there, to make sure we understand all the
cases where there is no type to translate. We could just remove the
whole error check. (stencil.go)
13.go: in subst.node(), missed handling the case where a method
expression is immediate called (which of course, is quite unusual, since
then there's no real reason to have used the method expression syntax in
that case). Just needed to add ir.OMETHEXPR in the OCALL switch
statement. (stencil.go)
Change-Id: I202cbe9541dfafe740e3b84b44982d6181738ea0
Reviewed-on: https://go-review.googlesource.com/c/go/+/333165
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
types2.subst has an assertion that check is non-nil, but which breaks
Instantiate() with an interface type param (used when re-importing
instatiated type to types2). But this check was added when Instantiate()
was added, and things seem to work fine when the assertion is removed.
Fixes test/typeparam/mdempsky/7.go.
Change-Id: I4980f0b202a0b310a3c91a7a87f97576f54911de
Reviewed-on: https://go-review.googlesource.com/c/go/+/333155
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>
I'm not sure why blank was special-cased here before, but it's
wrong. Blank is a non-exported identifier, and writing it out without
package-qualification can result in linker symbol collisions.
Fixes#47087.
Change-Id: Ie600037c8e54e3d4fdaeec21e2ca212badbd830b
Reviewed-on: https://go-review.googlesource.com/c/go/+/333163
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>
Up to this point, we were only handling typeparams that were converted
to empty or non-empty interfaces. But we have a dictionary entry for
each derived type (i.e. type derived from typeparams) as well. So, when
doing a conversion, look for the source type in both the type params and
derived types of the generic info, and then use the appropriate
dictionary entry.
Added some cases to ifaceconv.go (e.g. converting []T to an empty
interface).
Change-Id: I7bbad0128bec20ccccd93ae1d65c1ffd44ca79a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/333011
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This allows exporting comparable type bounds, and importing back into
types2 for typechecking.
Fixes typeparam/mdempsky/8.go
Change-Id: I3ee12433df2ed68ac6ef4cad24be9fcdfaaca4e3
Reviewed-on: https://go-review.googlesource.com/c/go/+/333129
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>
The (*T).M method expression is where M is a value method, but the type
(*T) is a pointer to the main type. In this case, after following any
embedded fields, we need to add an extra star operator when using the
receiver arg in the closure call.
Thanks to Cuong for finding/pointing out an example for this case
(typeparam/mdempsky/14.go) This example also shows that we now need the
ability to export/import OEFACE and OIDATA, which I added.
Change-Id: Ida0f81ce757fff78fec6276c60052ed71d207454
Reviewed-on: https://go-review.googlesource.com/c/go/+/333014
Run-TryBot: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
This CL includes multiple test cases that exercise unique failures
with -G=3 mode that did not affect unified IR mode. Most of these were
found over a period of about 3 hours of manual experimentation.
Thanks to Cuong Manh Le for test cases 11 and 12.
Updates #46704.
Change-Id: Ia2fa619536732b121b6c929329065c85b9384511
Reviewed-on: https://go-review.googlesource.com/c/go/+/326169
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
This CL changes the existing excluded-test mechanism into a
known-failure mechanism instead. That is, it runs the test regardless,
but only reports if it failed (or succeeded) unexpectedly.
It also splits the known failures list into fine-grain failure lists
for types2, types2 w/ 32-bit target, -G=3, and unified.
Updates #46704.
Change-Id: I1213cbccf1bab6a92d9bfcf0d971a2554249bbff
Reviewed-on: https://go-review.googlesource.com/c/go/+/332551
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Added new struct instInfo for information about an instantiation (of a
generic function/method with gcshapes or concrete types). We use this to
remember the dictionary param node, the nodes where sub-dictionaries
need to be used, etc. The instInfo map replaces the Stencil map in
Package.
Added code to access sub-dictionary entries at the appropriate call
sites. We are currently still calculating the corresponding main
dictionary, even when we really only need a sub-dictionary. I'll clean
that up in a follow-up CL.
Added code to deal with "generic" closures (closures that reference some
generic variables/types). We decided that closures will share the same
dictionary as the containing function (accessing the dictionary via a
closure variable). So, the getGfInfo function now traverses all the
nodes of each closure in a function that it is analyzing, so that a
function's dictionary has all the entries needed for all its closures as
well. Also, the instInfo of a closure is largely shared with its
containing function. A good test for generic closures already exists
with orderedmap.go.
Other improvements:
- Only create sub-dictionary entries when the function/method
call/value or closure actually has type params in it. Added new test
file subdict.go with an example where a generic method has an
instantiated method call that does not depend not have type params.
Change-Id: I691b9dc024a89d2305fcf1d8ba8540e53c9d103f
Reviewed-on: https://go-review.googlesource.com/c/go/+/331516
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Conflicts:
- src/cmd/compile/internal/walk/builtin.go
On dev.typeparams, CL 330194 changed OCHECKNIL to not require manual
SetTypecheck(1) anymore; while on master, CL 331070 got rid of the
OCHECKNIL altogether by moving the check into the runtime support
functions.
- src/internal/buildcfg/exp.go
On master, CL 331109 refactored the logic for parsing the
GOEXPERIMENT string, so that it could be more easily reused by
cmd/go; while on dev.typeparams, several CLs tweaked the regabi
experiment defaults.
Merge List:
+ 2021-06-30 4711bf30e5 doc/go1.17: linkify "language changes" in the runtime section
+ 2021-06-30 ed56ea73e8 path/filepath: deflake TestEvalSymlinksAboveRoot on darwin
+ 2021-06-30 c080d0323b cmd/dist: pass -Wno-unknown-warning-option in swig_callback_lto
+ 2021-06-30 7d0e9e6e74 image/gif: fix typo in the comment (io.ReadByte -> io.ByteReader)
+ 2021-06-30 0fa3265fe1 os: change example to avoid deprecated function
+ 2021-06-30 d19a53338f image: add Uniform.RGBA64At and Rectangle.RGBA64At
+ 2021-06-30 c45e800e0c crypto/x509: don't fail on optional auth key id fields
+ 2021-06-29 f9d50953b9 net: fix failure of TestCVE202133195
+ 2021-06-29 e294b8a49e doc/go1.17: fix typo "MacOS" -> "macOS"
+ 2021-06-29 3463852b76 math/big: fix typo of comment (`BytesScanner` to `ByteScanner`)
+ 2021-06-29 fd4b587da3 cmd/compile: suppress details error for invalid variadic argument type
+ 2021-06-29 e2e05af6e1 cmd/internal/obj/arm64: fix an encoding error of CMPW instruction
+ 2021-06-28 4bb0847b08 cmd/compile,runtime: change unsafe.Slice((*T)(nil), 0) to return []T(nil)
+ 2021-06-28 1519271a93 spec: change unsafe.Slice((*T)(nil), 0) to return []T(nil)
+ 2021-06-28 5385e2386b runtime/internal/atomic: drop Cas64 pointer indirection in comments
+ 2021-06-28 956c81bfe6 cmd/go: add GOEXPERIMENT to `go env` output
+ 2021-06-28 a1d27269d6 cmd/go: prep for 'go env' refactoring
+ 2021-06-28 901510ed4e cmd/link/internal/ld: skip the windows ASLR test when CGO_ENABLED=0
+ 2021-06-28 361159c055 cmd/cgo: fix 'see gmp.go' to 'see doc.go'
+ 2021-06-27 c95464f0ea internal/buildcfg: refactor GOEXPERIMENT parsing code somewhat
+ 2021-06-25 ed01ceaf48 runtime/race: use race build tag on syso_test.go
+ 2021-06-25 d1916e5e84 go/types: in TestCheck/issues.src, import regexp/syntax instead of cmd/compile/internal/syntax
+ 2021-06-25 5160896c69 go/types: in TestStdlib, import from source instead of export data
+ 2021-06-25 d01bc571f7 runtime: make ncgocall a global counter
Change-Id: I1ce4a3b3ff7c824c67ad66dd27d9d5f1d25c0023
Created functions to create GC shape type and names, based on a proposal
from Keith. Kept unsigned and signed integer types as different, since
they have different shift operations.
Included adding in alignment fields where padding is
required between fields, even though that seems like it will be fairly
uncommon to use.
Added some extra unusual struct typeparams (for testing the gcshape
names/types) in index.go test.
Change-Id: I8132bbd28098bd933435b8972ac5cc0b39f4c0df
Reviewed-on: https://go-review.googlesource.com/c/go/+/329921
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This CL handles I(x) where I is an interface type and x has
typeparam type.
Change-Id: Ib99de2b741d588947f5e0164255f6365e98acd8a
Reviewed-on: https://go-review.googlesource.com/c/go/+/326189
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
CL 255241 made error message involving variadic calls clearer. To do it,
we added a check that the type of variadic argument must be a slice.
That's why the compiler crashes for invalid variadic argument type.
Instead, we can just omit the details error message, and report not
enough arguments error, which matches the behavior of go/types and types2.
Fixes#46957
Change-Id: I638d7e8f031f0ee344d5d802104fd93a60aae00a
Reviewed-on: https://go-review.googlesource.com/c/go/+/331569
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 removes the unconditional OCHECKNIL check added in
walkUnsafeSlice by instead passing it as a pointer to
runtime.unsafeslice, and hiding the check behind a `len == 0` check.
While here, this CL also implements checkptr functionality for
unsafe.Slice and disallows use of unsafe.Slice with //go:notinheap
types.
Updates #46742.
Change-Id: I743a445ac124304a4d7322a7fe089c4a21b9a655
Reviewed-on: https://go-review.googlesource.com/c/go/+/331070
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Allow fix for issue46725 to work for -G=3 mode.
Change-Id: Id522fbc2278cf878cb3f95b3205a2122c164ae29
Reviewed-on: https://go-review.googlesource.com/c/go/+/331470
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
As walk already create the wrapper if necessary.
With this change, test/inline.go need to be changed to use
errorcheckwithauto, for matching "inlining call to ..." in autogenerated
position for method value wrapper, since when we don't generate the
wrapper immediately during typecheck.
Change-Id: I9ffbec9ad3c2b7295546976e2fa517336c13c89b
Reviewed-on: https://go-review.googlesource.com/c/go/+/330838
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 unified IR to handle creating wrapper methods. There's
relatively little about this code that's actually specific to unified
IR, but rewriting this logic allows a few benefits:
1. It decouples unified IR from reflectdata.methodWrapper, so the
latter code can evolve freely for -G=3's needs. This will also allow
the new code to evolve to unified IR's wrapper needs, which I
anticipate will operate slightly differently.
2. It provided an opportunity to revisit a lot of the code and
simplify/update it to current style. E.g., in the process, I
discovered #46903, which unified IR now gets correctly. (I have not
yet attempted to fix reflectdata.methodWrapper.)
3. It gives a convenient way for unified IR to ensure all of the
wrapper methods it needs are generated correctly.
For now, the wrapper generation is specific to non-quirks mode.
Change-Id: I5798de6b141f29e8eb6a5c563e7049627ff2868a
Reviewed-on: https://go-review.googlesource.com/c/go/+/330569
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>
Conflicts:
- src/go/types/check_test.go
CL 330629 fixed a bug in package qualification logic
- src/internal/buildcfg/exp.go
CL 329930 make parseExperiments get go arch string as input param
Merge List:
+ 2021-06-25 37f9a8f69d go/types: fix a bug in package qualification logic
+ 2021-06-24 c309c89db5 reflect: document that InterfaceData is a low-entropy RNG
+ 2021-06-24 cce621431a cmd/compile: fix wrong type in SSA generation for OSLICE2ARRPTR
+ 2021-06-24 600a2a4ffb cmd/go: don't try to add replaced versions that won't be selected
+ 2021-06-24 a9bb38222a net: remove hard-coded timeout in dialClosedPort test helper
+ 2021-06-24 86d72fa2cb time: handle invalid UTF-8 byte sequences in quote to prevent panic
+ 2021-06-24 44a12e5f33 cmd/go: search breadth-first instead of depth-first for test dependency cycles
+ 2021-06-24 73496e0df0 net: use absDomainName in the Windows lookupPTR test helper
+ 2021-06-24 222ed1b38a os: enable TestFifoEOF on openbsd
+ 2021-06-22 0ebd5a8de0 cmd/go: update ToolTags based on GOARCH value
+ 2021-06-22 5bd09e5efc spec: unsafe.Add/Slice are not permitted in statement context
+ 2021-06-22 666315b4d3 runtime/internal/atomic: remove incorrect pointer indirection in comment
+ 2021-06-22 63daa774b5 go/types: guard against checking instantiation when generics is disabled
+ 2021-06-22 197a5ee2ab cmd/gofmt: remove stale documentation for the -G flag
+ 2021-06-22 9afd158eb2 go/parser: parse an ast.IndexExpr for a[]
+ 2021-06-21 1bd5a20e3c cmd/go: add a -go flag to 'go mod graph'
+ 2021-06-21 761edf71f6 cmd/internal/moddeps: use a temporary directory for GOMODCACHE if needed
+ 2021-06-21 a0400420ad cmd/internal/moddeps: use -mod=readonly instead of -mod=mod
+ 2021-06-21 3f9ec83b10 cmd/go: document GOPPC64 environment variable
+ 2021-06-21 20bdfba325 go/scanner: fall back to next() when encountering 0 bytes in parseIdentifier
+ 2021-06-21 44f9a3566c database/sql: fix deadlock test in prepare statement
Change-Id: I16490e8ea70ee65081f467223857033842da513a
In normal build configurations, we test both -G=0 and -G=3 so that we
can test both typecheck and types2. However, GOEXPERIMENT=unified
always uses types2, so testing both is redundant.
Change-Id: I697d2ad916d8b17cfaf4f0b6b32eec380d4e7906
Reviewed-on: https://go-review.googlesource.com/c/go/+/330755
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Similar to the previous CL to suppress escape analysis diagnostics for
method wrappers, suppress liveness analysis diagnostics too. It's
hardly useful to know that all of a wrapper method's arguments are
live at entry.
Change-Id: I0d1e44552c6334ee3b454adc107430232abcb56a
Reviewed-on: https://go-review.googlesource.com/c/go/+/330749
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>
This is code in progress to generate the two main other types of entries
in dictionaries:
- all types in the instantiated function derived from the type
arguments (which are currently concrete, but will eventually be
gcshapes)
- pointers (i.e. mainly the unique name) to all needed sub-dictionaries
In order to generate these entries, we now generate cached information
gfInfo about generic functions/methods that can be used for creating the
instantiated dictionaries. We use the type substituter to compute the
right type args for instantiated sub-dictionaries.
If infoPrintMode is changed to true, the code prints out all the
information gathered about generic functions, and also the entries in
all the dictionaries that are instantiated. The debug mode also prints
out the locations where we need main dictionaries in non-instantiated
functions.
Other changes:
- Moved the dictionary generation back to stencil.go from reflect.go,
since we need to do extra analysis for the new dictionary entries. In
the process, made getInstantiation generate both the function
instantiation and the associated dictionary.
- Put in small change for now in reflect.go, so that we don't try
generate separate dictionaries for Value[T].get and the
auto-generated (*Value[T]).get. The auto-generated wrapper shouldn't really
need a dictionary.
- Detected, but not handling yet, a new case which needs
dictionaries - closures that have function params or captured
variables whose types are derived from type arguments.
- Added new tests in dictionaryCapture for use of method
value/expressions in generic functions and for mutually recursive
generic functions.
Change-Id: If0cbde8805a9f673a23f5ec798769c85c9c5359b
Reviewed-on: https://go-review.googlesource.com/c/go/+/327311
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This CL changes escape analysis to skip reporting diagnostics (at
least for parameter tagging) for generated wrappers.
We're inconsistent about when/where wrappers are generated, which made
errorcheck tests of escape analysis unnecessarily brittle to changes
in wrapper generation. This CL addresses this making errorcheck tests
only care about tagging of the actual functions themselves, not the
wrappers too.
Change-Id: Ia1a0b9dabee4d4162b05647f871db03b032c945a
Reviewed-on: https://go-review.googlesource.com/c/go/+/330689
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>
- Fix handling of method expressions with embedded fields. Fix an
incorrect lookup for method expressions, which have only the
top-level type (and don't have DOT operations for the embedded
fields). Add the embedded field dot operations into the closure.
- Don't need a dictionary and so don't build a closure if the last
embedded field reached in a method expression is an interface value.
- Fix methodWrapper() to use the computed 'dot' node in the
generic-only part of the code.
- For a method expression, don't create a generic wrapper if the last
embedded field reached before the method lookup is an interface.
Copied cmd/compile/internal/types2/testdata/fixedbugs/issue44688.go2 to
test/typeparam/issue44688.go, made it fully runnable (rather than just
for compilation), and added a bunch more tests.
Change-Id: I90c1aa569e1c7272e986c9d2ae683e553c3a38a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/329550
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
This CL extends escape analysis to analyze function calls using method
expressions the same as it would a normal method call. That is, it now
analyzes "T.M(recv, args...)" the same as "recv.M(args...)".
This is useful because it means the frontend can eventually stop
supporting both function calls and method calls. We can simply desugar
method calls into function calls, like we already do in the backend to
simplify SSA construction.
Change-Id: I9cd5ec0d534cbcd9860f0014c86e4ae416920c26
Reviewed-on: https://go-review.googlesource.com/c/go/+/330331
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>
This CL moves two bits of related code from order.go to escape
analysis:
1. The recognition of "unsafe uintptr" arguments passed to
syscall-like functions.
2. The wrapping of go/defer function calls in parameter-free function
literals.
As with previous CLs, it would be nice to push this logic even further
forward, but for now escape analysis seems most pragmatic.
A couple side benefits:
1. It allows getting rid of the uintptrEscapesHack kludge.
2. When inserting wrappers, we can move some expressions into the
wrapper and escape analyze them better. For example, the test
expectation changes are all due to slice literals in go/defer calls
where the slice is now constructed at the call site, and can now be
stack allocated.
Change-Id: I73679bcad7fa8d61d2fc52d4cea0dc5ff0de8c0c
Reviewed-on: https://go-review.googlesource.com/c/go/+/330330
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>
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>
This ports the fix in CL 328050 for typecheck to types2.
The fix is not identical, due to code structure differences between
typecheck and types2, but the idea is the same. We only do the untyped
conversion when both operands can be mixed.
Updates #46749
Change-Id: Ib2c63ba0d5dd8bf02318b1bfdfe51dcaeeeb7f82
Reviewed-on: https://go-review.googlesource.com/c/go/+/328053
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 Griesemer <gri@golang.org>
This CL changes types2's instance hashing logic to include position
information for function-scope defined types as disambiguation. This
isn't ideal, but it worked for getting nested.go passing.
Updates #46592.
Change-Id: Id83ba0001f44af69b81260306cc8b05e44fc4f09
Reviewed-on: https://go-review.googlesource.com/c/go/+/327170
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
- test/run.go
CL 328050 added fixedbugs/issue46749.go to -G=3 excluded files list
Merge List:
+ 2021-06-16 785a8f677f cmd/compile: better error message for invalid untyped operation
+ 2021-06-16 a752bc0746 syscall: fix TestGroupCleanupUserNamespace test failure on Fedora
+ 2021-06-15 d77f4c0c5c net/http: improve some server docs
+ 2021-06-15 219fe9d547 cmd/go: ignore UTF8 BOM when reading source code
+ 2021-06-15 723f199edd cmd/link: set correct flags in .dynamic for PIE buildmode
+ 2021-06-15 4d2d89ff42 cmd/go, go/build: update docs to use //go:build syntax
+ 2021-06-15 033d885315 doc/go1.17: document go run pkg@version
+ 2021-06-15 ea8612ef42 syscall: disable c-shared test when no cgo, for windows/arm
+ 2021-06-15 abc56fd1a0 internal/bytealg: remove duplicate go:build line
+ 2021-06-15 4061d3463b syscall: rewrite handle inheritance test to use C rather than Powershell
+ 2021-06-15 cf4e3e3d3b reflect: explain why convertible or comparable types may still panic
+ 2021-06-14 7841cb14d9 doc/go1.17: assorted fixes
+ 2021-06-14 8a5a6f46dc debug/elf: don't apply DWARF relocations for ET_EXEC binaries
+ 2021-06-14 9d13f8d43e runtime: update the variable name in comment
+ 2021-06-14 0fd20ed5b6 reflect: use same conversion panic in reflect and runtime
+ 2021-06-14 6bbb0a9d4a cmd/internal/sys: mark windows/arm64 as c-shared-capable
+ 2021-06-14 d4f34f8c63 doc/go1.17: reword "results" in stack trace printing
Change-Id: I60d1f67c4d48cd4093c350fc89bd60c454d23944
For typed vs un-typed operation, the compiler do the conversion
un-conditionally, so if the operation is invalid, the error report is
pointed to the conversion, instead of the invalid operation itself.
To fix this, only do the conversion when the operations are valid
for both types.
Fixes#46749
Change-Id: Ib71c7bcd3ed5454e6df55b6a8db4e0f189259ba7
Reviewed-on: https://go-review.googlesource.com/c/go/+/328050
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>
Two non-conflict changes included because they're needed for all.bash:
1. Bump internal/goversion.Version to 18. This will happen eventually
anyway (dev.typeparams will not be merged back to Go 1.17), and is
needed for cmd/api to allow new API additions.
2. Add fixedbugs/issue46725.go (new test added on master) to the list
of known failures for -G=3. This test exercises a bug that was fixed
in typecheck, but -G=3 mode has duplicated that code and will need to
be fixed as well. That's outside of the scope of a merge.
Conflicts:
- src/runtime/traceback.go
Nearby lines were removed on both master and dev.typeparams.
Merge List:
+ 2021-06-14 fdab5be159 doc/go1.17: further revise OpenBSD release notes
+ 2021-06-14 326ea438bb cmd/compile: rewrite a, b = f() to use temporaries when type not identical
+ 2021-06-14 3249b645c9 cmd/compile: factor out rewrite multi-valued f()
+ 2021-06-13 14305bf0b9 misc/cgo: generate Windows import libraries for clang
+ 2021-06-13 24cff0f044 cmd/go, misc/cgo: skip test if no .edata
+ 2021-06-13 67b1b6a2e3 cmd/compile: allow ir.OSLICE2ARRPTR in mayCall
+ 2021-06-12 1ed0d129e9 runtime: testprogcgo: don't call exported Go functions directly from Go
+ 2021-06-12 9d46ee5ac4 reflect: handle stack-to-register translation in callMethod
+ 2021-06-11 e552a6d312 cmd/go: remove hint when no module is suggested
+ 2021-06-11 16b5d766d8 syscall: do not load native libraries on non-native powershell on arm
+ 2021-06-11 77aa209b38 runtime: loop on EINTR in macOS sigNoteSleep
+ 2021-06-11 e2dc6dd5c9 doc/go1.17: clean up formatting of gofmt section
+ 2021-06-11 2f1128461d cmd/go: match Windows paths in TestScript/mod_invalid_version
+ 2021-06-11 2721da2608 doc/go1.17: fix formatting near httptest
+ 2021-06-10 770f1de8c5 net/http: remove test-only private key from production binaries
+ 2021-06-10 8d11b1d117 cmd/go: report the imports of CompiledGoFiles in ImportMap
+ 2021-06-10 dc00dc6c6b crypto/tls: let HTTP/1.1 clients connect to servers with NextProtos "h2"
+ 2021-06-09 27f83723e9 api: promote next to go1.17
+ 2021-06-09 182157c81a doc/go1.17: remove lingering TODO
+ 2021-06-09 a5bc060b42 doc/go1.17: document strconv changes for Go 1.17
+ 2021-06-09 1402b27d46 strconv: document parsing of leading +/-
+ 2021-06-09 df35ade067 doc/go1.17: document //go:build lines
+ 2021-06-09 e4e7807d24 net/http: add AllowQuerySemicolons
+ 2021-06-09 ec3026d032 doc/go1.17: remove TODO for ports section
+ 2021-06-09 e6dda19888 net/url: reject query values with semicolons
+ 2021-06-09 139e935d3c math/big: comment division
+ 2021-06-09 aa5540cd82 cmd/compile: make map.zero symbol content-addressable
+ 2021-06-09 07ca28d529 cmd/link: fix bug in -strictdups checking of BSS symbols
+ 2021-06-08 bcecae2af6 doc/go1.17: mention new possibility of type conversion panicking
+ 2021-06-08 63dcab2e91 doc/go1.17: mention new vet checks sigchanyzer and stdmethods.
+ 2021-06-08 6551763a60 doc/go1.17: mention block profile bias fix
+ 2021-06-08 cb80937bf6 Revert "doc/go1.17: mention block profile bias fix"
+ 2021-06-08 d3e3d03666 net: reject leading zeros in IP address parsers
+ 2021-06-08 da4a640141 doc/go1.17: revise OpenBSD release notes
+ 2021-06-08 689f4c7415 doc/go1.17: mention block profile bias fix
+ 2021-06-08 9afe071c60 doc/go1.17: remove TODO for Tools section
+ 2021-06-08 f753d7223e doc/go1.17: resolve TODO for cmd/cover
+ 2021-06-08 9498b0155d cmd/go: in Go 1.17+ modules, add indirect go.mod dependencies separately from direct ones
+ 2021-06-08 949f00cebe doc/go1.17: add release notes for crypto packages
+ 2021-06-08 0fb3e2c184 doc/go1.17: add a release note for the '-compat' flag to 'go mod tidy'
+ 2021-06-08 2169deb352 cmd/compile: use t.AllMethods when sorting typesByString
+ 2021-06-08 c20bcb6488 runtime: remove out-of-date comments about frame skipping
+ 2021-06-07 39c39ae52f doc: document Go 1.17 language changes
+ 2021-06-07 dc8b558951 cmd/dist: pass -Wno-lto-type-mismatch in swig_callback_lto
+ 2021-06-07 909dd5e010 strconv: ParseFloat: always return ErrSyntax for bad syntax
Change-Id: Iffdf379d0275bbd12d50149ce38634773ced481d
If any of the LHS expressions of an OAS2FUNC are not identical to the
respective function call results, escape analysis mishandles the
implicit conversion, causes memory corruption.
Instead, we should insert autotmps like we already do for f(g()) calls
and return g() statements.
Fixes#46725
Change-Id: I71a08da0bf1a03d09a023da5b6f78fb37a4a4690
Reviewed-on: https://go-review.googlesource.com/c/go/+/327651
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>
CL 301650 adds conversion from slice to array ptr. The conversion
expression may appear as argument to a function call, so it will be
tested by mayCall. But ir.OSLICE2ARRPTR op is not handled by mayCall,
causes the compiler crashes.
Updates #395Fixes#46720
Change-Id: I39e1b3e38e224a31f3dec46dbbdc855ff3b2c6a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/327649
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
This CL copies go/build's splitQuoted function (used for parsing #cgo
directives within `import "C"` preambles) to parse test recipe
commands. In particular, this now allows writing "build" and "run"
tests that use -gcflags to pass multiple compiler flags.
Change-Id: I0d18a9c13a4ce24bbdfa1da8662c0498c93a6762
Reviewed-on: https://go-review.googlesource.com/c/go/+/327275
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>
The compiler machinery that generates "map.zero" symbols marks them as
RODATA and DUPOK, which is problematic when a given application has
multiple map zero symbols (from different packages) with varying
sizes: the dupok path in the loader assumes that if two symbols have
the same name, it is safe to pick any of the versions. In the case of
map.zero, the link needs to select the largest symbol, not an
arbitrary sym.
To fix this problem, mark map.zero symbols as content-addressable,
since the loader's content addressability processing path already
supports selection of the larger symbol in cases where there are dups.
Fixes#46653.
Change-Id: Iabd2feef01d448670ba795c7eaddc48c191ea276
Reviewed-on: https://go-review.googlesource.com/c/go/+/326211
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Hardwire regabidefers to true. Remove it from GOEXPERIMENTs.
Fallback paths are not cleaned up in this CL. That will be done
in later CLs.
Change-Id: Iec1112a1e55d5f6ef70232a5ff6e702f649071c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/325913
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
For interface types, t.Methods contains only unexpanded method set, i.e
exclusive of interface embedding. Thus, we can't use it to detect an
interface contains embedding empty interface, like in:
type EI interface{}
func f() interface{ EI } {
return nil
}
At the time we generate runtime types, we want to check against the full
method set of interface instead.
Fixes#46386
Change-Id: Idff53ad39276be6632eb5932b76e855c15cbdd2e
Reviewed-on: https://go-review.googlesource.com/c/go/+/323649
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 converting from a type param to an interface, allow it if
the type bound implements that interface.
Query: some conversions go through this path, some use another path?
The test does
var i interface{foo()int} = x
but
i := (interface{foo()int})(x)
works at tip.
Change-Id: I84d497e5228c0e1d1c9d76ffebaedce09dc45e8e
Reviewed-on: https://go-review.googlesource.com/c/go/+/325409
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
The instantiated functions are created in the source package of the
generic function, so all lookups of symbols should be relative to that
package, so all symbols are consistently in the source package.
Fixes#46575
Change-Id: Iba67b2ba8014a630c5d4e032c0f2f2fbaaedce65
Reviewed-on: https://go-review.googlesource.com/c/go/+/325529
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
There's no outer function in these cases, so we won't be reading
the dictionary as a subdictionary from the outer scope's dictionary.
It will always be a compile-time constant.
Change-Id: I754b126652a6ffb62255734d53fcec29d77cfa9e
Reviewed-on: https://go-review.googlesource.com/c/go/+/324949
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
Change markType to scan generic types and methods, so that inlineable
functions inside generic functions/methods will be properly marked for
export, which means inlining inside instantiated functions will work
correctly.
Also, fix handling of closures for instantiated functions. Some code
needs to be adjusted, since instantiated functions/methods are compiled
as if in the package of the source generic function/type, rather than in
the local package. When we create the closure struct, we want to make
sure that the .F field has the same package as the other fields for the
closure variables. Also, we need to disable a check in tcCompLit() when
being done for an instantiated function, since fields of the closure
struct will be from the source package, not the local package.
Re-enabled part of the orderedmapsimp test that was disabled because of
these issues.
Change-Id: Ic4dba8917da0a36b17c0bdb69d6d6edfdf14104a
Reviewed-on: https://go-review.googlesource.com/c/go/+/324331
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Previously, live.go is conditioned on not using regabidefers. Now
we have regabidefers enabled by default everywhere, and we may
remove the fallback path in the near future, test that
configuration instead.
Change-Id: Idf910aee323bdd6478bc7a2062b2052d82ce003f
Reviewed-on: https://go-review.googlesource.com/c/go/+/325111
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
When compiling runtime, we don't allow closures to escape,
because we don't want (implicit) allocations to occur when it is
not okay to allocate (e.g. in the allocator itself). However, for
go statement, it already allocates a new goroutine anyway. It is
okay to allocate the closure. Allow it.
Also include the closure's name when reporting error.
Updates #40724.
Change-Id: Id7574ed17cc27709609a059c4eaa67ba1c4436dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/325109
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Deal with export/import of recursive generic types. This includes
typeparams which have bounds that reference the typeparam.
There are three main changes:
- Change export/import of typeparams to have an implicit "declaration"
(doDecl). We need to do a declaration of typeparams (via the
typeparam's package and unique name), because it may be referenced
within its bound during its own definition.
- We delay most of the processing of the Instantiate call until we
finish the creation of the top-most type (similar to the way we
delay CheckSize). This is because we can't do the full instantiation
properly until the base type is fully defined (with methods). The
functions delayDoInst() and resumeDoInst() delay and resume the
processing of the instantiations.
- To do the full needed type substitutions for type instantiations
during import, I had to separate out the type subster in stencil.go
and move it to subr.go in the typecheck package. The subster in
stencil.go now does node substitution and makes use of the type
subster to do type substitutions.
Notable other changes:
- In types/builtins.go, put the newly defined typeparam for a union type
(related to use of real/imag, etc.) in the current package, rather
than the builtin package, so exports/imports work properly.
- In types2, allowed NewTypeParam() to be called with a nil bound, and
allow setting the bound later. (Needed to import a typeparam whose
bound refers to the typeparam itself.)
- During import of typeparams in types2 (importer/import.go), we need
to keep an index of the typeparams by their package and unique name
(with id). Use a new map typParamIndex[] for that. Again, this is
needed to deal with typeparams whose bounds refer to the typeparam
itself.
- Added several new tests absdiffimp.go and orderedmapsimp.go. Some of
the orderemapsimp tests are commented out for now, because there are
some issues with closures inside instantiations (relating to unexported
names of closure structs).
- Renamed some typeparams in test value.go to make them all T (to make
typeparam uniqueness is working fine).
Change-Id: Ib47ed9471c19ee8e9fbb34e8506907dad3021e5a
Reviewed-on: https://go-review.googlesource.com/c/go/+/323029
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This CL updates cmd/compile (including types2) and go/types to report
errors about using unsafe.Add and unsafe.Slice when language
compatibility is set to Go 1.16 or older.
Fixes#46525.
Change-Id: I1bfe025a672d9f4b929f443064ad1effd38d0363
Reviewed-on: https://go-review.googlesource.com/c/go/+/324369
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
For debugging.
Change-Id: I5875ccd2413b8ffd2ec97a0ace66b5cae7893b24
Reviewed-on: https://go-review.googlesource.com/c/go/+/324765
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Did a mix of tilde and non-tilde usage. Tilde notation is not quite
fully functional, so no tests are currently trying to distinguish
(fail/not fail) based on tilde usage.
Change-Id: Ib50cec2fc0684f9d9f3561c889fd44c7a7af458c
Reviewed-on: https://go-review.googlesource.com/c/go/+/324572
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
In codegen/arithmetic.go, previously there are MOVD's that match
for loads of arguments. With register ABI there are no more such
loads. Remove the MOVD matches.
Change-Id: I920ee2629c8c04d454f13a0c08e283d3528d9a64
Reviewed-on: https://go-review.googlesource.com/c/go/+/324251
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
A constant will have a TYPEPARAM type if it appears in a place where it
must match that typeparam type (e.g. in a binary operation with a
variable of that typeparam type). If so, then we must write out its
actual constant kind as well, so its constant val can be read in
properly during import.
Fixed some export/import tests which were casting some untyped constants
to avoid this problem.
Change-Id: I285ad8f1c8febbe526769c96e6b27acbd23050f0
Reviewed-on: https://go-review.googlesource.com/c/go/+/324189
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
When converting from a generic function to a concrete implementation,
add a dictionary argument to the generic function (both an actual
argument at each callsite, and a formal argument of each
implementation).
The dictionary argument comes before all other arguments (including
any receiver).
The dictionary argument is checked for validity, but is otherwise unused.
Subsequent CLs will start using the dictionary for, e.g., converting a
value of generic type to interface{}.
Import/export required adding support for LINKSYMOFFSET, which is used
by the dictionary checking code.
Change-Id: I16a7a8d23c7bd6a897e0da87c69f273be9103bd7
Reviewed-on: https://go-review.googlesource.com/c/go/+/323272
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Many compiler tests fail with -G=3 due to changes in error message format.
This commit fixes two of these tests, to ensure I am on the right track in review.
Updates #46447
Change-Id: I138956d536a1d48ca9198e6ddbfde13865bb5dd5
GitHub-Last-Rev: 0ed904b9fa
GitHub-Pull-Request: golang/go#46445
Reviewed-on: https://go-review.googlesource.com/c/go/+/323314
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This CL refactors mkinlcall by extracting the core InlinedCallExpr
construction code into a new "oldInline" function, and adds a new
"NewInline" hook point that can be overriden with a new inliner
implementation that only needs to worry about the details of
constructing the InlinedCallExpr.
It also moves the delayretvars optimization check into CanInline, so
it's performed just once per inlinable function rather than once for
each inlined call.
Finally, it skips printing the function body about to be inlined (and
updates the couple of regress tests that expected this output). We
already report the inline body as it was saved, and this diagnostic is
only applicable to the current inliner, which clones existing function
body instances. In the unified IR inliner, we'll directly construct
inline bodies from the serialized representation.
Change-Id: Ibdbe617da83c07665dcbda402cc8d4d4431dde2f
Reviewed-on: https://go-review.googlesource.com/c/go/+/323290
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
15 more tests are passing from recent changes. 83 still to go.
Change-Id: I155b3e3db966d604ccec8bf3a7c182421f3d26c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/323211
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>
We already have and use FixVariadicCall to normalize non-dotted calls
to variadic functions elsewhere in the compiler to simplify rewriting
of function calls. This CL updates inl.go to use it too.
A couple tests need to be updated to (correctly) expect diagnostics
about "... argument" instead of a slice literal. This is because
inl.go previously failed to set Implicit on the slice literal node.
Change-Id: I76bd79b95ae1f16e3b26ff7e9e1c468f538fd1f0
Reviewed-on: https://go-review.googlesource.com/c/go/+/323009
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
The compiler renames anonymous and blank result parameters to ~rN or
~bN, but the current semantics for computing N are rather annoying and
difficult to reproduce cleanly. They also lead to difficult to read
escape analysis results in tests.
This CL changes N to always be calculated as the parameter's index
within the function's result parameter tuple. E.g., if a function has
a single result, it will now always be named "~r0".
The normative change to this CL is fairly simple, but it requires
updating a lot of test expectations.
Change-Id: I58a3c94de00cb822cb94efe52d115531193c993c
Reviewed-on: https://go-review.googlesource.com/c/go/+/323010
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Always generate (*T).M wrappers for instantiated methods, even when the
instantiated method is being generated for another package (its source
package)
Added new function t.IsInstantiated() to check for fully-instantiated
types (generic type instantiated with concrete types, hence concrete
themselves). This function helps hide the representation of instantiated
types outside of the types package.
Added new export/import test setsimp.go that needs this change.
Change-Id: Ifb700db8c9494e1684c93735edb20f4709be5f7f
Reviewed-on: https://go-review.googlesource.com/c/go/+/322193
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Generic types can the source type of a type alias, so modify g.typ0() to
be able to deal with base generic types.
Added test aliasimp.go that tests aliasing of local generic types and
imported generic types.
Change-Id: I1c398193819d47a36b014cc1f9bb55107e9a565b
Reviewed-on: https://go-review.googlesource.com/c/go/+/322194
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Add union support in types1, and allow exporting of unions, and
importing unions back into types1 and types2.
Added new test mincheck.go/mincheck.dir that tests that type lists (type
sets) are correctly exported/imported, so that types2 gives correct
errors that an instantiation doesn't fit the type list in the type param
constraint.
Change-Id: I8041c6c79289c870a95ed5a1b10e4c1c16985b12
Reviewed-on: https://go-review.googlesource.com/c/go/+/322609
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
In a late change to golang.org/cl/320609, while going back and forth
on the meaning of the boolean result value for "checkFlags", I got one
of the cases wrong. As a result, rather than testing both default
flags and -G=3, we were (redundanly) testing default flags and -G=0.
I ran into this because in my local dev tree, I'm using types2 even
for -G=0, and evidently one of the recent types2 CLs changed the error
message in fixedbugs/issue10975.go. Fortunately, there haven't been
any other regressions despite lacking test coverage.
So this CL cleans things up a bit:
1. Fixes that test to use -lang=go1.17, so types2 reports the old
error message again.
2. Renames "checkFlags" to "validForGLevel" so the boolean result is
harder to get wrong.
3. Removes the blanket deny list of all -m tests, and instead adds the
specific tests that are still failing. This effectively extends -G=3
coverage to another 27 tests that were using -m but already passing,
so we can make sure they don't regress again.
4. Adds a -f flag to force running tests even if they're in the deny
list, to make it easier to test whether they're still failing without
having to edit run.go.
Change-Id: I058d9d90d81a92189e54c6f591d95fb617fede53
Reviewed-on: https://go-review.googlesource.com/c/go/+/322612
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Merge List:
+ 2021-05-25 f22ec51deb doc: add Go 1.17 release note about inlining functions with closures
+ 2021-05-25 8b462d7567 cmd/go: add a -compat flag to 'go mod tidy'
+ 2021-05-24 c89f1224a5 net: verify results from Lookup* are valid domain names
+ 2021-05-24 08a8fa9c47 misc/wasm: ensure correct stack pointer in catch clauses
+ 2021-05-24 32b73ae180 cmd/go: align checks of module path during initialization.
+ 2021-05-24 15d9d4a009 cmd/go: add tests illustrating what happens when Go 1.16 is used in a Go 1.17 main module
+ 2021-05-24 873401df5b cmd/compile: ensure equal functions don't do unaligned loads
+ 2021-05-24 b83610699a cmd/compile: record regabi status in DW_AT_producer
+ 2021-05-24 a22e317220 cmd/compile: always include underlying type for map types
+ 2021-05-24 4356e7e85f runtime: account for spill slots in Windows callback compilation
+ 2021-05-24 52d7033ff6 cmd/go/internal/modload: set the default GoVersion in a single location
+ 2021-05-24 05819bc104 cmd/go/internal/modcmd: factor out a type for flags whose arguments are Go versions
+ 2021-05-22 cca23a7373 cmd/compile: revert CL/316890
+ 2021-05-21 f87194cbd7 doc/go1.17: document changes to net/http package
+ 2021-05-21 217f5dd496 doc: document additional atomic.Value methods
+ 2021-05-21 3c656445f1 cmd/go: in TestScript/mod_replace, download an explicit module path
+ 2021-05-21 76b2d6afed os: document that StartProcess puts files into blocking mode
+ 2021-05-21 e4d7525c3e cmd/dist: display first class port status in json output
+ 2021-05-21 4fb10b2118 cmd/go: in 'go mod download' without args, don't save module zip sums
+ 2021-05-21 4fda54ce3f doc/go1.17: document database/sql changes for Go 1.17
+ 2021-05-21 8876b9bd6a doc/go1.17: document io/fs changes for Go 1.17
+ 2021-05-21 5fee772c87 doc/go1.17: document archive/zip changes for Go 1.17
+ 2021-05-21 3148694f60 cmd/go: remove warning from module deprecation notice printing
+ 2021-05-21 7e63c8b765 runtime: wait for Go runtime to initialize in Windows signal test
+ 2021-05-21 831573cd21 io/fs: added an example for io/fs.WalkDir
+ 2021-05-20 baa934d26d cmd: go get golang.org/x/tools/analysis@49064d23 && go mod vendor
+ 2021-05-20 7c692cc7ea doc/go1.17: document changes to os package
+ 2021-05-20 ce9a3b79d5 crypto/x509: add new FreeBSD 12.2+ trusted certificate folder
+ 2021-05-20 f8be906d74 test: re-enable test on riscv64 now that it supports external linking
+ 2021-05-20 def5360541 doc/go1.17: add release notes for OpenBSD ports
+ 2021-05-20 ef1f52cc38 doc/go1.17: add release note for windows/arm64 port
+ 2021-05-20 bb7495a46d doc/go1.17: document new math constants
+ 2021-05-20 f07e4dae3c syscall: document NewCallback and NewCallbackCDecl limitations
+ 2021-05-20 a8d85918b6 misc/cgo/testplugin: skip TestIssue25756pie on darwin/arm64 builder
+ 2021-05-19 6c1c055d1e cmd/internal/moddeps: use filepath.SkipDir only on directories
+ 2021-05-19 658b5e66ec net: return nil UDPAddr from ReadFromUDP
+ 2021-05-19 15a374d5c1 test: check portable error message on issue46234.go
+ 2021-05-18 eeadce2d87 go/build/constraint: fix parsing of "// +build" (with no args)
+ 2021-05-18 6d2ef2ef2a cmd/compile: don't emit inltree for closure within body of inlined func
+ 2021-05-18 048cb4ceee crypto/x509: remove duplicate import
Change-Id: Ib0442e3555493805f2aa1df26dfd6898df989a37
We have a value typecheck(3) that indicates that a node in a generic
function still needs transformation (via the functions in transform.go).
But it is not very desirable to export/import the value of typecheck(3).
So, I changed the stenciling code to just try to transform all relevant
node types during node copy. Almost all tranform functions were already
idempotent. I only had to add an extra if check before calling
transformAssign() in the OAS case. We still use the typecheck(3) in
noder to determine when higher-nodes have to delay transformation
because one or more of their args are delaying transformation.
Added new test mapsimp.go that required these tranformations after import.
As an additional change, export/import of OINDEX requires exporting the
type using w.exoticType() rather than w.typ(), in order to handle
generic functions. Since generic functions can have pre-transform
operations, the index operation can have a tuple type (multiple return
from a map lookup).
Added printing of imported function bodies in -W=3 debug mode.
Change-Id: I220e2428dc5f2741e91db146f075eb5b6045f451
Reviewed-on: https://go-review.googlesource.com/c/go/+/322191
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
The name substitution for stenciling was incorrectly handling non-local
names. Made changes to explicitly built the vars[] name substitution map
based on the local variables (similar to what inlining substitution
does). Then, we we are stenciling a name node, we do NOT make a copy of
the name node if it is not in vars[], since it is then a reference to an
external name. Added new function localvar() to create the new nodes for
the local variables and put them in the vars[] map.
New test listimp2.go, added missing test calls in list2.go
Change-Id: I8946478250c7bf2bd31c3247089bd50cfeeda0fd
Reviewed-on: https://go-review.googlesource.com/c/go/+/322190
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This is a revert of https://go-review.googlesource.com/c/go/+/316890,
which has positive effects on debugging + DWARF variable locations
for register parameters when the reg abi is in effect, but also
turns out to interact badly with the register allocator.
Fixes#46304.
Change-Id: I624bd980493411a9cde45d44fcd3c46cad796909
Reviewed-on: https://go-review.googlesource.com/c/go/+/321830
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
We want to keep the Nname references for external function references in
tstruct (not remove them, as is currently happening). We only change the
Nname reference (translate it) when it appears in subst.vars[].
New export/import test sliceimp.go which includes some of these external
function references.
Change-Id: Ie3d73bd989a16082f0cebfb566e0a7faeda55e60
Reviewed-on: https://go-review.googlesource.com/c/go/+/321735
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Improvements:
- Fix export/import of the default case of a select statement (was not
dealing with nil Comm case)
- Set properly the name of closure functions in imported generic
functions
Added new test exporting/importing a reasonably large channel package,
chansimp.go.
Change-Id: If2ee12bd749e5df415f48ec4b629a2fa68a79dcb
Reviewed-on: https://go-review.googlesource.com/c/go/+/321734
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
For generic functions, we have to leave the builtins in OCALL form,
rather than transform to specific ops, since we don't know the exact
types involved. Allow export/import of builtins in OCALL form.
Added new export/import test mapimp.go.
Change-Id: I571f8eeaa13b4f69389dbdb9afb6cc61924b9bf2
Reviewed-on: https://go-review.googlesource.com/c/go/+/321750
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Added new test typeparam/factimp.go and changed a bunch of other tests
to test exporting more generic functions and types.
Change-Id: I573d75431cc92482f8f908695cfbc8e84dbb36d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/321749
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
I added constants for the previous export versions, and for the final
generics export version. I also added a const for the current export
version. We can increment the current export version for unstable
changes in dev.typeparams, and eventally set it back to the generics
version (2) before release. Added the same constants in
typecheck/iexport.go, importer/iimport.go, and gcimporter/iimport.go,
must be kept in sync.
Put in the needed conditionals to be able to read old versions.
Added new export/import test listimp.dir.
Change-Id: I166d17d943e07951aa752562e952b067704aeeca
Reviewed-on: https://go-review.googlesource.com/c/go/+/319931
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
The general idea is that we now export/import typeparams, typeparam
lists for generic types and functions, and instantiated types
(instantiations of generic types with either new typeparams or concrete
types).
This changes the export format -- the next CL in the stack adds the
export versions and checks for it in the appropriate places.
We always export/import generic function bodies, using the same code
that we use for exporting/importing the bodies of inlineable functions.
To avoid complicated scoping, we consider all type params as unique and
give them unique names for types1. We therefore include the types2 ids
(subscripts) in the export format and re-create on import. We always
access the same unique types1 typeParam type for the same typeparam
name.
We create fully-instantiated generic types and functions in the original
source package. We do an extra NeedRuntimeType() call to make sure that
the correct DWARF information is written out. We call SetDupOK(true) for
the functions/methods to have the linker automatically drop duplicate
instantiations.
Other miscellaneous details:
- Export/import of typeparam bounds works for methods (but not
typelists) for now, but will change with the typeset changes.
- Added a new types.Instantiate function roughly analogous to the
types2.Instantiate function recently added.
- Always access methods info from the original/base generic type, since
the methods of an instantiated type are not filled in (in types2 or
types1).
- New field OrigSym in types.Type to keep track of base generic type
that instantiated type was based on. We use the generic type's symbol
(OrigSym) as the link, rather than a Type pointer, since we haven't
always created the base type yet when we want to set the link (during
types2 to types1 conversion).
- Added types2.AsTypeParam(), (*types2.TypeParam).SetId()
- New test minimp.dir, which tests use of generic function Min across
packages. Another test stringimp.dir, which also exports a generic
function Stringify across packages, where the type param has a bound
(Stringer) as well. New test pairimp.dir, which tests use of generic
type Pair (with no methods) across packages.
- New test valimp.dir, which tests use of generic type (with methods
and related functions) across packages.
- Modified several other tests (adder.go, settable.go, smallest.go,
stringable.go, struct.go, sum.go) to export their generic
functions/types to show that generic functions/types can be exported
successfully (but this doesn't test import).
Change-Id: Ie61ce9d54a46d368ddc7a76c41399378963bb57f
Reviewed-on: https://go-review.googlesource.com/c/go/+/319930
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Update #36739
Change-Id: I14ab2cd0e29966b9a2f992e8c3bcb415203e63e6
Reviewed-on: https://go-review.googlesource.com/c/go/+/321449
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
When reporting a "cannot import package as init" error, we can't rely
on s.LocalPkgName being non-nil, as the original package's name may
already be nil.
Change-Id: Idec006780f12ee4398501d05a5b2ed13157f88ea
Reviewed-on: https://go-review.googlesource.com/c/go/+/320490
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>
Followup to previous commit that extended test/run.go to run more
tests with -G=3. This CL updates a handful of easy test cases for
types2 compatibility.
Change-Id: I58a6f9ce6f9172d61dc25411536ee489ccb03ae0
Reviewed-on: https://go-review.googlesource.com/c/go/+/320610
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
issue46234.go expects an error output "segmentation violation",
which is UNIX-specific. Check for "nil pointer dereference"
instead, which is emitted by the Go runtime and should work on all
platforms.
Should fix Windows builders.
Change-Id: I3f5a66a687d43cae5eaf6a9e942b877e5a248900
Reviewed-on: https://go-review.googlesource.com/c/go/+/321072
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
This CL expands the current logic for re-running "errorcheck" tests
with -G=3 to run (almost) all regress tests that way. This exposes a
handful of additional failures, so the excluded-files list is expanded
accordingly. (The next CL addresses several of the easy test cases.)
Change-Id: Ia5ce399f225d83e817a046a3bd1a41b9681be3af
Reviewed-on: https://go-review.googlesource.com/c/go/+/320609
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
When inlining functions with closures, ensure that we don't mark the
body of the closure with a src.Pos marker that reflects the inline,
since this will result in the generation of an inltree table for the
closure itself (as opposed to the routine that the func-with-closure
was inlined into).
Fixes#46234.
Change-Id: I348296de6504fc4745d99adab436640f50be299a
Reviewed-on: https://go-review.googlesource.com/c/go/+/320913
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Than McIntosh <thanm@google.com>
Merge List:
+ 2021-05-18 690a8c3fb1 make.bash: fix misuse of continue
+ 2021-05-18 8b0901fd32 doc/go1.17: fix typo "avoding" -> "avoiding"
+ 2021-05-18 5e191f8f48 time: rewrite the documentation for layout strings
+ 2021-05-17 bfe3573d58 go/token: correct the interval notation used in some panic messages
+ 2021-05-17 a2c07a9a1a all: update golang.org/x/net to latest
+ 2021-05-17 b9b2bed893 syscall: some containers may fail syscall.TestSetuidEtc
+ 2021-05-17 b1aff42900 cmd/go: don't print 'go get' deprecation notices in the main module
+ 2021-05-17 bade680867 runtime/cgo: fix crosscall2 on ppc64x
+ 2021-05-15 ce92a2023c cmd/go: error out of 'go mod tidy' if the go version is newer than supported
+ 2021-05-14 02699f810a runtime: mark osyield nosplit on OpenBSD
+ 2021-05-14 3d324f127d net/http: prevent infinite wait during TestMissingStatusNoPanic
+ 2021-05-14 0eb38f2b16 cmd/go/internal/load: override Package.Root in module mode
+ 2021-05-14 a938e52986 cmd/go: fix a portability issue in the cd script command
+ 2021-05-14 d137b74539 cmd/go: fix spacing in help text of -overlay flag
+ 2021-05-14 c925e1546e cmd/internal/obj/arm64: disable AL and NV for some condition operation instructions
+ 2021-05-14 12d383c7c7 debug/macho: fix a typo in macho.go
+ 2021-05-14 3a0453514a all: fix spelling
+ 2021-05-13 b4833f7c06 cmd/link: always mark runtime.unreachableMethod symbol
+ 2021-05-13 92c189f211 cmd/link: resolve ABI alias for runtime.unreachableMethod
+ 2021-05-13 7a7624a3fa cmd/go: permit .tbd files as a linker flag
+ 2021-05-13 cde2d857fe cmd/go: be less strict about go version syntax in dependency go.mod files
+ 2021-05-13 2a61b3c590 regexp: fix repeat of preferred empty match
+ 2021-05-13 fd4631e24f cmd/compile/internal/dwarfgen: fix DWARF param DIE ordering
+ 2021-05-13 a63cded5e4 debug/dwarf: delay array type fixup to handle type cycles
+ 2021-05-13 0fa2302ee5 cmd/vendor: update golang.org/x/sys to latest
+ 2021-05-13 2c76a6f7f8 all: add //go:build lines to assembly files
+ 2021-05-12 6db7480f59 cmd/go/internal/modload: in updateLazyRoots, do not require the main module explicitly
+ 2021-05-12 f93b951f33 cmd/compile/abi-internal.md: fix table format
+ 2021-05-12 3b321a9d12 cmd/compile: add arch-specific inlining for runtime.memmove
+ 2021-05-12 07ff596404 runtime/internal/atomic: add LSE atomics instructions to arm64
+ 2021-05-12 03886707f9 runtime: fix handling of SPWRITE functions in traceback
+ 2021-05-12 e03383a2e2 cmd/link: check mmap error
+ 2021-05-12 af0f8c149e cmd/link: don't cast end address to int32
+ 2021-05-12 485474d204 cmd/go/testdata/script: fix test failing on nocgo builders
+ 2021-05-12 1a0ea1a08b runtime: fix typo in proc.go
+ 2021-05-11 9995c6b50a cmd/go: ignore implicit imports when the -find flag is set
Change-Id: I843fe029b8ac09424a83e8a4e8bdcc86edd40603
We were handling the case where an OFUNCINST node was used as a function
value, but not the case when an OFUNCINST node was used as a method
value. In the case of a method value, we need to create a new selector
expression that references the newly stenciled method.
To make this work, also needed small fix to noder2 code to properly set the
Sel of a method SelectorExpr (should be just the base method name, not
the full method name including the type string). This has to be correct,
so that the function created by MethodValueWrapper() can be typechecked
successfully.
Fixes#45817
Change-Id: I7343e8a0d35fc46b44dfe4d45b77997ba6c8733e
Reviewed-on: https://go-review.googlesource.com/c/go/+/319589
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
This CL add runtime.memmove inlining for AMD64 and ARM64.
According to ssa dump from testcases generic rules can't inline
memmomve properly due to one of the arguments is Phi operation. But this
Phi op will be optimized out by later optimization stages. As a result
memmove can be inlined during arch-specific rules.
The commit add new optimization rules to arch-specific rules that can
inline runtime.memmove if it possible during lowering stage.
Optimization fires 5 times in Go source-code using regabi.
Fixes#41662
Change-Id: Iaffaf4c482d068b5f0683d141863892202cc8824
Reviewed-on: https://go-review.googlesource.com/c/go/+/289151
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: David Chase <drchase@google.com>
These operations (BT{S,R,C}{Q,L}modify) are quite a bit slower than
other ways of doing the same thing.
Without the BTxmodify operations, there are two fallback ways the compiler
performs these operations: AND/OR/XOR operations directly on memory, or
load-BTx-write sequences. The compiler kinda chooses one arbitrarily
depending on rewrite rule application order. Currently, it uses
load-BTx-write for the Const benchmarks and AND/OR/XOR directly to memory
for the non-Const benchmarks. TBD, someone might investigate which of
the two fallback strategies is really better. For now, they are both
better than BTx ops.
name old time/op new time/op delta
BitSet-8 1.09µs ± 2% 0.64µs ± 5% -41.60% (p=0.000 n=9+10)
BitClear-8 1.15µs ± 3% 0.68µs ± 6% -41.00% (p=0.000 n=10+10)
BitToggle-8 1.18µs ± 4% 0.73µs ± 2% -38.36% (p=0.000 n=10+8)
BitSetConst-8 37.0ns ± 7% 25.8ns ± 2% -30.24% (p=0.000 n=10+10)
BitClearConst-8 30.7ns ± 2% 25.0ns ±12% -18.46% (p=0.000 n=10+10)
BitToggleConst-8 36.9ns ± 1% 23.8ns ± 3% -35.46% (p=0.000 n=9+10)
Fixes#45790
Update #45242
Change-Id: Ie33a72dc139f261af82db15d446cd0855afb4e59
Reviewed-on: https://go-review.googlesource.com/c/go/+/318149
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ben Shi <powerman1st@163.com>
This disables the "testing names" for method names and
trailing input types passed to closure/interface/other calls.
The logic using the names remains, so that editing the change
to enable local testing is not too hard.
Also fixes broken build tag in reflect/abi_test.go
Updates #44816.
Change-Id: I3d222d2473c98d04ab6f1122ede9fea70c994af1
Reviewed-on: https://go-review.googlesource.com/c/go/+/300150
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The inlsubst already does the same thing for OLABEL, so we must do the
same thing for OGOTO. Otherwise, new inlined OGOTO node will be
associated with non-existed label.
Fixes#45947
Change-Id: I40eef095f57fd3438c38a0b5d9751d5d7ebf759e
Reviewed-on: https://go-review.googlesource.com/c/go/+/316931
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Dan Scales <danscales@google.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>
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>
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>
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>
In the register allocator, if possible, we allocate a value to its
desired register (the ideal register for its next use). In some
cases the desired register does not satisfies the value's output
register mask. We should not use the register in this case.
In the following example, v33 is going to be returned as a
function result, so it is allocated to its desired register AX.
However, its Op cannot use AX as output, causing miscompilation.
v33 = CMOVQEQF <int> v24 v28 v29 : AX (~R0[int])
v35 = MakeResult <int,int,mem> v33 v26 v18
Ret v35
Change-Id: Id0f4f27c4b233ee297e83077e3c8494fe193e664
Reviewed-on: https://go-review.googlesource.com/c/go/+/314630
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>
In CL 255899, we added code to make clearer error when non-bool used
as operand to logical operators. The code is safe, because node type
is guaranteed to be non-nil.
In CL 279442, we refactored typechecking arith, including moving
typechecking logical operators to separate case. Now we have to
explicitly check if operand type is not nil, because calling Expr can
set operand type nil for non-bool operands.
Fixes#45804
Change-Id: Ie2b6e18f65c0614a803b343f60e78ee1d660bbeb
Reviewed-on: https://go-review.googlesource.com/c/go/+/314209
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>
Ensure that formal parameter Names are correctly copied and marked
with the correct Curfn. We need to ensure this even when the underlying
closure has no type parameters.
(Aside: it is strange that the types of things contain formal
parameter names that need to be copied. Maybe that's an underlying
larger problem that needs to be fixed.)
Fixes#45738
Change-Id: Ia13d69eea992ff7080bd44065115bc52eb624e73
Reviewed-on: https://go-review.googlesource.com/c/go/+/313652
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
The transform functions (specifically transformArgs, which is used from
transformCall/transformReturn) require that ir.CurFunc is set correctly.
Since transformCall() is used on the call of an instantiated generic
function, we need to set ir.CurFunc correctly in stencil(). Also,
correctly save/restore ir.CurFunc in genericSubst().
Without this fix, ir.CurFunc can be nil when we call TransformCall()
from stencil(), which leads to some temp variables being added
incorrectly to ir.TodoFunc (which leads to the fatal panic in the
issue).
Fixes#45722
Change-Id: Iddf4a67d28f2100dde8cde5dbc9ca1e00dad6089
Reviewed-on: https://go-review.googlesource.com/c/go/+/313869
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
It's not a predeclared type, but a type defined in "unsafe" package.
Fixes#44830
Change-Id: If39815b1070059b608be8231dfac9b7f3307cb15
Reviewed-on: https://go-review.googlesource.com/c/go/+/313349
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>
Within clovar, n.Defn can also be *ir.TypeSwitchGuard. The proper fix
here would be to populate m.Defn and have it filled in too, but we
already leave it nil in inlvar. So for consistency, this CL does the
same in clovar too.
Eventually inl.go should be rewritten to fully respect IR invariants.
Fixes#45743.
Change-Id: I8b38e5d8b2329ad242de97670f2141f713954d28
Reviewed-on: https://go-review.googlesource.com/c/go/+/313289
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Trust: Dan Scales <danscales@google.com>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
The previous fix to ensure early evaluation of lvalue-init statements
(CL 312632) added it after we'd already peeled away any array-OINDEX
expressions. But those might have init statements too, so we need to
do this earlier actually and perhaps more than once.
Longer term, lvalue expressions shouldn't have init statements anyway.
But rsc and I both spent a while looking into this earlier in the dev
cycle and couldn't come up with anything reasonable.
Fixes#45706.
Change-Id: I2d19c5ba421b3f019c62eec45774c84cf04b30ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/313011
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
CL 281152 improved ascompatee by removing the call to safeExpr on lhs.
But we forgot that lhs int statements, if any, must be walked prior
saving subexpressions, which cause the bug in #45706.
Fixes#45706
Change-Id: I0064315056ef4ca92ebf3c332c2e3a9bb2b26f68
Reviewed-on: https://go-review.googlesource.com/c/go/+/312632
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>
Currently, when copying definition node of an inlined var, we do not
update var Defn field to point to new copied node. That causes all
inlined vars point to the same Defn, and ir.StaticValue can not find
inlined var in the lhs of its definition.
clovar creates new ONAME node for local variables or params of closure
inside inlined function, by copying most of the old node fields. So the
new Node.Defn is not modified, its lhs still refer to old node
instead of new one.
To fix this, we need to do two things:
- In subst.clovar, set a dummy Defn node for inlvar
- During subst.node, when seeing OAS/OAS2 nodes, after substituting, we
check if any node in lhs has the dummy Defn, then set it to the current
OAS/OAS2 node.
Fixes#45606
Change-Id: Ib517b753a7643756dcd61d36deae60f1a0fc53c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/312630
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 defer wrapping feature added to the compiler's "order" phase
creates temporaries into which it copies defer arguments. If one of
these temps is large enough that we place it into the defer closure by
address (as opposed to by value), then the temp in question can't be
reused later on in the order phase, nor do we want a VARKILL
annotation for it at the end of the current block scope.
Test written by Cherry.
Updates #40724.
Change-Id: Iec7efd87ec5a3e3d7de41cdcc7f39c093ed1e815
Reviewed-on: https://go-review.googlesource.com/c/go/+/312869
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 is a port of CL 312212, CL 312591 (except check_test.go), and
CL 312790 to types2.
Updates #19367.
Updates #40481.
Change-Id: I58ba0b0dad157baba3f82c909d5eb1268b931be4
Reviewed-on: https://go-review.googlesource.com/c/go/+/312511
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
If the address of an auto is used in a Call, we need to keep it,
as we keep the Call itself.
Fixes#45693.
Change-Id: Ie548d6dffc95bf916868a8885d4ab4cf9e86355a
Reviewed-on: https://go-review.googlesource.com/c/go/+/312670
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>
Now that we can set experiments at build time instead of make.bash time,
we can actually write a test for field tracking!
Update #20014
This CL contains a test for the functionality fixed in CL 312069.
Change-Id: I7569a7057bbc7c88ae25ae7bf974b0c8a4e35be8
Reviewed-on: https://go-review.googlesource.com/c/go/+/312217
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This reverts CL 311829, and reenables CL 309330. The issue
should be fixed in the previous CL.
Change-Id: I69db0565c72470a1814f135d8f8ec62c781bfc5a
Reviewed-on: https://go-review.googlesource.com/c/go/+/312094
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Apparently CL 309330 caused the compiler OOMing on some large
input (giant generated switch statement). I don't quite understand
it for now. Disable it for now.
Change-Id: I19c84f3f5e158897bff0b32d6217fcff3c66874d
Reviewed-on: https://go-review.googlesource.com/c/go/+/311829
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>
When creating the temporary for map functions, if the key
contains pointer, we need to create pointer-typed temporary. So
if the temporary is live across a function call, the pointer is
live.
Change-Id: Id6e14ec9def8bc7987f0f8ce8423caf1e3754fcb
Reviewed-on: https://go-review.googlesource.com/c/go/+/311379
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Currently, if we have AX=a and BX=b, and we want to make a call
F(1, a, b), to move arguments into the desired registers it emits
MOVQ AX, CX
MOVL $1, AX // AX=1
MOVQ BX, DX
MOVQ CX, BX // BX=a
MOVQ DX, CX // CX=b
This has a few redundant moves.
This is because we process inputs in order. First, allocate 1 to
AX, which kicks out a (in AX) to CX (a free register at the
moment). Then, allocate a to BX, which kicks out b (in BX) to DX.
Finally, put b to CX.
Notice that if we start with allocating CX=b, then BX=a, AX=1,
we will not have redundant moves. This CL reduces redundant moves
by allocating them in different order: First, for inpouts that are
already in place, keep them there. Then allocate free registers.
Then everything else.
before after
cmd/compile binary size 23703888 23609680
text size 8565899 8533291
(with regabiargs enabled.)
Change-Id: I69e1bdf745f2c90bb791f6d7c45b37384af1e874
Reviewed-on: https://go-review.googlesource.com/c/go/+/311371
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
With defer/go wrapping and register arguments, some liveness info
changed and live.go test was disabled for regabi. This CL adds a
new one for regabi.
Change-Id: I65f03a6ef156366d8b76c62a16251c3e818f4b02
Reviewed-on: https://go-review.googlesource.com/c/go/+/311369
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
CL 256798 added compiler ability to retain only used interface methods,
by generating a mark relocation whenever an interface method is used. To
do that, the compiler needs the current function linker object.
However, for unnamed function "func _()", its linker object is nil,
causes the compiler crashes for code in #45258.
CL 283313 fixed the code in #45258 unintentionally, since when the
compiler now does not walk unnamed functions anymore.
This CL fixes the root issue, by making reflectdata.MarkUsedIfaceMethod
skips unnamed functions, and also adding regression test.
Fixes#45258
Change-Id: I4cbefb0a89d9928f70c00dc8a271cb61cd20a49c
Reviewed-on: https://go-review.googlesource.com/c/go/+/311130
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: Keith Randall <khr@golang.org>
The build.Default context really needs to accurately describe
the default build context. The goexperiment tags being a special
case in the go command violates that rule and is the root cause
of the various try-bot failures blocking the enabling of regabi.
(The cleanups I made in golang.org/x/tools were long overdue
but are not strictly necessary for making regabi work; this CL is.)
Having moved the GOEXPERIMENT parsing into internal/buildcfg,
go/build can now use it to set up build.Default, in the new field
ToolTags, meant to hold toolchain-determined tags (for now,
just the experiments). And at the same time we can remove the
duplication of GOOS and GOARCH defaults.
And then once build.Default is set up accurately, the special case
code in cmd/go itself can be removed, and the special case code
in test/run.go is at least a bit less special.
Change-Id: Ib7394e10aa018e492cb9a83fb8fb9a5011a8c25b
Reviewed-on: https://go-review.googlesource.com/c/go/+/310732
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Currently, run.go sets GOEXPERIMENT build tags based on the
*difference* from the baseline experiment configuration, rather than
the absolute experiment configuration. This differs from cmd/go. As a
result, if we set a baseline configuration and don't override it with
a GOEXPERIMENT setting, run.go won't set any GOEXPERIMENT build tags,
instead of setting the tags corresponding to the baseline
configuration.
Fix this by making compile -V=goexperiment produce the full
GOEXPERIMENT configuration, which run.go can then use to set exactly
the right set of build tags.
For #40724.
Change-Id: Ieda6ea62f1a1fabbe8d749d6d09c198fd5ca8377
Reviewed-on: https://go-review.googlesource.com/c/go/+/310171
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Only complain about missing type; leave it to type-checking
to decide whether "..." is permitted in the first place.
Fixes#43674.
Change-Id: Icbc8f084e364fe3ac16076406a134354219c08d0
Reviewed-on: https://go-review.googlesource.com/c/go/+/310209
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Change-Id: I28a1910890659aaa449ffd2a847cd4ced5a8600d
Reviewed-on: https://go-review.googlesource.com/c/go/+/310211
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Add in some missing global assignment ops to the list of globals ops
that should be traversed to look for generic function instantiations.
The most common other one for global assigments (and the relevant one
for this bug) is OAS2FUNC, but also look at global assigments with
OAS2DOTTYPE, OAS2MAPR, OAS2RECV, and OASOP.
Bonus small fix: get rid of -G=3 case in ir.IsAddressable. Now that we
don't call the old typechecker from noder2, we don't need this -G-3
check anymore.
Fixes#45547.
Change-Id: I75fecec55ea0d6f62e1c2294d4d77447ed9be6ae
Reviewed-on: https://go-review.googlesource.com/c/go/+/310210
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Fixes this failure:
go test cmd/compile/internal/ssa -run TestStmtLines -v
=== RUN TestStmtLines
stmtlines_test.go:115: Saw too many (amd64, > 1%) lines without
statement marks, total=88263, nostmt=1930
('-run TestStmtLines -v' lists failing lines)
The failure has two causes.
One is that the first-line adjuster in code generation was relocating
"first lines" to instructions that would either not have any code generated,
or would have the statment marker removed by a different believed-good heuristic.
The other was that statement boundaries were getting attached to register
values (that with the old ABI were loads from the stack, hence real instructions).
The register values disappear at code generation.
The fixes are to (1) note that certain instructions are not good choices for
"first value" and skip them, and (2) in an expandCalls post-pass, look for
register valued instructions and under appropriate conditions move their
statement marker to a compatible use.
Also updates TestStmtLines to always log the score, for easier comparison of
minor compiler changes.
Updates #40724.
Change-Id: I485573ce900e292d7c44574adb7629cdb4695c3f
Reviewed-on: https://go-review.googlesource.com/c/go/+/309649
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
For OMETHEXPR, the Name in the Selection needs to be properly
linked up to the method declaration. Use the same code we
already have for ODOTMETH and OCALLPART to do that.
Fixes#45503
Change-Id: I7d6f886d606bae6faad8c104f50c177f871d41c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/309831
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Dan Scales <danscales@google.com>
For the new export/import of node types, we were just missing setting
the types of the closure variables (which have the same types as the
captured variables) and the OCLOSURE node itself (which has the same
type as the Func node).
Re-enabled inlining of functions with closures.
Change-Id: I687149b061f3ffeec3244ff02dc6e946659077a9
Reviewed-on: https://go-review.googlesource.com/c/go/+/308974
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Some codegen tests were written with the assumption that
arguments and results are in memory, and with a specific stack
layout. With the register ABI, the assumption is no longer true.
Adjust the tests to work with both cases.
- For tests expecting in memory arguments/results, change to use
global variables or memory-assigned argument/results.
- Allow more registers. E.g. some tests expecting register names
contain only letters (e.g. AX), but it can also contain numbers
(e.g. R10).
- Some instruction selection changes when operate on register vs.
memory, e.g. ADDQ vs. LEAQ, MOVB vs. MOVL. Accept both.
TODO: mathbits.go and memops.go still need fix.
Change-Id: Ic5932b4b5dd3f5d30ed078d296476b641420c4c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/309335
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
If GOEXPERIMENT environment variable is unset, use the default
value that is baked into the toolchain (instead of no
experiments).
Change-Id: I41f863e6f7439f2d53e3ebd25a7d9cf4a176e32e
Reviewed-on: https://go-review.googlesource.com/c/go/+/309333
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>
Include type information on exported function bodies, so that the
importer does not have to re-typecheck the body. This involves
including type information in the encoded output, as well as
avoiding some of the opcode rewriting and other changes that the
old exporter did assuming there would be a re-typechecking pass.
This CL could be considered a cleanup, but is more important than that
because it is an enabling change for generics. Without this CL, we'd
have to upgrade the current typechecker to understand generics. With
this CL, the current typechecker can mostly go away in favor of the
types2 typechecker.
For now, inlining of functions that contain closures is turned off.
We will hopefully resolve this before freeze.
Object files are only 0.07% bigger.
Change-Id: I85c9da09f66bfdc910dc3e26abb2613a1831634d
Reviewed-on: https://go-review.googlesource.com/c/go/+/301291
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
A quick check of the source to run.go suggests that it does not
look for the new-style build tags.
Updates #45465.
Change-Id: Ib4be040935d71e732f81d52c4a22c2b514195f40
Reviewed-on: https://go-review.googlesource.com/c/go/+/308934
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: David Chase <drchase@google.com>
This tickles some other bug, do this to clear builders.
Updates #40724.
Updates #45465.
Change-Id: Id51efbcf474865da231fcbc6216e5d604f99c296
Reviewed-on: https://go-review.googlesource.com/c/go/+/308889
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
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>
The helper function used by the compiler's walk phase to determine
whether a param can be passed in a single float register wasn't quite
correct (didn't allow for the possibility of struct with two fields,
first zero size and second float). Fix up the helper to take this
case into account.
Updates #40724.
Change-Id: I55b42a1b17ea86de1d696788f029ad3aae4a179c
Reviewed-on: https://go-review.googlesource.com/c/go/+/308689
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The function runtime.convT64 accepts a single uint64 argument, but the
compiler's rules in the walk phase for determining whether is it ok to
pass a value of type T to a call to runtime.convT64 were slightly off.
In particular the test was allowing a type T with size less than eight
bytes but with more than one internal element (e.g. a struct). This
patch tightens up the rules somewhat to prevent this from happening.
Updates #40724.
Change-Id: I3b909267534db59429b0aa73a3d73333e1bd6432
Reviewed-on: https://go-review.googlesource.com/c/go/+/308069
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>
go.mod file was not tidy, made builders sad.
Updates #40724.
Change-Id: I28371a1093108f9ec473eb20bb4d185e35dee67d
Reviewed-on: https://go-review.googlesource.com/c/go/+/308590
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
In expand_calls, OpSelectN occurs both before and after the rewriting.
Attempting to rewrite a post-expansion OpSelectN is bad.
(The only ones rewritten in place are the ones returning mem;
others are synthesized to replace other selection chains with
register references.)
Updates #40724.
Updates #44816#issuecomment-815258897.
Change-Id: I7b6022cfb47f808d3ce6cc796c067245f36047f3
Reviewed-on: https://go-review.googlesource.com/c/go/+/308309
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
There's a problem in liveness, where liveness of any
part of an aggregate keeps the whole aggregate alive,
but the not-live parts don't get spilled. The GC
can observe those live-but-not-spilled slots, which
can contain junk.
A better fix is to change liveness to work
pointer-by-pointer, but that is also a riskier,
trickier fix.
To avoid this, in the case of
(1) an aggregate input parameter
(2) containing pointers
(3) passed in registers
pre-spill the pointers.
Updates #40724.
Change-Id: I6beb8e0a353b1ae3c68c16072f56698061922c04
Reviewed-on: https://go-review.googlesource.com/c/go/+/307909
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@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>
When a function panics then recovers, it needs to return to the
caller with named results having the correct values. For
in-register results, we need to load them into registers at the
defer return path.
For non-open-coded defers, we already generate correct code, as
the defer return path is part of the SSA CFG and contains the
instructions that are the same as an ordinary return statement,
including putting the results to the right places.
For open-coded defers, we have a special code generation that
emits a disconnected block that currently contains only the
deferreturn call and a RET instruction. It leaves the result
registers unset. This CL adds instructions that load the result
registers on that path.
Updates #40724.
Change-Id: I1f60514da644fd5fb4b4871a1153c62f42927282
Reviewed-on: https://go-review.googlesource.com/c/go/+/307231
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Austin Clements <austin@google.com>
The exact same test case covered by this file is also in
fixedbugs/bug121.go. No need for duplication.
Also, the actual syntax error tested (multiple method names
with a single signature) is an unlikely syntax error, and
only here for historical reasons (in the very beginning, this
was actually possible to write). Now, virtually nobody is making
this mistake.
Change-Id: I9d68e0aee2a63025f44e6338647f8250ecc3077a
Reviewed-on: https://go-review.googlesource.com/c/go/+/307789
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This fixes a compile crash for
GOEXPERIMENT=regabi,regabiargs go test -c go/constant
Updates #40724.
Change-Id: I238cef436e045647815326fc8fdb025c30ba1f5c
Reviewed-on: https://go-review.googlesource.com/c/go/+/307309
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>
Update references missed in CL 263142.
For #41190
Change-Id: I778760a6a69bd0440fec0848bdef539c9ccb4ee1
GitHub-Last-Rev: dda42b09ff
GitHub-Pull-Request: golang/go#42874
Reviewed-on: https://go-review.googlesource.com/c/go/+/273946
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Cherry Zhang <cherryyz@google.com>
Leftover values that have been replaced can cause problems in later
passes (within expandCalls). For example, a struct select that
itself yields a struct will have a problematic rewrite, if the chance
is presented.
Updates #40724.
Change-Id: I1b445c47c301c3705f7fc0a9d39f1f5c84f4e190
Reviewed-on: https://go-review.googlesource.com/c/go/+/306869
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>
Reviewed-by: Than McIntosh <thanm@google.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>
Includes test.
Long term, need to make the offending code be more in terms
of official types package offsets, instead of duplicating that
logic.
For #40724.
Change-Id: Id33a153f10aed3289cc48d1f99a8e0f6ece9474d
Reviewed-on: https://go-review.googlesource.com/c/go/+/306469
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
For in-register arguments, it must have only a single copy of it
present in the function. If there are multiple copies, it confuses
the register allocator, as they are in the same register.
Change-Id: I55cb06746f08aa7c9168026d0f411bce0a9f93f4
Reviewed-on: https://go-review.googlesource.com/c/go/+/306330
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>
During substitution of the function type during stenciling, we must set
the Name nodes of the param/result fields of the func type. We get those
name nodes from the substituted Dcl nodes of the PPARAMS and PPARAMOUTs.
But we must check that the names match with the Dcl nodes, so that we
skip any param fields that correspond to unnamed (in) parameters.
Added a few tests to typelist.go by removing a variety of unneeded
function parameter names.
Change-Id: If786961b64549da6f18eeeb5060ea58fab874eb9
Reviewed-on: https://go-review.googlesource.com/c/go/+/305912
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
In expand_calls, when rewriting OpArg to OpArgIntReg/OpArgFloatReg,
avoid generating duplicates. Otherwise it will confuse the
register allocator: it would think the second occurance clobbers
the first's register, causing it to generate copies, which may
clobber other args.
Change-Id: I4f1dc0519afb77500eae1c0e6ac8745e51f7aa4e
Reviewed-on: https://go-review.googlesource.com/c/go/+/306029
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: David Chase <drchase@google.com>
Handle the case where types can be partially inferred for an
instantiated function that is not immediately called. The key for the
Inferred map is the CallExpr (if inferring types required the function
arguments) or the IndexExpr (if types could be inferred without the
function arguments).
Added new tests for the case where the function isn't immediately called
to typelist.go.
Change-Id: I60f503ad67cd192da2f2002060229efd4930dc39
Reviewed-on: https://go-review.googlesource.com/c/go/+/305909
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Dan Scales <danscales@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
The correct setting of t.nod is needed when exporting types. Make sure
we create instantiated named types correctly so t.nod is set.
New test file interfacearg.go that tests this (by instantiating a type
with an interface). Also has tests for various kinds of method
expressions.
Change-Id: Ia7fd9debd495336b73788af9e35d72331bb7d2b5
Reviewed-on: https://go-review.googlesource.com/c/go/+/305730
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Fix various small bugs related to delaying transformations due to type
params. Most of these relate to the need to delay a transformation when
an argument of an expression or statement has a type parameter that has
a structural constraint. The structural constraint implies the operation
should work, but the transformation can't happen until the actual value
of the type parameter is known.
- delay transformations for send statements and return statements if
any args/values have type params.
- similarly, delay transformation of a call where the function arg has
type parameters. This is mainly important for the case where the
function arg is a pure type parameter, but has a structural
constraint that requires it to be a function. Move the setting of
n.Use to transformCall(), since we may not know how many return
values there are until then, if the function arg is a type parameter.
- set the type of unary expressions from the type2 type (as we do with
most other expressions), since that works better with expressions
with type params.
- deal with these delayed transformations in subster.node() and convert
the CALL checks to a switch statement.
- make sure ir.CurFunc is set properly during stenciling, including
closures (needed for transforming return statements during
stenciling).
New test file typelist.go with tests for these cases.
Change-Id: I1b82f949d8cec47d906429209e846f4ebc8ec85e
Reviewed-on: https://go-review.googlesource.com/c/go/+/305729
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
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>
Adds code to the compiler's "order" phase to rewrite go and defer
statements to always be argument-less. E.g.
defer f(x,y) => x1, y1 := x, y
defer func() { f(x1, y1) }
This transformation is not beneficial on its own, but it helps
simplify runtime defer handling for the new register ABI (when
invoking deferred functions on the panic path, the runtime doesn't
need to manage the complexity of determining which args to pass in
register vs memory).
This feature is currently enabled by default if GOEXPERIMENT=regabi or
GOEXPERIMENT=regabidefer is in effect.
Included in this CL are some workarounds in the runtime to insure that
"go" statement targets in the runtime are argument-less already (since
wrapping them can potentially introduce heap-allocated closures, which
are currently not allowed). The expectation is that these workarounds
will be temporary, and can go away once we either A) change the rules
about heap-allocated closures, or B) implement some other scheme for
handling go statements.
Change-Id: I01060d79a6b140c6f0838d6e6813f807ccdca319
Reviewed-on: https://go-review.googlesource.com/c/go/+/298669
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>
Reviewed-by: David Chase <drchase@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>
For additions, compares, and slices, create transform functions that do
just the transformations for those nodes by the typecheck package (given
that the code has been fully typechecked by types2). For nodes that have
no args with typeparams, we call these transform functions directly in
noder2. But for nodes that have args with typeparams, we have to delay
and call the tranform functions during stenciling, since we don't know
the specific types involved.
We indicate that a node still needs transformation by setting Typecheck
to a new value 3. This value means the current type of the node has been
set (via types2), but the node may still need transformation.
Had to export typcheck.IsCmp and typecheck.Assignop from the typecheck
package.
Added new tests list2.go (required delaying compare typecheck/transform
because of != compare in checkList) and adder.go (requires delaying add
typecheck/transform, since it can do addition for numbers or strings).
There are several more transformation functions needed for expressions
(indexing, calls, etc.) and several more complicated ones needed for
statements (mainly various kinds of assignments).
Change-Id: I7d89d13a4108308ea0304a4b815ab60b40c59b0a
Reviewed-on: https://go-review.googlesource.com/c/go/+/303091
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Optimize some patterns into rev16/rev16w instruction.
Pattern1:
(c & 0xff00ff00)>>8 | (c & 0x00ff00ff)<<8
To:
rev16w c
Pattern2:
(c & 0xff00ff00ff00ff00)>>8 | (c & 0x00ff00ff00ff00ff)<<8
To:
rev16 c
This patch is a copy of CL 239637, contributed by Alice Xu(dianhong.xu@arm.com).
Change-Id: I96936c1db87618bc1903c04221c7e9b2779455b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/268377
Trust: fannie zhang <Fannie.Zhang@arm.com>
Run-TryBot: fannie zhang <Fannie.Zhang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
When -clobberdeadreg flag is set, the compiler inserts code that
clobbers integer registers at call sites. This may be helpful for
debugging register ABI.
Only implemented on AMD64 for now.
Change-Id: Ia203d3f891c30fd95d0103489056fe01d63a2899
Reviewed-on: https://go-review.googlesource.com/c/go/+/302809
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>
types2 will give us a constant with a type T, if an untyped constant is
used with another operand of type T (in a provably correct way). When we
substitute in the type args during stenciling, we now know the real type
of the constant. We may then need to change the BasicLit.val to be the
correct type (e.g. convert an int64Val constant to a floatVal constant).
Otherwise, later parts of the compiler will be confused.
Updated tests list.go and double.go with uses of untyped constants.
Change-Id: I9966bbb0dea3a7de1c5a6420f8ad8af9ca84a33e
Reviewed-on: https://go-review.googlesource.com/c/go/+/303089
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
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>
Currently, the nosplit test disables ABI wrapper generation because it
generates a main.main in assembly, and so the ABI wrapper for calling
from runtime.main to main.main counts against the nosplit limit, which
cases some of the tests to fail.
Fix this by first entering ABI0 in a splittable context and then
calling from there into the test entry point, since this doesn't
introduce an ABI wrapper.
While we're here, this CL removes the test's check for the
framepointer experiment. That's now statically enabled, so it doesn't
appear in the experiment line, and enabling any other experiment
causes the test to think that the framepointer experiment *isn't*
enabled.
For #40724.
Change-Id: I6291eb9391f129779e726c5fc8c41b7b4a14eeb9
Reviewed-on: https://go-review.googlesource.com/c/go/+/302772
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
This CL adds rewrite rules for CSETM, CSINC, CSINV, and CSNEG. By adding
these rules, we can save one instruction.
For example,
func test(cond bool, a int) int {
if cond {
a++
}
return a
}
Before:
MOVD "".a+8(RSP), R0
ADD $1, R0, R1
MOVBU "".cond(RSP), R2
CMPW $0, R2
CSEL NE, R1, R0, R0
After:
MOVBU "".cond(RSP), R0
CMPW $0, R0
MOVD "".a+8(RSP), R0
CSINC EQ, R0, R0, R0
This patch is a copy of CL 285694. Co-authored-by: JunchenLi
<junchen.li@arm.com>
Change-Id: Ic1a79e8b8ece409b533becfcb7950f11e7b76f24
Reviewed-on: https://go-review.googlesource.com/c/go/+/302231
Trust: fannie zhang <Fannie.Zhang@arm.com>
Run-TryBot: fannie zhang <Fannie.Zhang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
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>
This CL resurrects the clobberdead debugging mode (CL 23924).
When -clobberdead flag is set (TODO: make it GOEXPERIMENT?), the
compiler inserts code that clobbers all dead stack slots that
contains pointers.
Mark windows syscall functions cgo_unsafe_args, as the code
actually does that, by taking the address of one argument and
passing it to cgocall.
Change-Id: Ie09a015f4bd14ae6053cc707866e30ae509b9d6f
Reviewed-on: https://go-review.googlesource.com/c/go/+/301791
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
For Builtin ops, we currently stay with using the old
typechecker to transform the call to a more specific expression
and possibly use more specific ops. However, for a bunch of the
ops, we delay calling the old typechecker if any of the args have
type params, for a variety of reasons.
In the near future, we will start creating separate functions that do
the same transformations as the old typechecker for calls, builtins,
indexing, comparisons, etc. These functions can then be called at noder
time for nodes with no type params, and at stenciling time for nodes
with type params.
Remove unnecessary calls to types1 typechecker for most kinds of
statements (still need it for SendStmt, AssignStmt, ReturnStmt, and
SelectStmt). In particular, we don't need it for RangeStmt, and this
avoids some complaints by the types1 typechecker on generic code.
Other small changes:
- Fix check on whether to delay calling types1-typechecker on type
conversions. Should check if HasTParam is true, rather than if the
type is directly a TYPEPARAM.
- Don't call types1-typechecker on an indexing operation if the left
operand has a typeparam in its type and is not obviously a TMAP,
TSLICE, or TARRAY. As above, we will eventually have to create a new
function that can do the required transformations (for complicated
cases) at noder time or stenciling time.
- Copy n.BuiltinOp in subster.node()
- The complex arithmetic example in absdiff.go now works.
- Added new tests double.go and append.go
- Added new example with a new() call in settable.go
Change-Id: I8f377afb6126cab1826bd3c2732aa8cdf1f7e0b4
Reviewed-on: https://go-review.googlesource.com/c/go/+/301951
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Code generation for open defers failed to account for
presence of method receiver and thus was OFF BY ONE.
Fixes#45062.
Updates #44816.
Updates #40724.
Change-Id: Ia90ea8fd0f7d823e1f757c406f9127136c2ffdd2
Reviewed-on: https://go-review.googlesource.com/c/go/+/302249
Trust: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Repair of CL 300749.
ALSO:
found evidence that stack maps for bodyless methods are wrong.
gofmt in test/abi
removed never-executed code in types/size.go
Updates #44816.
Updates #40724.
Change-Id: Ifeb5fee60f60e7c7b58ee0457f58a3265d6cf3f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/302071
Trust: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Ignore an embedded type in an interface which is the predeclared
interface "comparable" (which currently can only be in a type
constraint), since the name doesn't resolve and the "comparable" type
doesn't have any relevant methods (for the purposes of the compiler).
Added new test case graph.go that needs this fix.
Change-Id: I2443d2c3dfeb9d0a78aaaaf91a2808ae2759d247
Reviewed-on: https://go-review.googlesource.com/c/go/+/301831
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This reverts commit 8ed438c077, CL 300749.
Reason for revert: Looks like it crashes on link-register architectures
Change-Id: I0c261df58900008cada3359889d2a87508158447
Reviewed-on: https://go-review.googlesource.com/c/go/+/302053
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
ALSO:
found evidence that stack maps for bodyless methods are wrong.
gofmt in test/abi
removed never-executed code in types/size.go
Updates #44816.
Change-Id: I658c33f049337fb6f1e625f0c55430d25bfa877e
Reviewed-on: https://go-review.googlesource.com/c/go/+/300749
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>
Added test example orderedmap.go (binary search tree) that requires this
fix (calling function compare in _Map).
Also added new tests slices.go and metrics.go that just work.
Change-Id: Ifa5f42ab6eee9aa54c40f0eca19e00a87f8f608a
Reviewed-on: https://go-review.googlesource.com/c/go/+/301829
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Add support for maps in subster.typ(). Add new test cases maps.go and set.go.
Change substitution of a TFUNC in subster.typ() to always create new
param and result structs if any of the receiver, param, or result
structs get substituted. All these func structs must be copied, because
they have offset fields that are dependent, and so must have an
independent copy for each new signature (else there will be an error
later when frame offsets are calculated).
Change-Id: I576942a62f06b46b6f005abc98f65533008de8dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/301670
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Add support for channels in subster.typ(). Add new test file chans.go.
To support assignability of bidirectional channel args to directional
channel params, I needed to type check generic calls after they are
instantiated. (Eventually, we will create separate functions to just do
the assignability logic, so we don't need to call the old typechecker in
this case.) So, for generic calls, we now leave the call as OCALL (as a
signal that the call still needs typechecking), and do typecheck.Call()
during stenciling.
Smaller changes:
- Set the type of an instantiated OCLOSURE node (and not just the associated
OFUNC node)
- In instTypeName2, filter out the space that types2.TypeString inserts
after a common in a typelist. Our standard naming requires no space
after the comma.
- With the assignability fix above, I no longer need the explicit
conversions in cons.go.
Change-Id: I148858bfc6708c0aa3f50bad7debce2b8c8c091f
Reviewed-on: https://go-review.googlesource.com/c/go/+/301669
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This is enabled with a ridiculous magic name for method,
or for last input type passed, that needs to be changed
to something inutterable before actual release.
Ridiculous method name: MagicMethodNameForTestingRegisterABI
Ridiculous last (input) type name: MagicLastTypeNameForTestingRegisterABI
RLTN is tested with strings.Contains, so you can have
MagicLastTypeNameForTestingRegisterABI1
and
MagicLastTypeNameForTestingRegisterABI2
if that is helpful
Includes test test/abi/fibish2.go
Updates #44816.
Change-Id: I592a6edc71ca9bebdd1d00e24edee1ceebb3e43f
Reviewed-on: https://go-review.googlesource.com/c/go/+/299410
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>
Simple change to avoid calling the old typechecker in noder.Addr(). This
fixes cases where generic code calls a pointer method with a non-pointer
receiver.
Added test typeparam/lockable.go that now works with this change.
For lockable.go to work, also fix incorrect check to decide whether to
translate an OXDOT now or later. We should delay translating an OXDOT
until instantiation (because we don't know how embedding, etc. will
work) if the receiver has any typeparam, not just if the receiver type
is a simple typeparam. We also have to handle OXDOT for now in
IsAddressable(), until we can remove calls to the old typechecker in
(*irgen).funcBody().
Change-Id: I77ee5efcef9a8f6c7133564106a32437e36ba4bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/300990
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
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 case of partially inferred type arguments, we need to use the
IndexExpr as the key in g.info.Inferred[] rather than the CallExpr.
Added an extra fromStrings1 call in the settable.go test that tests
partially inferred type arguments. This new call uses a new concrete
type SettableString as well.
I also added another implementation fromStrings3 (derived from a go2go
tests) that typechecks but intentionally causes a panic.
Change-Id: I74d35c5a741f72f37160a96fbec939451157f392
Reviewed-on: https://go-review.googlesource.com/c/go/+/300309
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
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>
Deal with cases like: 'type P[T any] T' (used to add methods to an
arbitrary type T), In this case, P[T] has kind types.TTYPEPARAM (as does
T itself), but requires more code to substitute than a simple TTYPEPARAM
T. See the comment near the beginning of subster.typ() in stencil.go.
Add new test absdiff.go. This test has a case for complex types (which
I've commented out) that will only work when we deal better with Go
builtins in generic functions (like real and imag).
Remove change in fmt.go for TTYPEPARAMS that is no longer needed (since
all TTYPEPARAMS have a sym) and was sometimes causing an extra prefix
when formatting method names.
Separate out the setting of a TTYPEPARAM bound, since it can reference
the TTYPEPARAM being defined, so must be done separately. Also, we don't
currently (and may not ever) need bounds after types2 typechecking.
Change-Id: Id173057e0c4563b309b95e665e9c1151ead4ba77
Reviewed-on: https://go-review.googlesource.com/c/go/+/300049
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
These instructions are actually 5 argument opcodes as specified
by the ISA. Prior to this patch, the MB and ME arguments were
merged into a single bitmask operand to workaround the limitations
of the ppc64 assembler backend.
This limitation no longer exists. Thus, we can pass operands for
these opcodes without having to merge the MB and ME arguments in
the assembler frontend or compiler backend.
Likewise, support for 4 operand variants is unchanged.
Change-Id: Ib086774f3581edeaadfd2190d652aaaa8a90daeb
Reviewed-on: https://go-review.googlesource.com/c/go/+/298750
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Carlos Eduardo Seo <carlos.seo@linaro.org>
Trust: Carlos Eduardo Seo <carlos.seo@linaro.org>
ABI info producer and consumer had different ideas for register
order for parameters.
Includes a test, includes improvements to debugging output.
Updates #44816.
Change-Id: I4812976f7a6c08d6fc02aac1ec0544b1f141cca6
Reviewed-on: https://go-review.googlesource.com/c/go/+/299570
Trust: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Includes more enhancements to debugging output.
Updates #44816.
Change-Id: I5b21815cf37ed21e7dec6c06f538090f32260203
Reviewed-on: https://go-review.googlesource.com/c/go/+/299409
Trust: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Get instantiatiated generic types working with interfaces, including
typechecking assignments to interfaces and instantiating all the methods
properly. To get it all working, this change includes:
- Add support for substituting in interfaces in subster.typ()
- Fill in the info for the methods for all instantiated generic types,
so those methods will be available for later typechecking (by the old
typechecker) when assigning an instantiated generic type to an
interface. We also want those methods available so we have the list
when we want to instantiate all methods of an instantiated type. We
have both for instantiated types encountered during the initial noder
phase, and for instantiated types created during stenciling of a
function/method.
- When we first create a fully-instantiated generic type (whether
during initial noder2 pass or while instantiating a method/function),
add it to a list so that all of its methods will also be
instantiated. This is needed so that an instantiated type can be
assigned to an interface.
- Properly substitute type names in the names of instantiated methods.
- New accessor methods for types.Type.RParam.
- To deal with generic types which are empty structs (or just don't use
their type params anywhere), we want to set HasTParam if a named type
has any type params that are not fully instantiated, even if the
type param is not used in the type.
- In subst.typ() and elsewhere, always set sym.Def for a new forwarding
type we are creating, so we always create a single unique type for
each generic type instantiation. This handles recursion within a
type, and also recursive relationships across many types or methods.
We remove the seen[] hashtable, which was serving the same purpose,
but for subst.typ() only. We now handle all kinds of recursive types.
- We don't seem to need to force types.CheckSize() on
created/substituted generic types anymore, so commented out for now.
- Add an RParams accessor to types2.Signature, and also a new
exported types2.AsSignature() function.
Change-Id: If6c5dd98427b20bfe9de3379cc16f83df9c9b632
Reviewed-on: https://go-review.googlesource.com/c/go/+/298449
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
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>
includes three tests
Change-Id: I33ac0cfe35085d4b6ad2775abcaa3d7d6527b49f
Reviewed-on: https://go-review.googlesource.com/c/go/+/297031
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
It is not multithreaded-compilation-safe, and also seems
to cause problems on the noopt-builder.
Change-Id: I52dbcd507d256990f1ec7c8040ec7b76595aae4f
Reviewed-on: https://go-review.googlesource.com/c/go/+/298850
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Added a test that exercises named results
Change-Id: Ie228b68f4f846266595a95e0f65a6e4b8bf79635
Reviewed-on: https://go-review.googlesource.com/c/go/+/297029
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
at least for ints and strings
includes simple test
For #40724.
Change-Id: Ib8484e5b957b08f961574a67cfd93d3d26551558
Reviewed-on: https://go-review.googlesource.com/c/go/+/295309
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Verified with test and with single step watching changes to register
values across morestack calls, after reload.
Also added stack-growth test with pointer parameters of varying lifetime.
For #40724.
Change-Id: Idb5fe27786ac5c6665a734d41e68d3d39de2f4da
Reviewed-on: https://go-review.googlesource.com/c/go/+/294429
Trust: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Morestack works for non-pointer register parameters
Within a function body, pointer-typed parameters are correctly
tracked.
Results still not hooked up.
For #40724.
Change-Id: Icaee0b51d0da54af983662d945d939b756088746
Reviewed-on: https://go-review.googlesource.com/c/go/+/294410
Trust: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@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>
Add generic rule to rewrite the single-precision square root expression
with one single-precision instruction. The optimization will reduce two
times of precision converting between double-precision and single-precision.
On arm64 flatform.
previous:
FCVTSD F0, F0
FSQRTD F0, F0
FCVTDS F0, F0
optimized:
FSQRTS S0, S0
And this patch adds the test case to check the correctness.
This patch refers to CL 241877, contributed by Alice Xu
(dianhong.xu@arm.com)
Change-Id: I6de5d02281c693017ac4bd4c10963dd55989bd7e
Reviewed-on: https://go-review.googlesource.com/c/go/+/276873
Trust: fannie zhang <Fannie.Zhang@arm.com>
Run-TryBot: fannie zhang <Fannie.Zhang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
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>
One of escape analysis's responsibilities is to summarize whether/how
each function parameter flows to the heap so we can correctly
incorporate those flows into callers' escape analysis data flow
graphs.
As an optimization, we separately record when parameters flow to
result parameters, so that we can more precisely analyze parameter
flows based on how the results are used at the call site. However, if
a named result parameter itself needs to be heap allocated, this
optimization isn't safe and the parameter needs to be recorded as
flowing to heap rather than flowing to result.
Escape analysis used to get this correct because it conservatively
rewalked the data-flow graph multiple times. So even though it would
incorrectly record the result parameter flow, it would separately find
a flow to the heap. However, CL 196811 (specifically, case 3)
optimized the walking logic to reduce unnecessary rewalks causing us
to stop finding the extra heap flow.
This CL fixes the issue by correcting location.leakTo to be sensitive
to sink.escapes and not record result-flows when the result parameter
escapes to the heap.
Fixes#44614.
Change-Id: I48742ed35a6cab591094e2d23a439e205bd65c50
Reviewed-on: https://go-review.googlesource.com/c/go/+/297289
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
A function returning multiple results, some of them zero-width,
will have more than one result present at an offset. Be sure
that offset AND type match.
Includes test.
Change-Id: I3eb1f56116d989b4e73f533fefabb1bf554c901b
Reviewed-on: https://go-review.googlesource.com/c/go/+/297169
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
- Deal with closures in generic functions by fixing the stenciling code
- Deal with instantiated function values (instantiated generic
functions that are not immediately called) during stenciling. This
requires changing the OFUNCINST node to an ONAME node for the
appropriately instantiated function. We do this in a second pass,
since this is uncommon, but requires editing the tree at multiple
levels.
- Check global assignments (as well as functions) for generic function
instantiations.
- Fix a bug in (*subst).typ where a generic type in a generic function
may definitely not use all the type args of the function, so we need
to translate the rparams of the type based on the tparams/targs of
the function.
- Added new test combine.go that tests out closures in generic
functions and instantiated function values.
- Added one new variant to the settable test.
- Enabling inlining functions with closures for -G=3. (For now, set
Ntype on closures in -G=3 mode to keep compatibility with later parts
of compiler, and allow inlining of functions with closures.)
Change-Id: Iea63d5704c322e42e2f750a83adc8b44f911d4ec
Reviewed-on: https://go-review.googlesource.com/c/go/+/296269
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
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>
math.Float32bits was not being inlined across package boundaries.
Create a private func that can be inlined with -l.
Change-Id: Ic50bf4727dd8ade09d011eb204006b7ee88db34a
Reviewed-on: https://go-review.googlesource.com/c/go/+/295989
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Added a flag '-d=inlfuncswithclosures=1' to allow inlining functions with
closures, and change the default to off for now, until #44370 is fixed.
Updates #44370.
Change-Id: Ic17723aa5c091d91f5f5004d8b63ec7125257acf
Reviewed-on: https://go-review.googlesource.com/c/go/+/296049
Run-TryBot: Dan Scales <danscales@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
The code generated when storing eight bytes loaded from memory created a
series of small writes instead of a single, large one. The specific
pattern of instructions generated stored 1 byte, then 2 bytes, then 4
bytes, and finally 1 byte.
The new rules match this specific pattern both for amd64 and for s390x,
and convert it into a single instruction to store the 8 bytes. arm64 and
ppc64le already generated the right code, but the new codegen test
covers also those architectures.
Fixes#41663
Change-Id: Ifb9b464be2d59c2ed5034acf7b9c3e473f344030
Reviewed-on: https://go-review.googlesource.com/c/go/+/280456
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Plumb abi information into ssa/ssagen for plain calls
and plain functions (not methods). Does not extend all the
way through the compiler (yet).
One test disabled because it extends far enough to break the test.
Normalized all the compiler's register args TODOs to
// TODO(register args) ...
For #40724.
Change-Id: I0173a4579f032ac3c9db3aef1749d40da5ea01ff
Reviewed-on: https://go-review.googlesource.com/c/go/+/293389
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>
OCONVOP doesn't have effect in the compiled code so, it can be safely
excluded from inline cost calculation.
Also make sequence ODEREF OCONVNOP* OADDR cost 1. This is rather common
conversion, such as *(*uint32)(unsafe.Pointer(&x)).
Fixes#42788
Change-Id: I5001f7e89d985c198b6405694cdd5b819cf3f47a
Reviewed-on: https://go-review.googlesource.com/c/go/+/281232
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Elias Naur <mail@eliasnaur.com>
Some bit test instruction generation stopped triggering after
the change to addressing modes. I suspect this was just because
ANDQload was being generated before the rewrite rules could discover
the BTQ. Fix that by decomposing the ANDQload when it is surrounded
by a TESTQ (thus re-enabling the BTQ rules).
Fixes#44228
Change-Id: I489b4a5a7eb01c65fc8db0753f8cec54097cadb2
Reviewed-on: https://go-review.googlesource.com/c/go/+/291749
Trust: Keith Randall <khr@golang.org>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Currently, we keep track of slice len by mapping from slice ID to
len/cap SSA value. However, slice len/cap can have multiple SSA values,
so when updating fact table for slice len/cap, we only update in one
place.
Instead, we can take advantage of the transitive relations provided by
poset. So all duplicated slice lens are set as equal to one another.
When updating fact table for one, that fact will be reflected to all
others. The same mechanism is applied for slice cap.
Removes 15 bounds checks from std/cmd.
Fixes#42603
Change-Id: I32c07968824cc33765b1e441b3ae2c4b5f5997c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/273670
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: Keith Randall <khr@golang.org>
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>
The address space starts at 4GB, so dummy is too far out.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
Change-Id: I5f67e268ce729086d9f9fc8541722fabccfd0145
Reviewed-on: https://go-review.googlesource.com/c/go/+/288823
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
A type may now have a type param in it, either because it has been
composed from a function type param, or it has been declared as or
derived from a reference to a generic type. No objects or types with
type params can be exported yet. No generic type has a runtime
descriptor (but will likely eventually be associated with a dictionary).
types.Type now has an RParam field, which for a Named type can specify
the type params (in order) that must be supplied to fully instantiate
the type. Also, there is a new flag HasTParam to indicate if there is
a type param (TTYPEPARAM) anywhere in the type.
An instantiated generic type (whether fully instantiated or
re-instantiated to new type params) is a defined type, even though there
was no explicit declaration. This allows us to handle recursive
instantiated types (and improves printing of types).
To avoid the need to transform later in the compiler, an instantiation
of a method of a generic type is immediately represented as a function
with the method as the first argument.
Added 5 tests on generic types to test/typeparams, including list.go,
which tests recursive generic types.
Change-Id: Ib7ff27abd369a06d1c8ea84edc6ca1fd74bbb7c2
Reviewed-on: https://go-review.googlesource.com/c/go/+/292652
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Dan Scales <danscales@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
This was a mostly clean merge, with the exception of codereview.cfg and
changes in src/go/types.
codereview.cfg for dev.typeparams is preserved in this CL. It should be
deleted before merging back to master.
The go/types changes were merged manually. For the most part this
involved taking the union of patches, with the following exceptions:
+ declInfo.aliasPos is removed, as it is not necessary in
dev.typeparams where we have access to the full TypeSpec.
+ Checker.overflow is updated to use the asBasic converter.
+ A TODO is added to errorcodes.go to ensure that go1.16 error codes
are preserved.
Change-Id: If9595196852e2163e27a9478df1e7b2c3704947d
Currently, we call Warnl in SSA backend when we see a function
(defined or called) with regparams pragma. Calling Warnl in
concurrent environment is racy. As the debugging output is
temporary, for testing purposes we just pass -c=1. We'll remove
the pragma and the debugging print some time soon.
Change-Id: I6f925a665b953259453fc458490c5ff91f67c91a
Reviewed-on: https://go-review.googlesource.com/c/go/+/291710
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Conflicts:
- src/cmd/compile/internal/gc/walk.go
gc/walk.go is changed in CL 290950 on the master branch but
deleted in the dev.regabi branch and moved over to the walk
package. This CL includes porting CL 290950 over to the new
walk.
Merge List:
+ 2021-02-12 ff0e93ea31 doc/go1.16: note that package path elements beginning with '.' are disallowed
+ 2021-02-11 249da7ec02 CONTRIBUTORS: update for the Go 1.16 release
+ 2021-02-11 864d4f1c6b cmd/go: multiple small 'go help' fixes
+ 2021-02-11 26ceae85a8 spec: More precise wording in section on function calls.
+ 2021-02-11 930c2c9a68 cmd/go: reject embedded files that can't be packed into modules
+ 2021-02-11 e5b08e6d5c io/fs: allow backslash in ValidPath, reject in os.DirFS.Open
+ 2021-02-10 ed8079096f cmd/compile: mark concrete call of reflect.(*rtype).Method as REFLECTMETHOD
+ 2021-02-09 e9c9683597 cmd/go: suppress errors from 'go get -d' for packages that only conditionally exist
+ 2021-02-09 e0ac989cf3 archive/tar: detect out of bounds accesses in PAX records resulting from padded lengths
+ 2021-02-09 c9d6f45fec runtime/metrics: fix a couple of documentation typpos
+ 2021-02-09 cea4e21b52 io/fs: backslash is always a glob meta character
+ 2021-02-08 dc725bfb3c doc/go1.16: mention new vet check for asn1.Unmarshal
Change-Id: Ib28fffa7dfbff7f6cdbfaf4a304757fead7bbf19
- Create the stencil name using targ.Type.String(), which handles cases
where, for example, a type argument is a pointer to a named type,
etc. *obj.
- Set name.Def properly for a new stenciled func (have the symbol point
back to the associated function node). Will be required when exporting.
- Add missing copying of Func field when making copies of Name nodes.
(On purpose (it seems), Name nodes don't have a copy() function, so
we have to copy all the needed fields explicitly.)
- Deal with nil type in subster.node(), which is the type of the return
value for a function that doesn't return anything.
- Fix min to match standard want/go form, and add in float tests. Changed
Got -> got in bunch of other typeparam tests.
- Add new tests index.go, settable.go, and smallest.go (similar to
examples in the type param proposal), some of which need the above
changes.
Change-Id: I09a72302bc1fd3635a326da92405222afa222e85
Reviewed-on: https://go-review.googlesource.com/c/go/+/291109
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
For functions that call reflect.Type.Method (or MethodByName), we
mark it as REFLECTMETHOD, which tells the linker that methods
can be retrieved via reflection and the linker keeps all exported
methods live. Currently, this marking expects exactly the
interface call reflect.Type.Method (or MethodByName). But now the
compiler can devirtualize that call to a concrete call
reflect.(*rtype).Method (or MethodByName), which is not handled
and causing the linker to discard methods too aggressively.
Handle the latter in this CL.
Fixes#44207.
Change-Id: Ia4060472dbff6ab6a83d2ca8e60a3e3f180ee832
Reviewed-on: https://go-review.googlesource.com/c/go/+/290950
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Add respective check to type checker.
Enables another excluded test in test/run.go.
This CL completes the currently required checks for
language compatibility in types2.
Updates #31793.
Change-Id: Icececff9e6023d38f600c93bcb54cdcafcf501b9
Reviewed-on: https://go-review.googlesource.com/c/go/+/290911
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
When doing a type conversion using a type param, delay the
transformation to OCONV/OCONVNOP until stenciling, since the nodes
created depend on the actual type.
Re-enable the fact.go test.
Change-Id: I3d5861aab3dd0e781d767f67435afaf951dfe451
Reviewed-on: https://go-review.googlesource.com/c/go/+/290752
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
- Have to delay the extra transformation on methods invoked on a type
param, since the actual transformation (including path through
embedded fields) will depend on the instantiated type. I am currently
doing the transformation during the stencil substitution phase. We
probably should have a separate pass after noder2 and stenciling,
which drives the extra transformations that were in the old
typechecker.
- We handle method values (that are not called) and method calls. We
don't currently handle method expressions.
- Handle type substitution in function types, which is needed for
function args in generic functions.
- Added stringer.go and map.go tests, testing the above changes
(including constraints with embedded interfaces).
Change-Id: I3831a937d2b8814150f75bebf9f23ab10b93fa00
Reviewed-on: https://go-review.googlesource.com/c/go/+/290550
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Dan Scales <danscales@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
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 involved a couple non-trivial fixes in go/types:
- move the check for main function signature to resolver.go, to be
consistent with init. Also, update uses of _InvalidInitSig to
_InvalidInitDecl, consistent with what we decided for dev.regabi.
- Update some tests in api_test.go which newly fail after CL 289715
(fixing reporting of untyped nil) In all cases but one, these updates
were consistent with types2. However, in one case types2 seems to be
able to resolve more type information than go/types for a broken
package. I left a TODO to investigate this further.
Change-Id: I8244b7c81654194edd5af8de689a13c262117dff
Disabled test/typeparam/fact.go for now as there's an issue
with stenciling.
Change-Id: Ie328a217de6d7b6695737f08ef5c944bcdaabd39
Reviewed-on: https://go-review.googlesource.com/c/go/+/290471
Trust: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
- Handle generic function calling itself or another generic function in
stenciling. This is easy - after it is created, just scan an
instantiated generic function for function instantiations (that may
needed to be stenciled), just like non-generic functions. The types
in the function instantiation will already have been set by the
stenciling.
- Handle OTYPE nodes in subster.node() (allows for generic type
conversions).
- Eliminated some duplicated work in subster.typ().
- Added new test case fact.go that tests a generic function calling
itself, and simple generic type conversions.
- Cause an error if a generic function is to be exported (which we
don't handle yet).
- Fixed some suggested changes in the add.go test case that I missed in
the last review.
Change-Id: I5d61704254c27962f358d5a3d2e0c62a5099f148
Reviewed-on: https://go-review.googlesource.com/c/go/+/290469
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Allow full compilation and running of simple programs with generic
functions by stenciling on the fly the needed generic functions. Deal
with some simple derived types based on type params.
Include a few new typeparam tests min.go and add.go which involve
fully compiling and running simple generic code.
Change-Id: Ifc2a64ecacdbd860faaeee800e2ef49ffef9df5e
Reviewed-on: https://go-review.googlesource.com/c/go/+/289630
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@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>
This matches the compiler's existing limitations and thus ensures
that types2 reports the same errors for oversize integer constants.
Change-Id: I4fb7c83f3af69098d96f7b6c53dbe3eaf6ea9ee4
Reviewed-on: https://go-review.googlesource.com/c/go/+/288633
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
In ABIInternal, reserve X15 as constant zero, and use it to zero
memory. (Maybe there can be more use of it?)
The register is zeroed when transition to ABIInternal from ABI0.
Caveat: using X15 generates longer instructions than using X0.
Maybe we want to use X0?
Change-Id: I12d5ee92a01fc0b59dad4e5ab023ac71bc2a8b7d
Reviewed-on: https://go-review.googlesource.com/c/go/+/288093
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>
Change-Id: I6290bc4921ef17586b5028d3f40a88372b175014
Reviewed-on: https://go-review.googlesource.com/c/go/+/289269
Trust: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
The compiler uses 512 bit of precision for untyped constant
arithmetic but didn't restrict the length of incoming constant
literals in any way, possibly opening the door for excessively
long constants that could bring compilation to a crawl.
Add a simple check that refuses excessively long constants.
Add test.
Change-Id: I797cb2a8e677b8da2864eb92d686d271ab8a004d
Reviewed-on: https://go-review.googlesource.com/c/go/+/289049
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
These newly enabled (not anymore excluded) tests pass now
that we run in -G=3 mode when using the new types2 based
noder.
Change-Id: I5e7304c8020f394b79737d67c750bebbe02bd502
Reviewed-on: https://go-review.googlesource.com/c/go/+/289109
Trust: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
CL 279423 introduced a regression in this test as it incorrectly laid
out various instructions. In the case of arm, the second instruction
was overwriting the first. In the case of 386, amd64 and s390x, the
instructions were being appended to the end of the slice after 64
zero bytes.
This was causing test failures on "linux/s390x on z13".
Fixes#44028
Change-Id: Id136212dabdae27db7e91904b0df6a3a9d2f4af4
Reviewed-on: https://go-review.googlesource.com/c/go/+/288278
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Add a test case for issue 43818. We don't want to mark as inlinable a
function with a closure that has an operation (such as OSELRECV2) that
we don't currently support for exporting. This test case fails to
compile without the fix for #43818.
Updates #43818
Change-Id: Ief322a14aefaefc6913c40a6b8505214bd622fda
Reviewed-on: https://go-review.googlesource.com/c/go/+/288392
Run-TryBot: Dan Scales <danscales@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Factor out the existing "constant representation" check after
untyped constant arithmetic and combine with an overflow check.
Use a better heuristic for determining the error position if we
know the error is for a constant operand that is the result of an
arithmetic expression.
Related cleanups.
With this change, untyped constant arithmetic reports an error
when (integer) constants become too large (> 2048 bits). Before,
such arithmetic was only limited by space and time.
Change-Id: Id3cea66c8ba697ff4c7fd1e848f350d9713e3c75
Reviewed-on: https://go-review.googlesource.com/c/go/+/287832
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
1) Rather than map-iterate through all file scopes and collect unused
packages, collect all imports in the Checker.imports list so that
errors are reported in source order.
2) From cmd/compile, borrow the idea of a "dotImportRefs" map to map
dot-imported objects to the package they were dot-imported through
(we call the map "dotImportMap").
3) From cmd/compile, borrow the "pkgnotused" function
(called Checker.errorUnusedPkg in this code) and clean up
unused package error reporting.
4) Adjust unused package error message to match compiler message exactly.
5) Enable one more excluded test case in test/run.go.
Change-Id: I4e4e55512a6043a7fd54f576c7441e3dd4077d6f
Reviewed-on: https://go-review.googlesource.com/c/go/+/287072
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The recent refactoring of SelectorExpr code to helpers broke the
handling of MethodExprs when there is an embedded field involved (e.g.
test/method7.go, line 48). If there is an embedded field involved, the
node op seen in DotMethod() is an ODOT rather than an OTYPE. Also, the
receiver type of the result should be the original type, but the new
code was using the last type after following the embedding path.
Change-Id: I13f7ea6448b03d3e8f974103ee3a027219ca8388
Reviewed-on: https://go-review.googlesource.com/c/go/+/286176
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>
The test is fine and probably was excluded by mistake.
Change-Id: I98508e603afe01a781ad7c8638830514aa75939c
Reviewed-on: https://go-review.googlesource.com/c/go/+/286732
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Currently, types2 sometimes produces constant.Values with a Kind
different than the untyped constant type's Is{Integer,Float,Complex}
info, which irgen expects to always match.
While we mull how best to proceed in #43891, this CL adapts irgen to
types2's current behavior. In particular, fixedbugs/issue11945.go now
passes with -G=3.
Updates #43891.
Change-Id: I24823a32ff49af6045a032d3903dbb55cbec6bef
Reviewed-on: https://go-review.googlesource.com/c/go/+/286652
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
This merge involved two merge conflicts:
1. walk's ascompatee code has been substantially refactored on
dev.regabi, so CL 285633 is ported to the new style.
2. The os.TestDirFS workaround added in CL 286213 can be removed now
that #42637 has been fixed by CL 285720.
Conflicts:
- src/cmd/compile/internal/gc/walk.go
- src/os/os_test.go
Merge List:
+ 2021-01-25 bf0f7c9d78 doc/go1.16: mention os.DirFS in os section
+ 2021-01-25 deaf29a8a8 cmd/compile: fix order-of-assignment issue w/ defers
+ 2021-01-25 ad2ca26a52 doc/go1.16: mention os.DirEntry and types moved from os to io/fs
+ 2021-01-25 a51921fa5b doc/go1.16: mention new testing/iotest functions
+ 2021-01-25 e6b6d107f7 doc/go1.16: mention deprecation of io/ioutil
+ 2021-01-25 96a276363b doc/go1.16: mention go/build changes
+ 2021-01-25 3d85c69a0b html/template: revert "avoid race when escaping updates template"
+ 2021-01-25 54514c6b28 cmd/go: fix TestScript/cgo_path, cgo_path_space when CC set
+ 2021-01-25 6de8443f3b doc/asm: add a section on go_asm.h, clean up go_tls.h section
+ 2021-01-25 54b251f542 lib/time, time/tzdata: update tzdata to 2021a
+ 2021-01-25 ff82cc971a os: force consistent mtime before running fstest on directory on Windows
+ 2021-01-25 044f937a73 doc/go1.16: fix WalkDir and Walk links
+ 2021-01-23 b634f5d97a doc/go1.16: add crypto/x509 memory optimization
+ 2021-01-23 9897655c61 doc/go1.16: reword ambiguously parsable sentence
+ 2021-01-23 cd99385ff4 cmd/internal/obj/arm64: fix VMOVQ instruction encoding error
+ 2021-01-23 66ee8b158f runtime: restore cgo_import_dynamic for libc.so on openbsd
+ 2021-01-22 25c39e4fb5 io/ioutil: fix example test for WriteFile to allow it to run in the playground
+ 2021-01-22 eb21b31e48 runtime: define dummy msanmove
+ 2021-01-22 3a778ff50f runtime: check for g0 stack last in signal handler
+ 2021-01-22 a2cef9b544 cmd/go: don't lookup the path for CC when invoking cgo
Change-Id: I651949f9eb18b57e3c996c4f3b2b3bf458bc5d97
CL 261677 fixed a logic issue in walk's alias detection, where it was
checking the RHS expression instead of the LHS expression when trying
to determine the kind of assignment. However, correcting this exposed
a latent issue with assigning to result parameters in functions with
defers, where an assignment could become visible earlier than intended
if a later expression could panic.
Fixes#43835.
Change-Id: I061ced125e3896e26d65f45b28c99db2c8a74a8c
Reviewed-on: https://go-review.googlesource.com/c/go/+/285633
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Floating-point constants are represented as rational numbers when
possible (i.e., when numerators and denominators are not too large).
If we convert to floats when not necessary, we risk losing precision.
This is the minimal fix for the specific issue, but it's too aggressive:
If the numbers are too large, we still want to convert to floats.
Will address in a separate CL that also does a few related cleanups.
Fixes#43908.
Change-Id: Id575e34fa18361a347c43701cfb4dd7221997f66
Reviewed-on: https://go-review.googlesource.com/c/go/+/286552
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This allows more precision and matches types2's behavior.
For backwards compatibility with gcimporter, for now we still need to
write out declared constants as limited-precision floating-point
values. To ensure consistent behavior of constant arithmetic whether
it spans package boundaries or not, we include the full-precision
rational representation in the compiler's extension section of the
export data.
Also, this CL simply uses the math/big.Rat.String text representation
as the encoding. This is inefficient, but because it's only in the
compiler's extension section, we can easily revisit this in the
future.
Declaring exported untyped float and complex constants isn't very
common anyway. Within the standard library, only package math declares
any at all, containing just 15. And those 15 are only imported a total
of 12 times elsewhere in the standard library.
Change-Id: I85ea23ab712e93fd3b68e52d60cbedce9be696a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/286215
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Change-Id: I170e4f9c5a1db4bad02a5fe4bddc65d4c75f51e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/286232
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Eager re-sync-branch to keep Git history reasonably accurate, since
Git lacks a better way of encoding partial merges like CL 286172.
Conflicts:
- src/cmd/compile/internal/inline/inl.go
- src/cmd/compile/internal/noder/import.go
- src/cmd/compile/internal/noder/noder.go
Merge List:
+ 2021-01-25 063c72f06d [dev.regabi] cmd/compile: backport changes from dev.typeparams (9456804)
+ 2021-01-23 d05d6fab32 [dev.regabi] cmd/compile: replace ir.Name map with ir.NameSet for SSA 2
+ 2021-01-23 48badc5fa8 [dev.regabi] cmd/compile: fix escape analysis problem with closures
+ 2021-01-23 51e1819a8d [dev.regabi] cmd/compile: scan body of closure in tooHairy to check for disallowed nodes
Change-Id: I48c0435f7aaf56f4aec26518a7459e9d95a51e9c
This CL backports a bunch of changes that landed on dev.typeparams,
but are not dependent on types2 or generics. By backporting, we reduce
the divergence between development branches, hopefully improving test
coverage and reducing risk of merge conflicts.
Updates #43866.
Change-Id: I382510855c9b5fac52b17066e44a00bd07fe86f5
Reviewed-on: https://go-review.googlesource.com/c/go/+/286172
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>
Change-Id: I9591f7aeab0448aca661560bf3064e057b48293e
Reviewed-on: https://go-review.googlesource.com/c/go/+/286012
Trust: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
In reflect.methodWrapper, we call escape analysis without including the
full batch of dependent functions, including the closure functions.
Because of this, we haven't created locations for the params/local
variables of a closure when we are processing a function that
inlines that closure. (Whereas in the normal compilation of the
function, we do call with the full batch.) To deal with this, I am
creating locations for the params/local variables of a closure when
needed.
Without this fix, the new test closure6.go would fail.
Updates #43818
Change-Id: I5f91cfb6f35efe2937ef88cbcc468e403e0da9ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/285677
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>
As with CL 285875, this required resolving some conflicts around
handling of //go:embed directives. Still further work is needed to
reject uses of //go:embed in files that don't import "embed", so this
is left as a TODO. (When this code was written for dev.typeparams, we
were still leaning towards not requiring the "embed" import.)
Also, the recent support for inlining closures (CL 283112) interacts
poorly with -G=3 mode. There are some known issues with this code
already (#43818), so for now this CL disables inlining of closures
when in -G=3 mode with a TODO to revisit this once closure inlining is
working fully.
Conflicts:
- src/cmd/compile/internal/noder/noder.go
- src/cmd/compile/internal/typecheck/dcl.go
- src/cmd/compile/internal/typecheck/func.go
- test/run.go
Merge List:
+ 2021-01-22 7e0a81d280 [dev.regabi] all: merge master (dab3e5a) into dev.regabi
+ 2021-01-22 dab3e5affe runtime: switch runtime to libc for openbsd/amd64
+ 2021-01-22 a1b53d85da cmd/go: add documentation for test and xtest fields output by go list
+ 2021-01-22 b268b60774 runtime: remove pthread_kill/pthread_self for openbsd
+ 2021-01-22 ec4051763d runtime: fix typo in mgcscavenge.go
+ 2021-01-22 7ece3a7b17 net/http: fix flaky TestDisableKeepAliveUpgrade
+ 2021-01-22 50cba0506f time: clarify Timer.Reset behavior on AfterFunc Timers
+ 2021-01-22 cf10e69f17 doc/go1.16: mention net/http.Transport.GetProxyConnectHeader
+ 2021-01-22 ec1b945265 doc/go1.16: mention path/filepath.WalkDir
+ 2021-01-22 11def3d40b doc/go1.16: mention syscall.AllThreadsSyscall
+ 2021-01-21 07b0235609 doc/go1.16: add notes about package-specific fs.FS changes
+ 2021-01-21 e2b4f1fea5 doc/go1.16: minor formatting fix
+ 2021-01-21 9f43a9e07b doc/go1.16: mention new debug/elf constants
+ 2021-01-21 3c2f11ba5b cmd/go: overwrite program name with full path
+ 2021-01-21 953d1feca9 all: introduce and use internal/execabs
+ 2021-01-21 b186e4d70d cmd/go: add test case for cgo CC setting
+ 2021-01-21 5a8a2265fb cmd/cgo: report exec errors a bit more clearly
+ 2021-01-21 46e2e2e9d9 cmd/go: pass resolved CC, GCCGO to cgo
+ 2021-01-21 3d40895e36 runtime: switch openbsd/arm64 to pthreads
+ 2021-01-21 d95ca91380 crypto/elliptic: fix P-224 field reduction
+ 2021-01-21 d7e71c01ad [dev.regabi] cmd/compile: replace ir.Name map with ir.NameSet for dwarf
+ 2021-01-21 5248f59a22 [dev.regabi] cmd/compile: replace ir.Name map with ir.NameSet for SSA
+ 2021-01-21 970d8b6cb2 [dev.regabi] cmd/compile: replace ir.Name map with ir.NameSet in inlining
+ 2021-01-21 68a4664475 [dev.regabi] cmd/compile: remove tempAssigns in walkCall1
+ 2021-01-21 fd9a391cdd [dev.regabi] cmd/compile: remove CallExpr.Rargs
+ 2021-01-21 19a6db6b63 [dev.regabi] cmd/compile: make sure mkcall* passed non-nil init
+ 2021-01-21 9f036844db [dev.regabi] cmd/compile: use ir.DoChildren directly in inlining
+ 2021-01-21 213c3905e9 [dev.regabi] cmd/compile: use node walked flag to prevent double walk for walkSelect
+ 2021-01-20 1760d736f6 [dev.regabi] cmd/compile: exporting, importing, and inlining functions with OCLOSURE
+ 2021-01-20 ecf4ebf100 cmd/internal/moddeps: check content of all modules in GOROOT
+ 2021-01-20 92cb157cf3 [dev.regabi] cmd/compile: late expansion of return values
+ 2021-01-20 d2d155d1ae runtime: don't adjust timer pp field in timerWaiting status
+ 2021-01-20 803d18fc6c cmd/go: set Incomplete field on go list output if no files match embed
+ 2021-01-20 6e243ce71d cmd/go: have go mod vendor copy embedded files in subdirs
+ 2021-01-20 be28e5abc5 cmd/go: fix mod_get_fallback test
+ 2021-01-20 928bda4f4a runtime: convert openbsd/amd64 locking to libc
+ 2021-01-19 824f2d635c cmd/go: allow go fmt to complete when embedded file is missing
+ 2021-01-19 0575e35e50 cmd/compile: require 'go 1.16' go.mod line for //go:embed
+ 2021-01-19 9423d50d53 [dev.regabi] cmd/compile: use '%q' for printing rune values less than 128
+ 2021-01-19 ccb2e90688 cmd/link: exit before Asmb2 if error
+ 2021-01-19 ca5774a5a5 embed: treat uninitialized FS as empty
+ 2021-01-19 d047c91a6c cmd/link,runtime: switch openbsd/amd64 to pthreads
+ 2021-01-19 61debffd97 runtime: factor out usesLibcall
+ 2021-01-19 9fed39d281 runtime: factor out mStackIsSystemAllocated
+ 2021-01-19 a2f825c542 [dev.regabi] cmd/compile: directly create go.map and go.track symbols
+ 2021-01-19 4a4212c0e5 [dev.regabi] cmd/compile: refactor Linksym creation
+ 2021-01-19 4f5c603c0f [dev.regabi] cmd/compile: cleanup callTargetLSym
+ 2021-01-18 dbab079835 runtime: free Windows event handles after last lock is dropped
+ 2021-01-18 5a8fbb0d2d os: do not close syscall.Stdin in TestReadStdin
+ 2021-01-18 422f38fb6c [dev.regabi] cmd/compile: move stack objects to liveness
+ 2021-01-18 6113db0bb4 [dev.regabi] cmd/compile: convert OPANIC argument to interface{} during typecheck
+ 2021-01-18 4c835f9169 [dev.regabi] cmd/compile: use LinksymOffsetExpr in TypePtr/ItabAddr
+ 2021-01-18 0ffa1ead6e [dev.regabi] cmd/compile: use *obj.LSym instead of *ir.Name for staticdata functions
+ 2021-01-17 7e0fa38aad [dev.regabi] cmd/compile: remove unneeded packages from ir.Pkgs
+ 2021-01-17 99a5db11ac [dev.regabi] cmd/compile: use LinksymOffsetExpr in walkConvInterface
+ 2021-01-17 87845d14f9 [dev.regabi] cmd/compile: add ir.TailCallStmt
+ 2021-01-17 e3027c6828 [dev.regabi] cmd/compile: fix linux-amd64-noopt builder
+ 2021-01-17 59ff93fe64 [dev.regabi] cmd/compile: rename NameOffsetExpr to LinksymOffsetExpr
+ 2021-01-17 82b9cae700 [dev.regabi] cmd/compile: change ir.NameOffsetExpr to use *obj.LSym instead of *Name
+ 2021-01-17 88956fc4b1 [dev.regabi] cmd/compile: stop analyze NameOffsetExpr.Name_ in escape analysis
+ 2021-01-17 7ce2a8383d [dev.regabi] cmd/compile: simplify stack temp initialization
+ 2021-01-17 ba0e8a92fa [dev.regabi] cmd/compile: refactor temp construction in walk
+ 2021-01-17 78e5aabcdb [dev.regabi] cmd/compile: replace Node.HasCall with walk.mayCall
+ 2021-01-16 6de9423445 [dev.regabi] cmd/compile: cleanup OAS2FUNC ordering
+ 2021-01-16 a956a0e909 [dev.regabi] cmd/compile, runtime: fix up comments/error messages from recent renames
+ 2021-01-16 ab3b67abfd [dev.regabi] cmd/compile: remove ONEWOBJ
+ 2021-01-16 c9b1445ac8 [dev.regabi] cmd/compile: remove TypeAssertExpr {Src,Dst}Type fields
+ 2021-01-15 682a1d2176 runtime: detect errors in DuplicateHandle
+ 2021-01-15 9f83418b83 cmd/link: remove GOROOT write in TestBuildForTvOS
+ 2021-01-15 ec9470162f cmd/compile: allow embed into any string or byte slice type
+ 2021-01-15 54198b04db cmd/compile: disallow embed of var inside func
+ 2021-01-15 b386c735e7 cmd/go: fix go generate docs
+ 2021-01-15 bb5075a525 syscall: remove RtlGenRandom and move it into internal/syscall
+ 2021-01-15 1deae0b597 os: invoke processKiller synchronously in testKillProcess
+ 2021-01-15 03a875137f [dev.regabi] cmd/compile: unexport reflectdata.WriteType
+ 2021-01-15 14537e6e54 [dev.regabi] cmd/compile: move stkobj symbol generation to SSA
+ 2021-01-15 ab523fc510 [dev.regabi] cmd/compile: don't promote Byval CaptureVars if Addrtaken
+ 2021-01-15 ff196c3e84 crypto/x509: update iOS bundled roots to version 55188.40.9
+ 2021-01-15 b7a698c73f [dev.regabi] test: disable test on windows because expected contains path separators.
+ 2021-01-15 4be7af23f9 [dev.regabi] cmd/compile: fix ICE during ir.Dump
+ 2021-01-14 e125ccd10e cmd/go: in 'go mod edit', validate versions given to -retract and -exclude
+ 2021-01-14 eb330020dc cmd/dist, cmd/go: pass -arch for C compilation on Darwin
+ 2021-01-14 84e8a06f62 cmd/cgo: remove unnecessary space in cgo export header
+ 2021-01-14 0c86b999c3 cmd/test2json: document passing -test.paniconexit0
+ 2021-01-14 9135795891 cmd/go/internal/load: report positions for embed errors
+ 2021-01-14 35b9c66601 [dev.regabi] cmd/compile,cmd/link: additional code review suggestions for CL 270863
+ 2021-01-14 d9b79e53bb cmd/compile: fix wrong complement for arm64 floating-point comparisons
+ 2021-01-14 c73232d08f cmd/go/internal/load: refactor setErrorPos to PackageError.setPos
+ 2021-01-14 6aa28d3e06 go/build: report positions for go:embed directives
+ 2021-01-14 9734fd482d [dev.regabi] cmd/compile: use node walked flag to prevent double walk for walkSwitch
+ 2021-01-14 f97983249a [dev.regabi] cmd/compile: move more PAUTOHEAP to SSA construction
+ 2021-01-14 4476300425 [dev.regabi] cmd/compile: use byte for CallExpr.Use
+ 2021-01-14 5a5ab24689 [dev.regabi] cmd/compile: do not rely on CallExpr.Rargs for detect already walked calls
+ 2021-01-14 983ac4b086 [dev.regabi] cmd/compile: fix ICE when initializing blank vars
+ 2021-01-13 7eb31d999c cmd/go: add hints to more missing sum error messages
+ 2021-01-13 d6d4673728 [dev.regabi] cmd/compile: fix GOEXPERIMENT=regabi builder
+ 2021-01-13 c41b999ad4 [dev.regabi] cmd/compile: refactor abiutils from "gc" into new "abi"
+ 2021-01-13 861707a8c8 [dev.regabi] cmd/compile: added limited //go:registerparams pragma for new ABI dev
+ 2021-01-13 c1370e918f [dev.regabi] cmd/compile: add code to support register ABI spills around morestack calls
+ 2021-01-13 2abd24f3b7 [dev.regabi] test: make run.go error messages slightly more informative
+ 2021-01-13 9a19481acb [dev.regabi] cmd/compile: make ordering for InvertFlags more stable
+ 2021-01-12 ba76567bc2 cmd/go/internal/modload: delete unused *mvsReqs.next method
+ 2021-01-12 665def2c11 encoding/asn1: document unmarshaling behavior for IMPLICIT string fields
+ 2021-01-11 81ea89adf3 cmd/go: fix non-script staleness checks interacting badly with GOFLAGS
+ 2021-01-11 759309029f doc: update editors.html for Go 1.16
+ 2021-01-11 c3b4c7093a cmd/internal/objfile: don't require runtime.symtab symbol for XCOFF
+ 2021-01-08 59bfc18e34 cmd/go: add hint to read 'go help vcs' to GOVCS errors
+ 2021-01-08 cd6f3a54e4 cmd/go: revise 'go help' documentation for modules
+ 2021-01-08 6192b98751 cmd/go: make hints in error messages more consistent
+ 2021-01-08 25886cf4bd cmd/go: preserve sums for indirect deps fetched by 'go mod download'
+ 2021-01-08 6250833911 runtime/metrics: mark histogram metrics as cumulative
+ 2021-01-08 8f6a9acbb3 runtime/metrics: remove unused StopTheWorld Description field
+ 2021-01-08 6598c65646 cmd/compile: fix exponential-time init-cycle reporting
+ 2021-01-08 fefad1dc85 test: fix timeout code for invoking compiler
+ 2021-01-08 6728118e0a cmd/go: pass signals forward during "go tool"
+ 2021-01-08 e65c543f3c go/build/constraint: add parser for build tag constraint expressions
+ 2021-01-08 0c5afc4fb7 testing/fstest,os: clarify racy behavior of TestFS
+ 2021-01-08 32afcc9436 runtime/metrics: change unit on *-by-size metrics to match bucket unit
+ 2021-01-08 c6513bca5a io/fs: minor corrections to Glob doc
+ 2021-01-08 304f769ffc cmd/compile: don't short-circuit copies whose source is volatile
+ 2021-01-08 ae97717133 runtime,runtime/metrics: use explicit histogram boundaries
+ 2021-01-08 a9ccd2d795 go/build: skip string literal while findEmbed
+ 2021-01-08 d92f8add32 archive/tar: fix typo in comment
+ 2021-01-08 cab1202183 cmd/link: accept extra blocks in TestFallocate
+ 2021-01-08 ee4d32249b io/fs: minor corrections to Glob release date
+ 2021-01-08 54bd1ccce2 cmd: update to latest golang.org/x/tools
+ 2021-01-07 9ec21a8f34 Revert "reflect: support multiple keys in struct tags"
+ 2021-01-07 091414b5b7 io/fs: correct WalkDirFunc documentation
+ 2021-01-07 9b55088d6b doc/go1.16: add release note for disallowing non-ASCII import paths
+ 2021-01-07 fa90aaca7d cmd/compile: fix late expand_calls leaf type for OpStructSelect/OpArraySelect
+ 2021-01-07 7cee66d4cb cmd/go: add documentation for Embed fields in go list output
+ 2021-01-07 e60cffa4ca html/template: attach functions to namespace
+ 2021-01-07 6da2d3b7d7 cmd/link: fix typo in asm.go
+ 2021-01-07 df81a15819 runtime: check mips64 VDSO clock_gettime return code
+ 2021-01-06 4787e906cf crypto/x509: rollback new CertificateRequest fields
+ 2021-01-06 c9658bee93 cmd/go: make module suggestion more friendly
+ 2021-01-06 4c668b25c6 runtime/metrics: fix panic message for Float64Histogram
+ 2021-01-06 d2131704a6 net/http/httputil: fix deadlock in DumpRequestOut
+ 2021-01-05 3e1e13ce6d cmd/go: set cfg.BuildMod to "readonly" by default with no module root
+ 2021-01-05 0b0d004983 cmd/go: pass embedcfg to gccgo if supported
+ 2021-01-05 1b85e7c057 cmd/go: don't scan gccgo standard library packages for imports
+ 2021-01-05 6b37b15d95 runtime: don't take allglock in tracebackothers
+ 2021-01-04 9eef49cfa6 math/rand: fix typo in comment
+ 2021-01-04 b01fb2af9e testing/fstest: fix typo in error message
+ 2021-01-01 3dd5867605 doc: 2021 is the Year of the Gopher
+ 2020-12-31 95ce805d14 io/fs: remove darwin/arm64 special condition
+ 2020-12-30 20d0991b86 lib/time, time/tzdata: update tzdata to 2020f
+ 2020-12-30 ed301733bb misc/cgo/testcarchive: remove special flags for Darwin/ARM
+ 2020-12-30 0ae2e032f2 misc/cgo/test: enable TestCrossPackageTests on darwin/arm64
+ 2020-12-29 780b4de16b misc/ios: fix wording for command line instructions
+ 2020-12-29 b4a71c95d2 doc/go1.16: reference misc/ios/README for how to build iOS programs
+ 2020-12-29 f83e0f6616 misc/ios: add to README how to build ios executables
+ 2020-12-28 4fd9455882 io/fs: fix typo in comment
Change-Id: If24bb93f1e1e7deb1d92ba223c85940ab93b2732
This merge had two conflicts to resolve:
1. The embed code on master had somewhat substantially diverged, so
this CL tediously backported the changes to dev.regabi. In particular,
I went through all of the embed changes to gc/{embed,noder,syntax}.go
and made sure the analogous code on dev.regabi in noder/noder.go and
staticdata/embed.go mirrors it.
2. The init-cycle reporting code on master was extended slightly to
track already visited declarations to avoid exponential behavior. The
same fix is applied on dev.regabi, just using ir.NameSet instead of
map[ir.Node]bool.
Conflicts:
- src/cmd/compile/internal/gc/embed.go
- src/cmd/compile/internal/gc/noder.go
- src/cmd/compile/internal/gc/syntax.go
- src/cmd/compile/internal/pkginit/initorder.go
- src/embed/internal/embedtest/embed_test.go
- src/go/types/stdlib_test.go
Merge List:
+ 2021-01-22 dab3e5affe runtime: switch runtime to libc for openbsd/amd64
+ 2021-01-22 a1b53d85da cmd/go: add documentation for test and xtest fields output by go list
+ 2021-01-22 b268b60774 runtime: remove pthread_kill/pthread_self for openbsd
+ 2021-01-22 ec4051763d runtime: fix typo in mgcscavenge.go
+ 2021-01-22 7ece3a7b17 net/http: fix flaky TestDisableKeepAliveUpgrade
+ 2021-01-22 50cba0506f time: clarify Timer.Reset behavior on AfterFunc Timers
+ 2021-01-22 cf10e69f17 doc/go1.16: mention net/http.Transport.GetProxyConnectHeader
+ 2021-01-22 ec1b945265 doc/go1.16: mention path/filepath.WalkDir
+ 2021-01-22 11def3d40b doc/go1.16: mention syscall.AllThreadsSyscall
+ 2021-01-21 07b0235609 doc/go1.16: add notes about package-specific fs.FS changes
+ 2021-01-21 e2b4f1fea5 doc/go1.16: minor formatting fix
+ 2021-01-21 9f43a9e07b doc/go1.16: mention new debug/elf constants
+ 2021-01-21 3c2f11ba5b cmd/go: overwrite program name with full path
+ 2021-01-21 953d1feca9 all: introduce and use internal/execabs
+ 2021-01-21 b186e4d70d cmd/go: add test case for cgo CC setting
+ 2021-01-21 5a8a2265fb cmd/cgo: report exec errors a bit more clearly
+ 2021-01-21 46e2e2e9d9 cmd/go: pass resolved CC, GCCGO to cgo
+ 2021-01-21 3d40895e36 runtime: switch openbsd/arm64 to pthreads
+ 2021-01-21 d95ca91380 crypto/elliptic: fix P-224 field reduction
+ 2021-01-20 ecf4ebf100 cmd/internal/moddeps: check content of all modules in GOROOT
+ 2021-01-20 d2d155d1ae runtime: don't adjust timer pp field in timerWaiting status
+ 2021-01-20 803d18fc6c cmd/go: set Incomplete field on go list output if no files match embed
+ 2021-01-20 6e243ce71d cmd/go: have go mod vendor copy embedded files in subdirs
+ 2021-01-20 be28e5abc5 cmd/go: fix mod_get_fallback test
+ 2021-01-20 928bda4f4a runtime: convert openbsd/amd64 locking to libc
+ 2021-01-19 824f2d635c cmd/go: allow go fmt to complete when embedded file is missing
+ 2021-01-19 0575e35e50 cmd/compile: require 'go 1.16' go.mod line for //go:embed
+ 2021-01-19 ccb2e90688 cmd/link: exit before Asmb2 if error
+ 2021-01-19 ca5774a5a5 embed: treat uninitialized FS as empty
+ 2021-01-19 d047c91a6c cmd/link,runtime: switch openbsd/amd64 to pthreads
+ 2021-01-19 61debffd97 runtime: factor out usesLibcall
+ 2021-01-19 9fed39d281 runtime: factor out mStackIsSystemAllocated
+ 2021-01-18 dbab079835 runtime: free Windows event handles after last lock is dropped
+ 2021-01-18 5a8fbb0d2d os: do not close syscall.Stdin in TestReadStdin
+ 2021-01-15 682a1d2176 runtime: detect errors in DuplicateHandle
+ 2021-01-15 9f83418b83 cmd/link: remove GOROOT write in TestBuildForTvOS
+ 2021-01-15 ec9470162f cmd/compile: allow embed into any string or byte slice type
+ 2021-01-15 54198b04db cmd/compile: disallow embed of var inside func
+ 2021-01-15 b386c735e7 cmd/go: fix go generate docs
+ 2021-01-15 bb5075a525 syscall: remove RtlGenRandom and move it into internal/syscall
+ 2021-01-15 1deae0b597 os: invoke processKiller synchronously in testKillProcess
+ 2021-01-15 ff196c3e84 crypto/x509: update iOS bundled roots to version 55188.40.9
+ 2021-01-14 e125ccd10e cmd/go: in 'go mod edit', validate versions given to -retract and -exclude
+ 2021-01-14 eb330020dc cmd/dist, cmd/go: pass -arch for C compilation on Darwin
+ 2021-01-14 84e8a06f62 cmd/cgo: remove unnecessary space in cgo export header
+ 2021-01-14 0c86b999c3 cmd/test2json: document passing -test.paniconexit0
+ 2021-01-14 9135795891 cmd/go/internal/load: report positions for embed errors
+ 2021-01-14 d9b79e53bb cmd/compile: fix wrong complement for arm64 floating-point comparisons
+ 2021-01-14 c73232d08f cmd/go/internal/load: refactor setErrorPos to PackageError.setPos
+ 2021-01-14 6aa28d3e06 go/build: report positions for go:embed directives
+ 2021-01-13 7eb31d999c cmd/go: add hints to more missing sum error messages
+ 2021-01-12 ba76567bc2 cmd/go/internal/modload: delete unused *mvsReqs.next method
+ 2021-01-12 665def2c11 encoding/asn1: document unmarshaling behavior for IMPLICIT string fields
+ 2021-01-11 81ea89adf3 cmd/go: fix non-script staleness checks interacting badly with GOFLAGS
+ 2021-01-11 759309029f doc: update editors.html for Go 1.16
+ 2021-01-11 c3b4c7093a cmd/internal/objfile: don't require runtime.symtab symbol for XCOFF
+ 2021-01-08 59bfc18e34 cmd/go: add hint to read 'go help vcs' to GOVCS errors
+ 2021-01-08 cd6f3a54e4 cmd/go: revise 'go help' documentation for modules
+ 2021-01-08 6192b98751 cmd/go: make hints in error messages more consistent
+ 2021-01-08 25886cf4bd cmd/go: preserve sums for indirect deps fetched by 'go mod download'
+ 2021-01-08 6250833911 runtime/metrics: mark histogram metrics as cumulative
+ 2021-01-08 8f6a9acbb3 runtime/metrics: remove unused StopTheWorld Description field
+ 2021-01-08 6598c65646 cmd/compile: fix exponential-time init-cycle reporting
+ 2021-01-08 fefad1dc85 test: fix timeout code for invoking compiler
+ 2021-01-08 6728118e0a cmd/go: pass signals forward during "go tool"
+ 2021-01-08 e65c543f3c go/build/constraint: add parser for build tag constraint expressions
+ 2021-01-08 0c5afc4fb7 testing/fstest,os: clarify racy behavior of TestFS
+ 2021-01-08 32afcc9436 runtime/metrics: change unit on *-by-size metrics to match bucket unit
+ 2021-01-08 c6513bca5a io/fs: minor corrections to Glob doc
+ 2021-01-08 304f769ffc cmd/compile: don't short-circuit copies whose source is volatile
+ 2021-01-08 ae97717133 runtime,runtime/metrics: use explicit histogram boundaries
+ 2021-01-08 a9ccd2d795 go/build: skip string literal while findEmbed
+ 2021-01-08 d92f8add32 archive/tar: fix typo in comment
+ 2021-01-08 cab1202183 cmd/link: accept extra blocks in TestFallocate
+ 2021-01-08 ee4d32249b io/fs: minor corrections to Glob release date
+ 2021-01-08 54bd1ccce2 cmd: update to latest golang.org/x/tools
+ 2021-01-07 9ec21a8f34 Revert "reflect: support multiple keys in struct tags"
+ 2021-01-07 091414b5b7 io/fs: correct WalkDirFunc documentation
+ 2021-01-07 9b55088d6b doc/go1.16: add release note for disallowing non-ASCII import paths
+ 2021-01-07 fa90aaca7d cmd/compile: fix late expand_calls leaf type for OpStructSelect/OpArraySelect
+ 2021-01-07 7cee66d4cb cmd/go: add documentation for Embed fields in go list output
+ 2021-01-07 e60cffa4ca html/template: attach functions to namespace
+ 2021-01-07 6da2d3b7d7 cmd/link: fix typo in asm.go
+ 2021-01-07 df81a15819 runtime: check mips64 VDSO clock_gettime return code
+ 2021-01-06 4787e906cf crypto/x509: rollback new CertificateRequest fields
+ 2021-01-06 c9658bee93 cmd/go: make module suggestion more friendly
+ 2021-01-06 4c668b25c6 runtime/metrics: fix panic message for Float64Histogram
+ 2021-01-06 d2131704a6 net/http/httputil: fix deadlock in DumpRequestOut
+ 2021-01-05 3e1e13ce6d cmd/go: set cfg.BuildMod to "readonly" by default with no module root
+ 2021-01-05 0b0d004983 cmd/go: pass embedcfg to gccgo if supported
+ 2021-01-05 1b85e7c057 cmd/go: don't scan gccgo standard library packages for imports
+ 2021-01-05 6b37b15d95 runtime: don't take allglock in tracebackothers
+ 2021-01-04 9eef49cfa6 math/rand: fix typo in comment
+ 2021-01-04 b01fb2af9e testing/fstest: fix typo in error message
+ 2021-01-01 3dd5867605 doc: 2021 is the Year of the Gopher
+ 2020-12-31 95ce805d14 io/fs: remove darwin/arm64 special condition
+ 2020-12-30 20d0991b86 lib/time, time/tzdata: update tzdata to 2020f
+ 2020-12-30 ed301733bb misc/cgo/testcarchive: remove special flags for Darwin/ARM
+ 2020-12-30 0ae2e032f2 misc/cgo/test: enable TestCrossPackageTests on darwin/arm64
+ 2020-12-29 780b4de16b misc/ios: fix wording for command line instructions
+ 2020-12-29 b4a71c95d2 doc/go1.16: reference misc/ios/README for how to build iOS programs
+ 2020-12-29 f83e0f6616 misc/ios: add to README how to build ios executables
+ 2020-12-28 4fd9455882 io/fs: fix typo in comment
Change-Id: I2f257bbc5fbb05f15c2d959f8cfe0ce13b083538
The types2.Config.IgnoreBranches flag mistakenly excluded a
set of label-unrelated branch checks. After fixing this and
also adjusting some error messages to match the existing
compiler errors, more errorcheck tests pass now with the -G
option.
Renamed IngnoreBranches to IgnoreLabels since its controlling
label checks, not all branch statement (such as continue, etc)
checks.
Change-Id: I0819f56eb132ce76c9a9628d8942af756691065a
Reviewed-on: https://go-review.googlesource.com/c/go/+/285652
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
I have exporting, importing, and inlining of functions with closures
working in all cases (issue #28727). all.bash runs successfully without
errors.
Approach:
- Write out the Func type, Dcls, ClosureVars, and Body when exporting
an OCLOSURE.
- When importing an OCLOSURE, read in the type, dcls, closure vars,
and body, and then do roughly equivalent code to (*noder).funcLit
- During inlining of a closure within inlined function, create new
nodes for all params and local variables (including closure
variables), so they can have a new Curfn and some other field
values. Must substitute not only on the Nbody of the closure, but
also the Type, Cvars, and Dcl fields.
Fixes#28727
Change-Id: I4da1e2567c3fa31a5121afbe82dc4e5ee32b3170
Reviewed-on: https://go-review.googlesource.com/c/go/+/283112
Run-TryBot: 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>
Trust: Dan Scales <danscales@google.com>
With this CL, the type reported for uses of the predeclared
identifier nil changes from untyped nil to the type of the
context within which nil is used, matching the behaviour of
types2 for other untyped types.
If an untyped nil value is assigned or converted to an
interface, the nil expression is given the interface type.
The predicate TypeAndValue.IsNil doesn't change in behavior,
it still reports whether the relevant expression is a (typed
or untyped) nil value.
Change-Id: Id766468f3f3f2a53e4c55e1e6cd521e459c4a94f
Reviewed-on: https://go-review.googlesource.com/c/go/+/284218
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This will produce better errors when earlier versions of
Go compile code using //go:embed. (The import will cause
a compilation error but then the go command will add to
the output that the Go toolchain in use looks too old
and maybe that's the problem.)
This CL also adds a test for disallowing embed of a var inside a func.
It's a bit too difficult to rebase down into that CL.
The build system configuration check is delayed in order to
make it possible to use errorcheck for these tests.
Change-Id: I12ece4ff2d8d53380b63f54866e8f3497657d54c
Reviewed-on: https://go-review.googlesource.com/c/go/+/282718
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Now that TailCallStmt carries an *ir.Name instead of a *types.Sym,
callTargetLSym can be similarly updated to take the target function as
an *ir.Name.
This inches us closer towards being able to move Linksym and other
properties from *types.Sym to *ir.Name, where they belong.
Passes toolstash -cmp w/ -gcflags=all=-abiwrap.
Change-Id: I091da290751970eba8ed0438f66d6cca88b665a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/284228
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Currently, typecheck leaves arguments to OPANIC as their original
type. This CL changes it to insert implicit OCONVIFACE operations to
convert arguments to `interface{}` like how any other function call
would be handled.
No immediate benefits, other than getting to remove a tiny bit of
special-case logic in order.go's handling of OPANICs. Instead, the
generic code path for handling OCONVIFACE is used, if necessary.
Longer term, this should be marginally helpful for #43753, as it
reduces the number of cases where we need values to be addressable for
runtime calls.
However, this does require adding some hacks to appease existing
tests:
1. We need yet another kludge in inline budgeting, to ensure that
reflect.flag.mustBe stays inlinable for cmd/compile/internal/test's
TestIntendedInlining.
2. Since the OCONVIFACE expressions are now being introduced during
typecheck, they're now visible to escape analysis. So expressions like
"panic(1)" are now seen as "panic(interface{}(1))", and escape
analysis warns that the "interface{}(1)" escapes to the heap. These
have always escaped to heap, just now we're accurately reporting about
it.
(Also, unfortunately fmt.go hides implicit conversions by default in
diagnostics messages, so instead of reporting "interface{}(1) escapes
to heap", it actually reports "1 escapes to heap", which is
confusing. However, this confusing messaging also isn't new.)
Change-Id: Icedf60e1d2e464e219441b8d1233a313770272af
Reviewed-on: https://go-review.googlesource.com/c/go/+/284412
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Matthew Dempsky <mdempsky@google.com>
Currently, to ensure OAS2FUNC results are assigned in the correct
order, they're always assigned to temporary variables. However, these
temporary variables are typed based on the destination type, which may
require an interface conversion. This means walk may have to then
introduce a second set of temporaries to ensure result parameters are
all copied out of the results area, before it emits calls to runtime
conversion functions.
That's just silly. Instead, this CL changes order to allocate the
result temporaries with the same type as the function returns in the
first place, and then assign them one at a time to their destinations,
with conversions as needed.
While here, also fix an order-of-evaluation issue with has-ok
assignments that I almost added to multi-value function call
assignments, and add tests for each.
Change-Id: I9f4e962425fe3c5e3305adbbfeae2c7f253ec365
Reviewed-on: https://go-review.googlesource.com/c/go/+/284220
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>
We decide during escape analysis whether to pass closure variables by
value or reference. One of the factors that's considered is whether a
variable has had its address taken.
However, this analysis is based only on the user-written source code,
whereas order+walk may introduce rewrites that take the address of a
variable (e.g., passing a uint16 key by reference to the size-generic
map runtime builtins).
Typically this would be harmless, albeit suboptimal. But in #43701 it
manifested as needing a stack object for a function where we didn't
realize we needed one up front when we generate symbols.
Probably we should just generate symbols on demand, now that those
routines are all concurrent-safe, but this is a first fix.
Thanks to Alberto Donizetti for reporting the issue, and Cuong Manh Le
for initial investigation.
Fixes#43701.
Change-Id: I16d87e9150723dcb16de7b43f2a8f3cd807a9437
Reviewed-on: https://go-review.googlesource.com/c/go/+/284075
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>
The feature being tested is insensitive to the OS anyway.
Change-Id: Ieac9bfaafc6a54c00017afcc0b87bd8bbe80af7b
Reviewed-on: https://go-review.googlesource.com/c/go/+/284032
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Consider the following example,
func test(a, b float64, x uint64) uint64 {
if a < b {
x = 0
}
return x
}
func main() {
fmt.Println(test(1, math.NaN(), 123))
}
The output is 0, but the expectation is 123.
This is because the rewrite rule
(CSEL [cc] (MOVDconst [0]) y flag) => (CSEL0 [arm64Negate(cc)] y flag)
converts
FCMP NaN, 1
CSEL MI, 0, 123, R0 // if 1 < NaN then R0 = 0 else R0 = 123
to
FCMP NaN, 1
CSEL GE, 123, 0, R0 // if 1 >= NaN then R0 = 123 else R0 = 0
But both 1 < NaN and 1 >= NaN are false. So the output is 0, not 123.
The root cause is arm64Negate not handle negation of floating comparison
correctly. According to the ARM manual, the meaning of MI, GE, and PL
are
MI: Less than
GE: Greater than or equal to
PL: Greater than, equal to, or unordered
Because NaN cannot be compared with other numbers, the result of such
comparison is unordered. So when NaN is involved, unlike integer, the
result of !(a < b) is not a >= b, it is a >= b || a is NaN || b is NaN.
This is exactly what PL means. We add NotLessThanF to represent PL. Then
the negation of LessThanF is NotLessThanF rather than GreaterEqualF. The
same reason for the other floating comparison operations.
Fixes#43619
Change-Id: Ia511b0027ad067436bace9fbfd261dbeaae01bcd
Reviewed-on: https://go-review.googlesource.com/c/go/+/283572
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Keith Randall <khr@golang.org>
CL 278914 introduced NameOffsetExpr to avoid copying ONAME nodes and
hacking up their offsets, but evidently staticinit subtly depended on
the prior behavior to allow dynamic initialization of blank variables.
This CL refactors the code somewhat to avoid using NameOffsetExpr with
blank variables, and to instead create dynamic assignments directly to
the global blank node. It also adds a check to NewNameOffsetExpr to
guard against misuse like this, since I suspect there could be other
cases still lurking within staticinit. (This code is overdue for an
makeover anyway.)
Thanks to thanm@ for bisect and test case minimization.
Fixes#43677.
Change-Id: Ic71cb5d6698382feb9548dc3bb9fd606b207a172
Reviewed-on: https://go-review.googlesource.com/c/go/+/283537
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
This only works for functions; if you try it with a method, it will
fail. It does work for both local package and imports. For now,
it tells you when it thinks it sees either a declaration or a call of
such a function (this will normally be silent since no existing
code uses this pragma).
Note: it appears to be really darn hard to figure out if this
pragma was set for a method, and the method's call site. Better
ir.Node wranglers than I might be able to make headway, but it
seemed unnecessary for this experiment.
Change-Id: I601c2ddd124457bf6d62f714d7ac871705743c0a
Reviewed-on: https://go-review.googlesource.com/c/go/+/279521
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
This is intended to make it easier to write/change a test
without referring to the source code to figure out what the
error messages actually mean, or how to correct them.
Change-Id: Ie79ff7cd9f2d1fa605257fe97eace68adc8a6716
Reviewed-on: https://go-review.googlesource.com/c/go/+/281452
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Current many architectures use a rule along the lines of
// Canonicalize the order of arguments to comparisons - helps with CSE.
((CMP|CMPW) x y) && x.ID > y.ID => (InvertFlags ((CMP|CMPW) y x))
to normalize comparisons as much as possible for CSE. Replace the
ID comparison with something less variable across compiler changes.
This helps avoid spurious failures in some of the codegen-comparison
tests (though the current choice of comparison is sensitive to Op
ordering).
Two tests changed to accommodate modified instruction choice.
Change-Id: Ib35f450bd2bae9d4f9f7838ceaf7ec682bcf1e1a
Reviewed-on: https://go-review.googlesource.com/c/go/+/280155
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The compiler currently has two modes for compilation: one where it
compiles each function as it sees them, and another where it enqueues
them all into a work queue. A subsequent CL is going to reorder
function compilation to ensure that functions are always compiled
before any non-trivial function literals they enclose, and this will
be easier if we always use the compile work queue.
Also, fewer compilation modes makes things simpler to reason about.
Change-Id: Ie090e81f7476c49486296f2b90911fa0a466a5dd
Reviewed-on: https://go-review.googlesource.com/c/go/+/283313
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Historically, inline function bodies were exported as plain Go source
code, and symbol mangling was a convenient hack because it allowed
variables to be re-imported with largely the same names as they were
originally exported as.
However, nowadays we use a binary format that's more easily extended,
so we can simply serialize all of a function's declared objects up
front, and then refer to them by index later on. This also allows us
to easily report unmangled names all the time (e.g., error message
from issue7921.go).
Fixes#43633.
Change-Id: I46c88f5a47cb921f70ab140976ba9ddce38df216
Reviewed-on: https://go-review.googlesource.com/c/go/+/283193
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Trust: Dan Scales <danscales@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
This CL refactors noder's package import logic so it's easier to reuse
with types2 and gcimports. In particular, this allows the types2
integration to now support vendored packages.
Change-Id: I1fd98ad612b4683d2e1ac640839e64de1fa7324b
Reviewed-on: https://go-review.googlesource.com/c/go/+/282919
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Currently, during walk we rewrite PAUTOHEAP uses into derefs of their
corresponding Heapaddr, but we can easily do this instead during SSA
construction. This does involve updating two test cases:
* nilptr3.go
This file had a test that we emit a "removed nil check" diagnostic for
the implicit dereference from accessing a PAUTOHEAP variable. This CL
removes this diagnostic, since it's not really useful to end users:
from the user's point of view, there's no pointer anyway, so they
needn't care about whether we check for nil or not. That's a purely
internal detail. And with the PAUTOHEAP dereference handled during SSA
construction, we can more robustly ensure this happens, rather than
relying on setting a flag in walk and hoping that SSA sees it.
* issue20780.go
Previously, when PAUTOHEAPs were dereferenced during walk, it had a
consequence that when they're passed as a function call argument, they
would first get copied to the stack before being copied to their
actual destination. Moving the dereferencing to SSA had a side-effect
of eliminating this unnecessary temporary, and copying directly to the
destination parameter.
The test is updated to instead call "g(h(), h())" where h() returns a
large value, as the first result will always need to be spilled
somewhere will calling the second function. Maybe eventually we're
smart enough to realize it can be spilled to the heap, but we don't do
that today.
Because I'm concerned that the direct copy-to-parameter optimization
could interfere with race-detector instrumentation (e.g., maybe the
copies were previously necessary to ensure they're not clobbered by
inserted raceread calls?), I've also added issue20780b.go to exercise
this in a few different ways.
Change-Id: I720598cb32b17518bc10a03e555620c0f25fd28d
Reviewed-on: https://go-review.googlesource.com/c/go/+/281293
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
I have a real 7,000-line Go program (not so big)
that took over two minutes to report a trivial init cycle.
I thought the compiler was in an infinite loop but
it was actually just very slow.
CL 170062 rewrote init cycle reporting but replaced
a linear-time algorithm with an exponential one:
it explores all paths through the call graph of functions
involved in the cycle.
The net effect was that Go 1.12 took 0.25 seconds to load,
typecheck, and then diagnose the cycle in my program,
while Go 1.13 takes 600X longer.
This CL makes the new reporting code run in linear time,
restoring the speed of Go 1.12 but preserving the semantic
fixes from CL 170062.
Change-Id: I7d6dc95676d577d9b96f5953b516a64db93249bf
Reviewed-on: https://go-review.googlesource.com/c/go/+/282314
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
When running go tool compile,
go tool is running compile as a subprocess.
Killing go tool with Process.Kill leaves the subprocess behind.
Send an interrupt signal first, which it can forward on
to the compile subprocess.
Also report the timeout in errorcheck -t.
Change-Id: I7ae0029bbe543ed7e60e0fea790dd0739d10bcaa
Reviewed-on: https://go-review.googlesource.com/c/go/+/282313
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Current optimization: When we copy a->b and then b->c, we might as well
copy a->c instead of b->c (then b might be dead and go away).
*Except* if a is a volatile location (might be clobbered by a call).
In that case, we really do want to copy a immediately, because there
might be a call before we can do the a->c copy.
User calls can't happen in between, because the rule matches up the
memory states. But calls inserted for memory barriers, particularly
runtime.typedmemmove, can.
(I guess we could introduce a register-calling-convention version
of runtime.typedmemmove, but that seems a bigger change than this one.)
Fixes#43570
Change-Id: Ifa518bb1a6f3a8dd46c352d4fd54ea9713b3eb1a
Reviewed-on: https://go-review.googlesource.com/c/go/+/282492
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>
For the example in #43551, before late call expansion, the OpArg type is
decomposed to int64. But the late call expansion is currently decompose
it to "x.Key" instead.
This CL make expand_calls decompose further for struct { 1-field type }
and array [1]elem.
This matches the previous rules for early decompose args:
(StructSelect (StructMake1 x)) => x
(ArraySelect (ArrayMake1 x)) => x
Fixes#43551
Change-Id: I2f1ebe18cb81cb967f494331c3d237535d2859e7
Reviewed-on: https://go-review.googlesource.com/c/go/+/282332
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: David Chase <drchase@google.com>
Now that CaptureVars is gone, we can remove the extra code in escape
analysis that only served to appease toolstash -cmp.
Change-Id: I8c811834f3d966e76702e2d362e3de414c94bea6
Reviewed-on: https://go-review.googlesource.com/c/go/+/281544
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>
Currently we rely on the type-checker to do some basic data-flow
analysis to help decide whether function literals should capture
variables by value or reference. However, this analysis isn't done by
go/types, and escape analysis already has a better framework for doing
this more precisely.
This CL extends escape analysis to recalculate the same "byval" as
CaptureVars and check that it matches. A future CL will remove
CaptureVars in favor of escape analysis's calculation.
Notably, escape analysis happens after deadcode removes obviously
unreachable code, so it sees the AST without any unreachable
assignments. (Also without unreachable addrtakens, but
ComputeAddrtaken already happens after deadcode too.) There are two
test cases where a variable is only reassigned on certain CPUs. This
CL changes them to reassign the variables unconditionally (as no-op
reassignments that avoid triggering cmd/vet's self-assignment check),
at least until we remove CaptureVars.
Passes toolstash -cmp.
Change-Id: I7162619739fedaf861b478fb8d506f96a6ac21f3
Reviewed-on: https://go-review.googlesource.com/c/go/+/281535
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>
The gc implementation has had precise GC for a while now, so we can
enable these tests more broadly.
Confirmed that they still fail with gccgo 10.2.1.
Change-Id: Ic1c0394ab832024a99e34163c422941a3706e1a2
Reviewed-on: https://go-review.googlesource.com/c/go/+/281542
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>
When exporting signature types, we include the originating package,
because it's exposed via go/types's API. And as a consistency check,
we ensure that the parameter names came from that same package.
However, we were getting this wrong in the case of exported variables
that were initialized with a method value using an imported method. In
this case, when we created the method value wrapper function's
type (which is reused as the variable's type if none is explicitly
provided in the variable declaration), we were reusing the
original (i.e., imported) parameter names, but the newly created
signature type was associated with the current package instead.
The correct fix here is really to preserve the original signature
type's package (along with position and name for its parameters), but
that's awkward to do at the moment because the DeclFunc API requires
an ir representation of the function signature, whereas we only
provide a way to explicitly set packages via the type constructor
APIs.
As an interim fix, we associate the parameters with the current
package, to be consistent with the signature type's package.
Fixes#43479.
Change-Id: Id45a10f8cf64165c9bc7d9598f0a0ee199a5e752
Reviewed-on: https://go-review.googlesource.com/c/go/+/281292
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>
It's an error to call Int64Val on constants that don't fit into
int64. CL 272654 made the compiler stricter about detecting misuse,
and revealed that we were using it improperly in detecting consecutive
integer-switch cases. That particular usage actually did work in
practice, but it's easy and best to just fix it.
Fixes#43480.
Change-Id: I56f722d75e83091638ac43b80e45df0b0ad7d48d
Reviewed-on: https://go-review.googlesource.com/c/go/+/281272
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>
After the previous cleanup/optimization CLs, ascompatee now correctly
handles map assignments too. So remove the code from order.mapAssign,
which causes us to assign to the map at the wrong point during
execution. It's not every day you get to fix an issue by only removing
code.
Thanks to Cuong Manh Le for test cases and continually following up on
this issue.
Passes toolstash -cmp. (Apparently the standard library never uses
tricky map assignments. Go figure.)
Fixes#23017.
Change-Id: Ie0728103d59d884d00c1c050251290a2a46150f9
Reviewed-on: https://go-review.googlesource.com/c/go/+/281172
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>
When deciding whether a captured variable can be passed by value, the
compiler is sensitive to the order that the OCLOSURE node is
typechecked relative to the order that the variable is passed to
"checkassign". Today, for an assignment like:
q, g = 2, func() int { return q }
we get this right because we always typecheck the full RHS expression
list before calling checkassign on any LHS expression.
But I nearly made a change that would interleave this ordering,
causing us to call checkassign on q before typechecking the function
literal. And alarmingly, there weren't any tests that caught this.
So this commit adds one.
Change-Id: I66cacd61066c7a229070861a7d973bcc434904cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/280998
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>
This CL fixes package initialization order by creating the init task
before the general deadcode-removal pass.
It also changes noder to emit zero-initialization assignments (i.e.,
OAS with nil RHS) for package-block variables, so that initOrder can
tell the variables still need initialization. To allow this, we need
to also extend the static-init code to recognize zero-initialization
assignments.
This doesn't pass toolstash -cmp, because it reorders some package
initialization routines.
Fixes#43444.
Change-Id: I0da7996a62c85e15e97ce965298127e075390a7e
Reviewed-on: https://go-review.googlesource.com/c/go/+/280976
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>
OTYPE and OMETHEXPR were missing from OpPrec. So add them with the
same precedences as OT{ARRAY,MAP,STRUCT,etc} and
ODOT{,METH,INTER,etc}, respectively. However, ODEREF (which is also
used for pointer types *T) has a lower precedence than other types, so
pointer types need to be specially handled to assign them their
correct, lower precedence.
Incidentally, this also improves the error messages in issue15055.go,
where we were adding unnecessary parentheses around the types in
conversion expressions.
Thanks to Cuong Manh Le for writing the test cases for #43428.
Fixes#43428.
Change-Id: I57e7979babe3ed9ef8a8b5a2a3745e3737dd785f
Reviewed-on: https://go-review.googlesource.com/c/go/+/280873
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>
The compiler has logic to check whether we implicitly dereferenced a
defined pointer while trying to select a method. However, rather than
checking whether there were any implicit dereferences of a defined
pointer, it was finding the innermost dereference/selector expression
and checking whether that was dereferencing a named pointer. Moreover,
it was only checking defined pointer declared in the package block.
This CL restructures the code to match go/types and gccgo's behavior.
Fixes#43384.
Change-Id: I7bddfe2515776d9480eb2c7286023d4c15423888
Reviewed-on: https://go-review.googlesource.com/c/go/+/280392
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
ODOTMETH is unique among SelectorExpr expressions, in that Sel gets
mangled so that it no longer has the original identifier that was
selected (e.g., just "Foo"), but instead the qualified symbol name for
the selected method (e.g., "pkg.Type.Foo"). This is rarely useful, and
instead results in a lot of compiler code needing to worry about
undoing this change.
This CL changes ODOTMETH to leave the original symbol in place. The
handful of code locations where the mangled symbol name is actually
wanted are updated to use ir.MethodExprName(n).Sym() or (equivalently)
ir.MethodExprName(n).Func.Sym() instead.
Historically, the compiler backend has mistakenly used types.Syms
where it should have used ir.Name/ir.Funcs. And this change in
particular may risk breaking something, as the SelectorExpr.Sel will
no longer point at a symbol that uniquely identifies the called
method. However, I expect CL 280294 (desugar OCALLMETH into OCALLFUNC)
to have substantially reduced this risk, as ODOTMETH expressions are
now replaced entirely earlier in the compiler.
Passes toolstash -cmp.
Change-Id: If3c9c3b7df78ea969f135840574cf89e1d263876
Reviewed-on: https://go-review.googlesource.com/c/go/+/280436
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>
The assignment type-checking code previously bounced around a lot
between the LHS and RHS sides of the assignment. But there's actually
a very simple, consistent pattern to how to type check assignments:
1. Check the RHS expression.
2. If the LHS expression is an identifier that was declared in this
statement and it doesn't have an explicit type, give it the RHS
expression's default type.
3. Check the LHS expression.
4. Try assigning the RHS expression to the LHS expression, adding
implicit conversions as needed.
This CL implements this algorithm, and refactors tcAssign and
tcAssignList to use a common implementation. It also fixes the error
messages to consistently say just "1 variable" or "1 value", rather
than occasionally "1 variables" or "1 values".
Fixes#43348.
Passes toolstash -cmp.
Change-Id: I749cb8d6ccbc7d22cd7cb0a381f58a39fc2696b5
Reviewed-on: https://go-review.googlesource.com/c/go/+/280112
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>
In issue11656.go, it tests that if the runtime can get a
reasonable traceback when it faults at a non-function PC. It does
it by jumping to an address that contains an illegal or trap
instruction. When it traps, the SIGTRAP crashes the runtime.
This CL changes it to use an instruction that triggers SIGSEGV.
This is due to two reasons:
- currently, the handling of bad PC is done by preparePanic,
which is only used for a panicking signal (SIGSEGV, SIGBUS,
SIGFPE), not a fatal signal (e.g. SIGTRAP).
- the test uses defer+recover to get a traceback, which only
works for panicking signals, not fatal signals.
Ideally, we should handle all kinds of faults (SIGSEGV, SIGBUS,
SIGILL, SIGTRAP, etc.) with a nice traceback. I'll leave this
for the future.
This CL also adds RISCV64 support.
Fixes#43283.
Change-Id: I5e0fbf8530cc89d16e05c3257d282bc1d4d03405
Reviewed-on: https://go-review.googlesource.com/c/go/+/279423
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Add compiler support for emitting ABI wrappers by creating real IR as
opposed to introducing ABI aliases. At the moment these are "no-op"
wrappers in the sense that they make a simple call (using the existing
ABI) to their target. The assumption here is that once late call
expansion can handle both ABI0 and the "new" ABIInternal (register
version), it can expand the call to do the right thing.
Note that the runtime contains functions that do not strictly follow
the rules of the current Go ABI0; this has been handled in most cases
by treating these as ABIInternal instead (these changes have been made
in previous patches).
Generation of ABI wrappers (as opposed to ABI aliases) is currently
gated by GOEXPERIMENT=regabi -- wrapper generation is on by default if
GOEXPERIMENT=regabi is set and off otherwise (but can be turned on
using "-gcflags=all=-abiwrap -ldflags=-abiwrap"). Wrapper generation
currently only workd on AMD64; explicitly enabling wrapper for other
architectures (via the command line) is not supported.
Also in this patch are a few other command line options for debugging
(tracing and/or limiting wrapper creation). These will presumably go
away at some point.
Updates #27539, #40724.
Change-Id: I1ee3226fc15a3c32ca2087b8ef8e41dbe6df4a75
Reviewed-on: https://go-review.googlesource.com/c/go/+/270863
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Than McIntosh <thanm@google.com>
The files below had conflicts that required manual resolution.
The unresolved conflict in noder.go was just in the import
declaration (trivial). All the other conflicts are in tests
where the ERROR regex patterns changed to accomodate gccgo
error messages (incoming from dev.regabi), and to accomodate
types2 in dev.typeparams. They were resolved by accepting the
dev.regabi changes (so as not to lose them) and then by re-
applying whatever changes needed to make them pass with types2.
Finally, the new test mainsig.go was excluded from run.go when
using types2 due to issue #43308.
src/cmd/compile/internal/gc/noder.go
test/fixedbugs/bug13343.go
test/fixedbugs/bug462.go
test/fixedbugs/issue10975.go
test/fixedbugs/issue11326.go
test/fixedbugs/issue11361.go
test/fixedbugs/issue11371.go
test/fixedbugs/issue11674.go
test/fixedbugs/issue13365.go
test/fixedbugs/issue13471.go
test/fixedbugs/issue14136.go
test/fixedbugs/issue14321.go
test/fixedbugs/issue14729.go
test/fixedbugs/issue15898.go
test/fixedbugs/issue16439.go
test/fixedbugs/issue17588.go
test/fixedbugs/issue19323.go
test/fixedbugs/issue19482.go
test/fixedbugs/issue19880.go
test/fixedbugs/issue20185.go
test/fixedbugs/issue20227.go
test/fixedbugs/issue20415.go
test/fixedbugs/issue20749.go
test/fixedbugs/issue22794.go
test/fixedbugs/issue22822.go
test/fixedbugs/issue22921.go
test/fixedbugs/issue23823.go
test/fixedbugs/issue25727.go
test/fixedbugs/issue26616.go
test/fixedbugs/issue28079c.go
test/fixedbugs/issue28450.go
test/fixedbugs/issue30085.go
test/fixedbugs/issue30087.go
test/fixedbugs/issue35291.go
test/fixedbugs/issue38745.go
test/fixedbugs/issue41247.go
test/fixedbugs/issue41440.go
test/fixedbugs/issue41500.go
test/fixedbugs/issue4215.go
test/fixedbugs/issue6402.go
test/fixedbugs/issue6772.go
test/fixedbugs/issue7129.go
test/fixedbugs/issue7150.go
test/fixedbugs/issue7153.go
test/fixedbugs/issue7310.go
test/fixedbugs/issue8183.go
test/fixedbugs/issue8385.go
test/fixedbugs/issue8438.go
test/fixedbugs/issue8440.go
test/fixedbugs/issue8507.go
test/fixedbugs/issue9370.go
test/fixedbugs/issue9521.go
Change-Id: I26e6e326fde6e3fca5400711a253834d710ab7f4
The list of conflicted files for this merge is:
src/cmd/compile/internal/gc/inl.go
src/cmd/compile/internal/gc/order.go
src/cmd/compile/internal/gc/ssa.go
test/fixedbugs/issue20415.go
test/fixedbugs/issue22822.go
test/fixedbugs/issue28079b.go
inl.go was updated for changes on dev.regabi: namely that OSELRECV has
been removed, and that OSELRECV2 now only uses List, rather than both
Left and List.
order.go was updated IsAutoTmp is now a standalone function, rather
than a method on Node.
ssa.go was similarly updated for new APIs involving package ir.
The tests are all merging upstream additions for gccgo error messages
with changes to cmd/compile's error messages on the dev.regabi branch.
Change-Id: Icaaf186d69da791b5994dbb6688ec989caabec42
For #11656
For #43283
Change-Id: I1fcf2b24800f421e36201af43130b487abe605b1
Reviewed-on: https://go-review.googlesource.com/c/go/+/279312
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Previously, reassigned was failing to detect reassignments due to
channel receives in select statements (OSELRECV, OSELRECV2), or due to
standalone 2-value receive assignments (OAS2RECV). This was reported
as a devirtualization panic, but could have caused mis-inlining as
well.
Fixes#43292.
Change-Id: Ic8079c20c0587aeacff9596697fdeba80a697b12
Reviewed-on: https://go-review.googlesource.com/c/go/+/279352
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
The issue11656 code was using the trap instruction as a PC value,
but it is intended to call a PC value that contains the trap instruction.
It doesn't matter too much as in practice the address is not
executable anyhow. But may as well have the code act the way it
is documented to act.
Also, don't run the test with gccgo/GoLLVM, as it can't work.
The illegal instruction will have no unwind data, so the unwinder
won't be able to get past it. In other words, gccgo/GoLLVM suffer
from the exact problem that the issue describes, but it seems insoluble.
For golang/go#11656
Change-Id: Ib2e50ffc91d215fd50e78f742fafe476c92d704e
Reviewed-on: https://go-review.googlesource.com/c/go/+/278473
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>
The language spec only requires a signed binary exponent of 16 bits
for floating point constants. Permit a "exponent too large" error for
larger exponents.
Don't run test 11326b with gccgo, as it requires successful compilation
of floating point constants with exponents that don't fit in 16 bits.
Change-Id: I98688160c76864aba525a151a14aaaf86bc36a6f
Reviewed-on: https://go-review.googlesource.com/c/go/+/279252
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Change the run.go driver to recognize the "gc" build tag.
Change existing tests to use the "gc" build tag if they use some
feature that seems specific to the gc compiler, such as passing specific
options to or expecting specific behavior from "go tool compile".
Change tests to use the "!gccgo" build tag if they use "go build" or
"go run", as while those might work with compilers other than gc, they
won't work with the way that gccgo runs its testsuite (which happens
independently of the go command).
For #43252
Change-Id: I666e04b6d7255a77dfc256ee304094e3a6bb15ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/279052
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL focuses on noder.go.
Passes buildall w/ toolstash -cmp.
Change-Id: Ie870126b51558e83c738add8e91a2804ed6d7f92
Reviewed-on: https://go-review.googlesource.com/c/go/+/277931
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL handles package fmt. There are various type assertions
but also some rewriting to lean more heavily on reflection.
Passes buildall w/ toolstash -cmp.
Change-Id: I503467468b42ace11bff2ba014b03cfa345e6d03
Reviewed-on: https://go-review.googlesource.com/c/go/+/277915
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The gofrontend code sees that the denominator is not zero,
so it computes the values. Dividing zero by a non-zero value
produces zero. The language spec doesn't require any of these
cases to report an error, so make the errors compiler-specific.
Change-Id: I5ed759a3121e38b937744d32250adcbdf2c4d3c2
Reviewed-on: https://go-review.googlesource.com/c/go/+/278117
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>
The bug429 tests is an exact duplicate of TestSimpleDeadlock in the
runtime package. The runtime package is the right place for this test,
and the version in the runtime package will run faster as the build
step is combined with other runtime package tests.
Change-Id: I6538d24e6df8e8c5e3e399d3ff37d68f3e52be56
Reviewed-on: https://go-review.googlesource.com/c/go/+/278173
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>
The language spec only requires that floating point values be
represented with 256 bits, which is about 1e75. The issue11371 test
was assuming that the compiler could represent 1e100. Adjusting the
test so that it only assumes 256 bits of precision still keeps the
test valid, and permits it to pass when using the gofrontend.
Change-Id: I9d1006e9adc9438277f4b8002488c912e5d61cc1
Reviewed-on: https://go-review.googlesource.com/c/go/+/278116
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
With the gc compiler the import path implies the package path,
so keeping a canonical path is important. With the gofrontend
this is not the case, so we don't need to report this as a bug.
Change-Id: I245e34f9b66383bd17e79438d4b002a3e20aa994
Reviewed-on: https://go-review.googlesource.com/c/go/+/278115
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The pattern in NNN.dir directories is that if we have a.go,
the other files import "./a". For gc it happens to work to use a path,
but not for gofrontend. Better to be consistent.
Change-Id: I2e023cbf6bd115f9fb77427b097b0ff9b9992f17
Reviewed-on: https://go-review.googlesource.com/c/go/+/278113
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>
This CL substantially reworks how imported declarations are handled,
and fixes a number of issues with dot imports. In particular:
1. It eliminates the stub ir.Name declarations that are created
upfront during import-declaration processing, allowing this to be
deferred to when the declarations are actually needed. (Eventually,
this can be deferred even further so we never have to create ir.Names
w/ ONONAME, but this CL is already invasive/subtle enough.)
2. During noding, we now use ir.Idents to represent uses of imported
declarations, including of dot-imported declarations.
3. Unused dot imports are now reported after type checking, so that we
can correctly distinguish whether composite literal keys are a simple
identifier (struct literals) or expressions (array/slice/map literals)
and whether it might be a use of a dot-imported declaration.
4. It changes the "redeclared" error messages to report the previous
position information in the same style as other compiler error
messages that reference other source lines.
Passes buildall w/ toolstash -cmp.
Fixes#6428.
Fixes#43164.
Fixes#43167.
Updates #42990.
Change-Id: I40a0a780ec40daf5700fbc3cfeeb7300e1055981
Reviewed-on: https://go-review.googlesource.com/c/go/+/277713
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
fixedbugs/issue26416.go:24:16: error: unknown field ‘t1f1’ in ‘t2’
fixedbugs/issue26416.go:25:16: error: unknown field ‘t1f2’ in ‘t3’
fixedbugs/issue26416.go:26:16: error: unknown field ‘t2f1’ in ‘t3’
fixedbugs/issue26616.go:15:9: error: single variable set to multiple-value function call
fixedbugs/issue26616.go:9:5: error: incompatible type in initialization (multiple-value function call in single-value context)
fixedbugs/issue26616.go:12:13: error: incompatible type in initialization (multiple-value function call in single-value context)
fixedbugs/issue26616.go:13:13: error: incompatible type in initialization (multiple-value function call in single-value context)
fixedbugs/issue26616.go:15:9: error: incompatible type in initialization (multiple-value function call in single-value context)
fixedbugs/issue26616.go:14:11: error: incompatible types in assignment (multiple-value function call in single-value context)
fixedbugs/issue26855.go:23:12: error: incompatible type for field 1 in struct construction
fixedbugs/issue26855.go:27:12: error: incompatible type for field 1 in struct construction
fixedbugs/issue25958.go:14:18: error: expected ‘<-’ or ‘=’
fixedbugs/issue25958.go:15:35: error: expected ‘<-’ or ‘=’
fixedbugs/issue28079b.go:13:9: error: array bound is not constant
fixedbugs/issue28079b.go:16:22: error: invalid context-determined non-integer type for left operand of shift
fixedbugs/issue28079c.go:14:22: error: invalid context-determined non-integer type for left operand of shift
fixedbugs/issue28450.go:9:19: error: ‘...’ only permits one name
fixedbugs/issue28450.go:10:18: error: ‘...’ must be last parameter
fixedbugs/issue28450.go:11:16: error: ‘...’ must be last parameter
fixedbugs/issue28450.go:11:24: error: ‘...’ must be last parameter
fixedbugs/issue28450.go:13:25: error: ‘...’ must be last parameter
fixedbugs/issue28450.go:15:19: error: ‘...’ must be last parameter
fixedbugs/issue28450.go:16:21: error: ‘...’ must be last parameter
fixedbugs/issue28450.go:16:31: error: ‘...’ must be last parameter
fixedbugs/issue28268.go:20:1: error: method ‘E’ redeclares struct field name
fixedbugs/issue28268.go:19:1: error: method ‘b’ redeclares struct field name
fixedbugs/issue27356.go:14:14: error: expected function
fixedbugs/issue27356.go:18:9: error: expected function
fixedbugs/issue29855.go:13:11: error: unknown field ‘Name’ in ‘T’
fixedbugs/issue27938.go:14:15: error: expected package
fixedbugs/issue27938.go:18:13: error: expected package
fixedbugs/issue27938.go:22:13: error: expected package
fixedbugs/issue27938.go:22:9: error: expected signature or type name
fixedbugs/issue29870b.go:13:9: error: ‘x’ declared but not used
fixedbugs/issue30085.go:10:18: error: wrong number of initializations
fixedbugs/issue30085.go:11:21: error: wrong number of initializations
fixedbugs/issue30087.go:10:18: error: wrong number of initializations
fixedbugs/issue30087.go:11:11: error: number of variables does not match number of values
fixedbugs/issue30087.go:12:9: error: wrong number of initializations
fixedbugs/issue30087.go:13:9: error: wrong number of initializations
fixedbugs/issue28926.go:16:14: error: use of undefined type ‘G’
fixedbugs/issue28926.go:18:14: error: use of undefined type ‘E’
fixedbugs/issue28926.go:22:24: error: use of undefined type ‘T’
fixedbugs/issue30722.go:13:13: error: invalid numeric literal
fixedbugs/issue30722.go:14:13: error: invalid numeric literal
fixedbugs/issue30722.go:15:13: error: invalid numeric literal
fixedbugs/issue33308.go:12:19: error: invalid context-determined non-integer type for left operand of shift
fixedbugs/issue33386.go:16:9: error: expected operand
fixedbugs/issue33386.go:22:9: error: expected operand
fixedbugs/issue33386.go:26:17: error: expected operand
fixedbugs/issue33386.go:27:18: error: expected operand
fixedbugs/issue33386.go:28:29: error: expected operand
fixedbugs/issue33386.go:15:17: error: reference to undefined name ‘send’
fixedbugs/issue33386.go:27:13: error: reference to undefined name ‘a’
fixedbugs/issue33386.go:21:19: error: value computed is not used
fixedbugs/issue33460.go:34:10: error: duplicate key in map literal
fixedbugs/issue33460.go:21:9: error: duplicate case in switch
fixedbugs/issue33460.go:24:9: error: duplicate case in switch
fixedbugs/issue33460.go:25:9: error: duplicate case in switch
fixedbugs/issue32723.go:12:14: error: invalid comparison of non-ordered type
fixedbugs/issue32723.go:13:13: error: invalid comparison of non-ordered type
fixedbugs/issue32723.go:16:16: error: invalid comparison of non-ordered type
fixedbugs/issue32723.go:17:16: error: invalid comparison of non-ordered type
fixedbugs/issue32723.go:18:15: error: invalid comparison of non-ordered type
fixedbugs/issue32723.go:21:15: error: invalid comparison of non-ordered type
fixedbugs/issue35291.go:13:9: error: duplicate value for index 1
fixedbugs/issue38745.go:12:12: error: reference to undefined field or method ‘M’
fixedbugs/issue38745.go:13:16: error: reference to undefined field or method ‘M’
fixedbugs/issue38745.go:17:19: error: reference to undefined field or method ‘M’
fixedbugs/issue38745.go:17:9: error: not enough arguments to return
fixedbugs/issue41500.go:16:22: error: incompatible types in binary expression
fixedbugs/issue41500.go:17:26: error: incompatible types in binary expression
fixedbugs/issue41500.go:18:22: error: incompatible types in binary expression
fixedbugs/issue41500.go:19:26: error: incompatible types in binary expression
fixedbugs/issue41575.go:23:6: error: invalid recursive type
fixedbugs/issue41575.go:9:6: error: invalid recursive type ‘T1’
fixedbugs/issue41575.go:13:6: error: invalid recursive type ‘T2’
fixedbugs/issue41575.go:17:6: error: invalid recursive type ‘a’
fixedbugs/issue41575.go:18:6: error: invalid recursive type ‘b’
fixedbugs/issue41575.go:19:6: error: invalid recursive type ‘c’
fixedbugs/issue41575.go:25:6: error: invalid recursive type ‘g’
fixedbugs/issue41575.go:32:6: error: invalid recursive type ‘x’
fixedbugs/issue41575.go:33:6: error: invalid recursive type ‘y’
fixedbugs/issue4215.go:10:9: error: not enough arguments to return
fixedbugs/issue4215.go:14:9: error: return with value in function with no return type
fixedbugs/issue4215.go:19:17: error: not enough arguments to return
fixedbugs/issue4215.go:21:9: error: not enough arguments to return
fixedbugs/issue4215.go:27:17: error: not enough arguments to return
fixedbugs/issue4215.go:29:17: error: too many values in return statement
fixedbugs/issue4215.go:31:17: error: not enough arguments to return
fixedbugs/issue4215.go:43:17: error: not enough arguments to return
fixedbugs/issue4215.go:46:17: error: not enough arguments to return
fixedbugs/issue4215.go:48:9: error: too many values in return statement
fixedbugs/issue4215.go:52:9: error: too many values in return statement
fixedbugs/issue41247.go:10:16: error: incompatible type for return value 1
fixedbugs/issue41440.go:13:9: error: too many arguments
fixedbugs/issue6772.go:10:16: error: ‘a’ repeated on left side of :=
fixedbugs/issue6772.go:17:16: error: ‘a’ repeated on left side of :=
fixedbugs/issue6402.go:12:16: error: incompatible type for return value 1
fixedbugs/issue6403.go:13:23: error: reference to undefined identifier ‘syscall.X’
fixedbugs/issue6403.go:14:15: error: reference to undefined name ‘voidpkg’
fixedbugs/issue7746.go:24:20: error: constant multiplication overflow
fixedbugs/issue7760.go:15:7: error: invalid constant type
fixedbugs/issue7760.go:16:7: error: invalid constant type
fixedbugs/issue7760.go:18:7: error: invalid constant type
fixedbugs/issue7760.go:19:7: error: invalid constant type
fixedbugs/issue7760.go:21:11: error: expression is not constant
fixedbugs/issue7760.go:22:11: error: expression is not constant
fixedbugs/issue7760.go:24:7: error: invalid constant type
fixedbugs/issue7760.go:25:7: error: invalid constant type
fixedbugs/issue7129.go:18:11: error: argument 1 has incompatible type (cannot use type bool as type int)
fixedbugs/issue7129.go:19:11: error: argument 1 has incompatible type (cannot use type bool as type int)
fixedbugs/issue7129.go:20:11: error: argument 1 has incompatible type (cannot use type bool as type int)
fixedbugs/issue7129.go:20:17: error: argument 2 has incompatible type (cannot use type bool as type int)
fixedbugs/issue7150.go:12:20: error: index expression is negative
fixedbugs/issue7150.go:13:13: error: some element keys in composite literal are out of range
fixedbugs/issue7150.go:14:13: error: some element keys in composite literal are out of range
fixedbugs/issue7150.go:15:13: error: some element keys in composite literal are out of range
fixedbugs/issue7150.go:16:13: error: some element keys in composite literal are out of range
fixedbugs/issue7675.go:16:11: error: argument 1 has incompatible type (cannot use type int as type string)
fixedbugs/issue7675.go:16:24: error: argument 3 has incompatible type (cannot use type string as type float64)
fixedbugs/issue7675.go:16:9: error: not enough arguments
fixedbugs/issue7675.go:16:14: error: floating-point constant truncated to integer
fixedbugs/issue7675.go:18:11: error: argument 1 has incompatible type (cannot use type int as type string)
fixedbugs/issue7675.go:18:24: error: argument 3 has incompatible type (cannot use type string as type float64)
fixedbugs/issue7675.go:18:28: error: argument 4 has incompatible type (cannot use type int as type string)
fixedbugs/issue7675.go:18:9: error: too many arguments
fixedbugs/issue7675.go:18:14: error: floating-point constant truncated to integer
fixedbugs/issue7675.go:19:11: error: argument 1 has incompatible type (cannot use type int as type string)
fixedbugs/issue7675.go:19:9: error: not enough arguments
fixedbugs/issue7675.go:19:14: error: floating-point constant truncated to integer
fixedbugs/issue7675.go:21:11: error: argument 1 has incompatible type (cannot use type int as type string)
fixedbugs/issue7675.go:21:19: error: argument 3 has incompatible type
fixedbugs/issue7675.go:21:14: error: floating-point constant truncated to integer
fixedbugs/issue7675.go:23:14: error: floating-point constant truncated to integer
fixedbugs/issue7153.go:11:15: error: reference to undefined name ‘a’
fixedbugs/issue7153.go:11:18: error: incompatible type for element 1 in composite literal
fixedbugs/issue7153.go:11:24: error: incompatible type for element 2 in composite literal
fixedbugs/issue7310.go:12:13: error: left argument must be a slice
fixedbugs/issue7310.go:13:13: error: second argument must be slice or string
fixedbugs/issue7310.go:14:15: error: incompatible types in binary expression
fixedbugs/issue6964.go:10:13: error: invalid type conversion (cannot use type complex128 as type string)
fixedbugs/issue7538a.go:14:9: error: reference to undefined label ‘_’
fixedbugs/issue8311.go:14:9: error: increment or decrement of non-numeric type
fixedbugs/issue8507.go:12:6: error: invalid recursive type ‘T’
fixedbugs/issue9521.go:16:20: error: argument 2 has incompatible type
fixedbugs/issue9521.go:17:20: error: argument 2 has incompatible type (cannot use type float64 as type int)
fixedbugs/issue8385.go:30:19: error: argument 1 has incompatible type (type has no methods)
fixedbugs/issue8385.go:30:14: error: not enough arguments
fixedbugs/issue8385.go:35:9: error: not enough arguments
fixedbugs/issue8385.go:36:9: error: not enough arguments
fixedbugs/issue8385.go:37:10: error: not enough arguments
fixedbugs/issue8385.go:38:10: error: not enough arguments
fixedbugs/issue8385.go:39:10: error: not enough arguments
fixedbugs/issue8385.go:40:10: error: not enough arguments
fixedbugs/issue8385.go:41:13: error: not enough arguments
fixedbugs/issue8438.go:13:23: error: incompatible type for element 1 in composite literal
fixedbugs/issue8438.go:14:22: error: incompatible type for element 1 in composite literal
fixedbugs/issue8438.go:15:23: error: incompatible type for element 1 in composite literal
fixedbugs/issue8440.go:10:9: error: reference to undefined name ‘n’
Change-Id: I5707aec7d3c9178c4f4d794d4827fc907b52efb3
Reviewed-on: https://go-review.googlesource.com/c/go/+/278032
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Also: Adjusted error patterns for passing test that have different
error messages.
Change-Id: I216294b4c4855aa93da22cdc3c0b3303e54a8420
Reviewed-on: https://go-review.googlesource.com/c/go/+/277994
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
If the parser reported an error for (string) literals, don't report
a second error during type checking.
This should have a couple of tests but they are tricky to arrange
with the current testing framework as the ERROR comment cannot be
on the line where the string. But the change is straightforward
and we have test/fixedbugs/issue32133.go that is passing now.
Change-Id: I0cd7f002b04e4092b8eb66009c7413288c8bfb23
Reviewed-on: https://go-review.googlesource.com/c/go/+/277993
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The following files had merge conflicts and were merged manually:
src/cmd/compile/fmtmap_test.go
src/cmd/compile/internal/gc/noder.go
src/go/parser/error_test.go
test/assign.go
test/chan/perm.go
test/fixedbugs/issue22822.go
test/fixedbugs/issue4458.go
test/init.go
test/interface/explicit.go
test/map1.go
test/method2.go
The following files had manual changes to make tests pass:
test/run.go
test/used.go
src/cmd/compile/internal/types2/stdlib_test.go
Change-Id: Ia495aaaa80ce321ee4ec2a9105780fbe913dbd4c
fixedbugs/issue20602.go:13:9: error: argument must have complex type
fixedbugs/issue20602.go:14:9: error: argument must have complex type
fixedbugs/issue19323.go:12:12: error: attempt to slice object that is not array, slice, or string
fixedbugs/issue19323.go:18:13: error: attempt to slice object that is not array, slice, or string
fixedbugs/issue20749.go:12:11: error: array index out of bounds
fixedbugs/issue20749.go:15:11: error: array index out of bounds
fixedbugs/issue20415.go:14:5: error: redefinition of ‘f’
fixedbugs/issue20415.go:12:5: note: previous definition of ‘f’ was here
fixedbugs/issue20415.go:25:5: error: redefinition of ‘g’
fixedbugs/issue20415.go:20:5: note: previous definition of ‘g’ was here
fixedbugs/issue20415.go:33:5: error: redefinition of ‘h’
fixedbugs/issue20415.go:31:5: note: previous definition of ‘h’ was here
fixedbugs/issue19977.go:12:21: error: reference to undefined name ‘a’
fixedbugs/issue20812.go:10:13: error: invalid type conversion (cannot use type string as type int)
fixedbugs/issue20812.go:11:13: error: invalid type conversion (cannot use type int as type bool)
fixedbugs/issue20812.go:12:13: error: invalid type conversion (cannot use type string as type bool)
fixedbugs/issue20812.go:13:13: error: invalid type conversion (cannot use type bool as type int)
fixedbugs/issue20812.go:14:13: error: invalid type conversion (cannot use type bool as type string)
fixedbugs/issue21256.go:9:5: error: redefinition of ‘main’
fixedbugs/issue20813.go:10:11: error: invalid left hand side of assignment
fixedbugs/issue20185.go:22:16: error: ‘t’ declared but not used
fixedbugs/issue20185.go:13:9: error: cannot type switch on non-interface value
fixedbugs/issue20185.go:22:9: error: cannot type switch on non-interface value
fixedbugs/issue20227.go:11:11: error: division by zero
fixedbugs/issue20227.go:12:12: error: division by zero
fixedbugs/issue20227.go:13:12: error: division by zero
fixedbugs/issue20227.go:15:11: error: division by zero
fixedbugs/issue20227.go:16:12: error: division by zero
fixedbugs/issue19880.go:14:13: error: invalid use of type
fixedbugs/issue23093.go:9:5: error: initialization expression for ‘f’ depends upon itself
fixedbugs/issue21979.go:29:13: error: integer constant overflow
fixedbugs/issue21979.go:39:13: error: complex constant truncated to floating-point
fixedbugs/issue21979.go:10:13: error: invalid type conversion (cannot use type string as type bool)
fixedbugs/issue21979.go:11:13: error: invalid type conversion (cannot use type int as type bool)
fixedbugs/issue21979.go:12:13: error: invalid type conversion (cannot use type float64 as type bool)
fixedbugs/issue21979.go:13:13: error: invalid type conversion (cannot use type complex128 as type bool)
fixedbugs/issue21979.go:15:13: error: invalid type conversion (cannot use type bool as type string)
fixedbugs/issue21979.go:17:13: error: invalid type conversion (cannot use type float64 as type string)
fixedbugs/issue21979.go:18:13: error: invalid type conversion (cannot use type complex128 as type string)
fixedbugs/issue21979.go:20:13: error: invalid type conversion (cannot use type string as type int)
fixedbugs/issue21979.go:21:13: error: invalid type conversion (cannot use type bool as type int)
fixedbugs/issue21979.go:27:13: error: invalid type conversion (cannot use type string as type uint)
fixedbugs/issue21979.go:28:13: error: invalid type conversion (cannot use type bool as type uint)
fixedbugs/issue21979.go:34:13: error: invalid type conversion (cannot use type string as type float64)
fixedbugs/issue21979.go:35:13: error: invalid type conversion (cannot use type bool as type float64)
fixedbugs/issue21979.go:41:13: error: invalid type conversion (cannot use type string as type complex128)
fixedbugs/issue21979.go:42:13: error: invalid type conversion (cannot use type bool as type complex128)
fixedbugs/issue21988.go:11:11: error: reference to undefined name ‘Wrong’
fixedbugs/issue22063.go:11:11: error: reference to undefined name ‘Wrong’
fixedbugs/issue22904.go:12:6: error: invalid recursive type ‘a’
fixedbugs/issue22904.go:13:6: error: invalid recursive type ‘b’
fixedbugs/issue22921.go:11:16: error: reference to undefined identifier ‘bytes.nonexist’
fixedbugs/issue22921.go:13:19: error: reference to undefined identifier ‘bytes.nonexist’
fixedbugs/issue22921.go:13:19: error: expected signature or type name
fixedbugs/issue22921.go:17:15: error: reference to undefined identifier ‘bytes.buffer’
fixedbugs/issue23823.go:15:9: error: invalid recursive interface
fixedbugs/issue23823.go:10:9: error: invalid recursive interface
fixedbugs/issue23732.go:24:13: error: too few expressions for struct
fixedbugs/issue23732.go:34:17: error: too many expressions for struct
fixedbugs/issue23732.go:37:13: error: too few expressions for struct
fixedbugs/issue23732.go:40:17: error: too many expressions for struct
fixedbugs/issue22794.go:16:14: error: reference to undefined field or method ‘floats’
fixedbugs/issue22794.go:18:19: error: unknown field ‘floats’ in ‘it’
fixedbugs/issue22794.go:19:17: error: unknown field ‘InneR’ in ‘it’
fixedbugs/issue22794.go:18:9: error: ‘i2’ declared but not used
fixedbugs/issue22822.go:15:17: error: expected function
fixedbugs/issue25727.go:12:10: error: reference to unexported field or method ‘doneChan’
fixedbugs/issue25727.go:13:10: error: reference to undefined field or method ‘DoneChan’
fixedbugs/issue25727.go:14:21: error: unknown field ‘tlsConfig’ in ‘http.Server’
fixedbugs/issue25727.go:15:21: error: unknown field ‘DoneChan’ in ‘http.Server’
fixedbugs/issue25727.go:21:14: error: unknown field ‘bAr’ in ‘foo’
Change-Id: I32ce0b7d80017b2367b8fb479a881632240d4161
Reviewed-on: https://go-review.googlesource.com/c/go/+/277455
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>
fixedbugs/issue14136.go:17:16: error: unknown field ‘X’ in ‘T’
fixedbugs/issue14136.go:18:13: error: incompatible type in initialization (cannot use type int as type string)
fixedbugs/issue14520.go:9:37: error: import path contains control character
fixedbugs/issue14520.go:14:2: error: expected ‘)’
fixedbugs/issue14520.go:14:3: error: expected declaration
fixedbugs/issue14652.go:9:7: error: use of undefined type ‘any’
fixedbugs/issue14729.go:13:17: error: embedded type may not be a pointer
fixedbugs/issue15514.dir/c.go:10: error: incompatible type in initialization
fixedbugs/issue15898.go:11:9: error: duplicate type in switch
fixedbugs/issue15898.go:16:9: error: duplicate type in switch
fixedbugs/issue16439.go:10:21: error: index expression is negative
fixedbugs/issue16439.go:13:21: error: index expression is negative
fixedbugs/issue16439.go:16:21: error: index expression is not integer constant
fixedbugs/issue16439.go:18:22: error: index expression is not integer constant
fixedbugs/issue17328.go:11:20: error: expected ‘{’
fixedbugs/issue17328.go:11:20: error: expected ‘;’ or ‘}’ or newline
fixedbugs/issue17328.go:13:1: error: expected declaration
fixedbugs/issue17588.go:14:15: error: expected type
fixedbugs/issue17631.go:20:17: error: unknown field ‘updates’ in ‘unnamed struct’
fixedbugs/issue17645.go:15:13: error: incompatible type in initialization
fixedbugs/issue17758.go:13:1: error: redefinition of ‘foo’
fixedbugs/issue17758.go:9:1: note: previous definition of ‘foo’ was here
fixedbugs/issue18092.go:13:19: error: expected colon
fixedbugs/issue18231.go:17:12: error: may only omit types within composite literals of slice, array, or map type
fixedbugs/issue18393.go:24:38: error: expected type
fixedbugs/issue18419.dir/test.go:12: error: reference to unexported field or method 'member'
fixedbugs/issue18655.go:14:1: error: redefinition of ‘m’
fixedbugs/issue18655.go:13:1: note: previous definition of ‘m’ was here
fixedbugs/issue18655.go:15:1: error: redefinition of ‘m’
fixedbugs/issue18655.go:13:1: note: previous definition of ‘m’ was here
fixedbugs/issue18655.go:16:1: error: redefinition of ‘m’
fixedbugs/issue18655.go:13:1: note: previous definition of ‘m’ was here
fixedbugs/issue18655.go:17:1: error: redefinition of ‘m’
fixedbugs/issue18655.go:13:1: note: previous definition of ‘m’ was here
fixedbugs/issue18655.go:18:1: error: redefinition of ‘m’
fixedbugs/issue18655.go:13:1: note: previous definition of ‘m’ was here
fixedbugs/issue18655.go:20:1: error: redefinition of ‘m’
fixedbugs/issue18655.go:13:1: note: previous definition of ‘m’ was here
fixedbugs/issue18655.go:21:1: error: redefinition of ‘m’
fixedbugs/issue18655.go:13:1: note: previous definition of ‘m’ was here
fixedbugs/issue18655.go:22:1: error: redefinition of ‘m’
fixedbugs/issue18655.go:13:1: note: previous definition of ‘m’ was here
fixedbugs/issue18915.go:13:20: error: expected ‘;’ after statement in if expression
fixedbugs/issue18915.go:16:21: error: parse error in for statement
fixedbugs/issue18915.go:19:24: error: expected ‘;’ after statement in switch expression
fixedbugs/issue18915.go:13:12: error: ‘a’ declared but not used
fixedbugs/issue18915.go:16:13: error: ‘b’ declared but not used
fixedbugs/issue18915.go:19:16: error: ‘c’ declared but not used
fixedbugs/issue19012.go:16:17: error: return with value in function with no return type
fixedbugs/issue19012.go:18:9: error: return with value in function with no return type
fixedbugs/issue19012.go:22:16: error: argument 2 has incompatible type (cannot use type bool as type uint)
fixedbugs/issue19012.go:22:9: error: too many arguments
fixedbugs/issue19012.go:22:16: error: incompatible types in binary expression
fixedbugs/issue19012.go:24:9: error: too many arguments
fixedbugs/issue19056.go:9:9: error: expected operand
fixedbugs/issue19056.go:9:9: error: expected ‘;’ or newline after top level declaration
fixedbugs/issue19482.go:25:15: error: expected struct field name
fixedbugs/issue19482.go:27:15: error: expected struct field name
fixedbugs/issue19482.go:31:19: error: expected struct field name
fixedbugs/issue19482.go:33:15: error: expected struct field name
fixedbugs/issue19667.go:13:1: error: expected operand
fixedbugs/issue19667.go:13:1: error: missing ‘)’
fixedbugs/issue19667.go:13:105: error: expected ‘;’ after statement in if expression
fixedbugs/issue19667.go:13:105: error: expected ‘{’
fixedbugs/issue19667.go:12:19: error: reference to undefined name ‘http’
Change-Id: Ia9c75b9c78671f354f0a0623dbc075157ef8f181
Reviewed-on: https://go-review.googlesource.com/c/go/+/277433
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>
There were only a few places these were still used, none of which
justify generating all this code. Instead rewrite them to use
fmt.Sprint or simpler means.
Passes buildall w/ toolstash -cmp.
Change-Id: Ibd123a1696941a597f0cb4dcc96cda8ced672140
Reviewed-on: https://go-review.googlesource.com/c/go/+/276072
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Since CL 270057, there're many attempts to fix the expand_calls pass
with interface{}-typed. But all of them did not fix the root cause. The
main issue is during SSA conversion in gc/ssa.go, for empty interface
case, we make its type as n.Type, instead of BytePtr.
To fix these, we can just use BytePtr for now, since when itab fields
are treated as scalar.
No significal changes on compiler speed, size.
cmd/compile/internal/ssa
expandCalls.func6 9488 -> 9232 (-2.70%)
file before after Δ %
cmd/compile/internal/ssa.s 3992893 3992637 -256 -0.006%
total 20500447 20500191 -256 -0.001%
Fixes#43112
Updates #42784
Updates #42727
Updates #42568
Change-Id: I0b15d9434e0be5448453e61f98ef9c2d6cd93792
Reviewed-on: https://go-review.googlesource.com/c/go/+/276952
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: Keith Randall <khr@golang.org>
The Go spec requires that select case clauses be evaluated in order,
which is stricter than normal ordering semantics. cmd/compile handled
this correctly for send clauses, but was not correctly handling
receive clauses that involved bare variable references.
Discovered with @cuonglm.
Fixes#43111.
Change-Id: Iec93b6514dd771875b084ba49c15d7f4531b4a6f
Reviewed-on: https://go-review.googlesource.com/c/go/+/277132
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>
Reviewed-by: Keith Randall <khr@golang.org>
fixedbugs/bug13343.go:10:12: error: initialization expressions for ‘b’ and ‘c’ depend upon each other
fixedbugs/bug13343.go:11:9: note: ‘c’ defined here
fixedbugs/bug13343.go:11:9: error: initialization expression for ‘c’ depends upon itself
fixedbugs/bug13343.go:11:9: error: initialization expressions for ‘c’ and ‘b’ depend upon each other
fixedbugs/bug13343.go:10:12: note: ‘b’ defined here
fixedbugs/issue10700.dir/test.go:24:10: error: reference to method ‘Do’ in type that is pointer to interface, not interface
fixedbugs/issue10700.dir/test.go:25:10: error: reference to method ‘do’ in type that is pointer to interface, not interface
fixedbugs/issue10700.dir/test.go:27:10: error: reference to method ‘Dont’ in type that is pointer to interface, not interface
fixedbugs/issue10700.dir/test.go:28:13: error: reference to undefined field or method ‘Dont’
fixedbugs/issue10700.dir/test.go:31:10: error: reference to undefined field or method ‘do’
fixedbugs/issue10700.dir/test.go:33:13: error: reference to undefined field or method ‘do’
fixedbugs/issue10700.dir/test.go:34:10: error: reference to undefined field or method ‘Dont’
fixedbugs/issue10700.dir/test.go:35:13: error: reference to undefined field or method ‘Dont’
fixedbugs/issue10700.dir/test.go:37:10: error: reference to method ‘Do’ in type that is pointer to interface, not interface
fixedbugs/issue10700.dir/test.go:38:10: error: reference to method ‘do’ in type that is pointer to interface, not interface
fixedbugs/issue10700.dir/test.go:40:13: error: reference to undefined field or method ‘do’
fixedbugs/issue10700.dir/test.go:41:10: error: reference to method ‘Dont’ in type that is pointer to interface, not interface
fixedbugs/issue10700.dir/test.go:42:13: error: reference to undefined field or method ‘Dont’
fixedbugs/issue10700.dir/test.go:43:10: error: reference to method ‘secret’ in type that is pointer to interface, not interface
fixedbugs/issue10700.dir/test.go:44:13: error: reference to unexported field or method ‘secret’
fixedbugs/issue10975.go:13:9: error: interface contains embedded non-interface
fixedbugs/issue11326.go:26:17: error: floating-point constant overflow
fixedbugs/issue11326.go:27:17: error: floating-point constant overflow
fixedbugs/issue11326.go:28:17: error: floating-point constant overflow
fixedbugs/issue11361.go:9:11: error: import file ‘fmt’ not found
fixedbugs/issue11361.go:11:11: error: reference to undefined name ‘fmt’
fixedbugs/issue11371.go:12:15: error: floating-point constant truncated to integer
fixedbugs/issue11371.go:13:15: error: integer constant overflow
fixedbugs/issue11371.go:17:15: error: floating-point constant truncated to integer
fixedbugs/issue11590.go:9:17: error: integer constant overflow
fixedbugs/issue11590.go:9:17: error: integer constant overflow
fixedbugs/issue11590.go:10:22: error: complex real part overflow
fixedbugs/issue11590.go:10:22: error: complex real part overflow
fixedbugs/issue11590.go:11:23: error: complex real part overflow
fixedbugs/issue11590.go:11:23: error: complex real part overflow
fixedbugs/issue11590.go:9:19: error: integer constant overflow
fixedbugs/issue11590.go:10:24: error: complex real part overflow
fixedbugs/issue11590.go:11:25: error: complex real part overflow
fixedbugs/issue11610.go:11:7: error: import path is empty
fixedbugs/issue11610.go:12:4: error: invalid character 0x3f in input file
fixedbugs/issue11610.go:14:1: error: expected identifier
fixedbugs/issue11610.go:14:1: error: expected type
fixedbugs/issue11614.go:14:9: error: interface contains embedded non-interface
fixedbugs/issue13248.go:13:1: error: expected operand
fixedbugs/issue13248.go:13:1: error: missing ‘)’
fixedbugs/issue13248.go:12:5: error: reference to undefined name ‘foo’
fixedbugs/issue13266.go:10:8: error: package name must be an identifier
fixedbugs/issue13266.go:10:8: error: expected ‘;’ or newline after package clause
fixedbugs/issue13266.go:10:8: error: expected declaration
fixedbugs/issue13273.go:50:18: error: expected ‘chan’
fixedbugs/issue13273.go:53:24: error: expected ‘chan’
fixedbugs/issue13274.go:11:58: error: expected ‘}’
fixedbugs/issue13365.go:14:19: error: index expression is negative
fixedbugs/issue13365.go:15:21: error: index expression is negative
fixedbugs/issue13365.go:16:22: error: index expression is negative
fixedbugs/issue13365.go:19:13: error: some element keys in composite literal are out of range
fixedbugs/issue13365.go:22:19: error: incompatible type for element 1 in composite literal
fixedbugs/issue13365.go:23:21: error: incompatible type for element 1 in composite literal
fixedbugs/issue13365.go:24:22: error: incompatible type for element 1 in composite literal
fixedbugs/issue13415.go:14:5: error: redefinition of ‘x’
fixedbugs/issue13415.go:14:5: note: previous definition of ‘x’ was here
fixedbugs/issue13415.go:14:5: error: ‘x’ declared but not used
fixedbugs/issue13471.go:12:25: error: floating-point constant truncated to integer
fixedbugs/issue13471.go:13:25: error: floating-point constant truncated to integer
fixedbugs/issue13471.go:14:25: error: floating-point constant truncated to integer
fixedbugs/issue13471.go:15:24: error: floating-point constant truncated to integer
fixedbugs/issue13471.go:16:23: error: floating-point constant truncated to integer
fixedbugs/issue13471.go:18:26: error: floating-point constant truncated to integer
fixedbugs/issue13471.go:19:26: error: floating-point constant truncated to integer
fixedbugs/issue13471.go:20:26: error: floating-point constant truncated to integer
fixedbugs/issue13471.go:21:25: error: floating-point constant truncated to integer
fixedbugs/issue13471.go:22:24: error: floating-point constant truncated to integer
fixedbugs/issue13471.go:24:24: error: floating-point constant truncated to integer
fixedbugs/issue13821b.go:18:12: error: incompatible types in binary expression
fixedbugs/issue13821b.go:19:13: error: incompatible types in binary expression
fixedbugs/issue13821b.go:20:13: error: incompatible types in binary expression
fixedbugs/issue13821b.go:21:13: error: incompatible types in binary expression
fixedbugs/issue13821b.go:22:13: error: incompatible types in binary expression
fixedbugs/issue13821b.go:24:12: error: incompatible types in binary expression
fixedbugs/issue14006.go:24:18: error: expected ‘;’ or ‘}’ or newline
fixedbugs/issue14006.go:30:18: error: expected ‘;’ or ‘}’ or newline
fixedbugs/issue14006.go:37:22: error: expected ‘;’ or ‘}’ or newline
fixedbugs/issue14006.go:43:22: error: expected ‘;’ or ‘}’ or newline
fixedbugs/issue14006.go:59:17: note: previous definition of ‘labelname’ was here
fixedbugs/issue14006.go:64:17: error: label ‘labelname’ already defined
fixedbugs/issue14006.go:24:17: error: value computed is not used
fixedbugs/issue14006.go:30:17: error: value computed is not used
fixedbugs/issue14006.go:37:20: error: value computed is not used
fixedbugs/issue14006.go:43:20: error: value computed is not used
fixedbugs/issue14006.go:59:17: error: label ‘labelname’ defined and not used
fixedbugs/issue14010.go:13:14: error: invalid left hand side of assignment
fixedbugs/issue14010.go:14:14: error: invalid left hand side of assignment
fixedbugs/issue14010.go:14:9: error: invalid use of type
fixedbugs/issue14321.go:30:10: error: method ‘F’ is ambiguous in type ‘C’
fixedbugs/issue14321.go:31:10: error: ‘G’ is ambiguous via ‘A’ and ‘B’
fixedbugs/issue14321.go:33:10: error: type ‘C’ has no method ‘I’
fixedbugs/issue8183.go:12:14: error: integer constant overflow
fixedbugs/issue9036.go:21:12: error: invalid prefix for floating constant
fixedbugs/issue9036.go:22:12: error: invalid prefix for floating constant
fixedbugs/issue9076.go:14:5: error: incompatible type in initialization (cannot use type uintptr as type int32)
fixedbugs/issue9076.go:15:5: error: incompatible type in initialization (cannot use type uintptr as type int32)
For issue9083.go avoid an error about a variable that is set but not used.
fixedbugs/issue9370.go:105:13: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:106:13: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:107:13: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:108:13: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:109:13: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:110:13: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:112:18: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:113:18: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:114:18: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:115:18: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:116:18: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:117:18: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:119:13: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:119:18: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:36:15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:39:15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:43:15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:46:15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:50:15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:53:15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:56:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:57:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:58:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:59:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:60:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:61:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:65:15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:68:15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:70:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:71:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:72:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:73:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:74:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:75:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:77:15: error: invalid operation (func can only be compared to nil)
fixedbugs/issue9370.go:78:15: error: invalid operation (func can only be compared to nil)
fixedbugs/issue9370.go:79:15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:80:15: error: invalid operation (func can only be compared to nil)
fixedbugs/issue9370.go:81:15: error: invalid operation (func can only be compared to nil)
fixedbugs/issue9370.go:82:15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:84:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:85:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:86:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:87:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:88:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:89:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:91:15: error: invalid operation (func can only be compared to nil)
fixedbugs/issue9370.go:92:15: error: invalid operation (func can only be compared to nil)
fixedbugs/issue9370.go:93:15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:94:15: error: invalid operation (func can only be compared to nil)
fixedbugs/issue9370.go:95:15: error: invalid operation (func can only be compared to nil)
fixedbugs/issue9370.go:96:15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:98:15: error: invalid operation (func can only be compared to nil)
fixedbugs/issue9370.go:99:15: error: invalid operation (func can only be compared to nil)
fixedbugs/issue9370.go💯15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:101:15: error: invalid operation (func can only be compared to nil)
fixedbugs/issue9370.go:102:15: error: invalid operation (func can only be compared to nil)
fixedbugs/issue9370.go:103:15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:121:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:122:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:123:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:124:15: error: incompatible types in binary expression
Change-Id: I4089de4919112b08f5f2bbec20f84fcc7dbe3955
Reviewed-on: https://go-review.googlesource.com/c/go/+/276832
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>
Change-Id: I4f1d5d34dd9b26cea8e837a8ff7e833e02c913e1
Reviewed-on: https://go-review.googlesource.com/c/go/+/276815
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
It just makes the compiler crash. Oops.
Fixes#43099
Change-Id: Id996c14799c1a5d0063ecae3b8770568161c2440
Reviewed-on: https://go-review.googlesource.com/c/go/+/276652
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Use the Key position of a syntax.KeyValueExpr (not the position of the
":") when reporting an error for a missing key.
(In go/types, the KeyValueExpr position is the start of the expression
not the ":", so there this works as expected.)
Change-Id: I74147d245927847274cf4e53b4f03dbb5110c324
Reviewed-on: https://go-review.googlesource.com/c/go/+/276813
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Triaged and adjusted more test/fixedbugs/* tests.
Change-Id: I80b9ead2445bb8d126b7d79db4bea9ddcb225a84
Reviewed-on: https://go-review.googlesource.com/c/go/+/276812
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Also: Triaged/adjusted some more test/fixedbugs tests.
Change-Id: I050847b6dfccc7f301f8100bfdbe84e0487e33fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/276512
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Enabled some more test/fixedbugs tests.
Change-Id: I02102b698eedfbee582b3234850fb01418ebbf7c
Reviewed-on: https://go-review.googlesource.com/c/go/+/276453
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Also: Triaged/adjusted some more test/fixedbugs tests.
Change-Id: Idaba1875273d6da6ef82dd8de8edd8daa885d32c
Reviewed-on: https://go-review.googlesource.com/c/go/+/276472
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Use a map to detect recursive types.
With this we can now typecheck fixedbugs/issue8501.go.
Updates #43088.
Change-Id: I7fad6ccf6c94268473ff72b09a3158e13a7f4cc3
Reviewed-on: https://go-review.googlesource.com/c/go/+/276374
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Ending typecheck1 in the switch makes it safe for each case
to do an appropriate type assertion. The main change is dropping
the computation of "ok" and using the syntax nodes themselves
to decide what's OK.
Passes buildall w/ toolstash -cmp.
Change-Id: I2a1873a51e3f1194d74bb87a6653cb9857a02a1b
Reviewed-on: https://go-review.googlesource.com/c/go/+/275444
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The gofrontend code would in some circumstances incorrectly generate a
type descriptor for an alias type, causing the type to fail to be
equal to the unaliased type.
Change-Id: I47d33b0bfde3c72a9a186049539732bdd5a6a96e
Reviewed-on: https://go-review.googlesource.com/c/go/+/275632
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Enabled fixedbugs/issue8183.go for run.go with new typechecker
now that issue is fixed.
Fixes#42992.
Updates #42991.
Change-Id: I23451999983b740d5f37ce3fa75ee756daf1a44f
Reviewed-on: https://go-review.googlesource.com/c/go/+/275517
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
If an interface contains a blank method, that's already an error. No
need for useless follow-up error messages about not implementing them.
Fixes#42964.
Change-Id: I5bf53a8f27d75d4c86c61588c5e2e3e95563d320
Reviewed-on: https://go-review.googlesource.com/c/go/+/275294
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>
Change-Id: I103e3eeacd5b11efd63c965482a626878ba5ac81
Reviewed-on: https://go-review.googlesource.com/c/go/+/275216
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Replace existing ad-hoc file exclusion mechanism with list of
excluded files; i.e., files for which the compiler with -G
option doesn't produce matching error messages yet.
Remove -G option since we now always run all passing tests.
Change-Id: I0655d2cf8bc135b3f50b1a811b8f49090c427580
Reviewed-on: https://go-review.googlesource.com/c/go/+/275212
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
An address of offset(SP) may point to the callee args area, and
may be used to move things into/out of the args/results. If an
address like that is spilled and picked up by the GC, it may hold
an arg/result live in the callee, which may not actually be live
(e.g. a result not initialized at function entry). Make sure
they are rematerializeable, so they are always short-lived and
never picked up by the GC.
This CL changes 386, PPC64, and Wasm. On AMD64 we already have
the rule (line 2159). On other architectures, we already have
similar rules like
(OffPtr [off] ptr:(SP)) => (MOVDaddr [int32(off)] ptr)
to avoid this problem. (Probably me in the past had run into
this...)
Fixes#42944.
Change-Id: Id2ec73ac08f8df1829a9a7ceb8f749d67fe86d1e
Reviewed-on: https://go-review.googlesource.com/c/go/+/275174
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
With this CL, the first ~500 errorcheck tests pass when running
go run run.go -v -G
in the $GOROOT/test directory (the log output includes a few dozen
tests that are currently skipped).
Change-Id: I9eaa2319fb39a090df54f8699ddc29ffe58b1bf1
Reviewed-on: https://go-review.googlesource.com/c/go/+/274975
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
assign.go:59:28: error: ‘x’ repeated on left side of :=
assign.go:65:20: error: ‘a’ repeated on left side of :=
method2.go:36:11: error: reference to method ‘val’ in type that is pointer to interface, not interface
method2.go:37:11: error: reference to method ‘val’ in type that is pointer to interface, not interface
Change-Id: I8f385c75a82fae4eacf4618df8f9f65932826494
Reviewed-on: https://go-review.googlesource.com/c/go/+/274447
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>
Now that filepath.WalkDir is available, it is more efficient
and should be used in place of filepath.Walk.
Update the tree to reflect best practices.
As usual, the code compiled with Go 1.4 during bootstrap is excluded.
(In this CL, that's only cmd/dist.)
For #42027.
Change-Id: Ib0f7b1e43e50b789052f9835a63ced701d8c411c
Reviewed-on: https://go-review.googlesource.com/c/go/+/267719
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
It's noisy and not doing any harm, and we still have an entire release
cycle to revisit and address the issue properly.
Updates #42938
Change-Id: I1de5cfb495a8148c9c08b215deba38f2617fb467
Reviewed-on: https://go-review.googlesource.com/c/go/+/274732
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Change-Id: Ie2950cdc5406915935f114bfd97ef03d965f9069
Reviewed-on: https://go-review.googlesource.com/c/go/+/274616
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The gofrontend code doesn't distinguish semicolon and newline,
and it doesn't have special treatment for EOF.
syntax/semi6.go:9:47: error: unexpected semicolon or newline in type declaration
syntax/semi6.go:11:62: error: unexpected semicolon or newline in type declaration
Change-Id: I9996b59a4fc78ad1935e779f354ddf75c0fb44e0
Reviewed-on: https://go-review.googlesource.com/c/go/+/274692
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
These replacement rules assume that TST and TEQ set V. But TST and
TEQ do not set V. This is a problem because instructions like LT are
actually checking for N!=V. But with TST and TEQ not setting V, LT
doesn't do anything meaningful. It's possible to construct trivial
miscompilations from this, such as:
package main
var x = [4]int32{-0x7fffffff, 0x7fffffff, 2, 4}
func main() {
if x[0] > x[1] {
panic("fail 1")
}
if x[2]&x[3] < 0 {
panic("fail 2") // Fails here
}
}
That first comparison sets V, via the CMP that subtracts the values
causing the overflow. Then the second comparison operation thinks that
it uses the result of TST, when it actually uses the V from CMP.
Before this fix:
TST R0, R1
BLT loc_6C164
After this fix:
TST R0, R1
BMI loc_6C164
The BMI instruction checks the N flag, which TST sets. This commit
fixes the issue by using [LG][TE]noov instead of vanilla [LG][TE], and
also adds a test case for the direct issue.
Fixes#42876.
Change-Id: I13c62c88d18574247ad002b671b38d2d0b0fc6fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/274026
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
If the new Config.IgnoreBranches flag is set, the typechecker
ignores errors due to misplaced labels, break, continue,
fallthrough, or goto statements.
Since the syntax parser already checks these errors, we need
to disable a 2nd check by the typechecker to avoid duplicate
errors when running the compiler with the new typechecker.
Adjusted test/run.go to not ignore some of the tests that
used to fail because of duplicate errors.
Change-Id: I8756eb1d44f67afef5e57da289cd604b8e1716db
Reviewed-on: https://go-review.googlesource.com/c/go/+/274612
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Added a new flag -G to run. Setting -G (as in: go run run.go -G)
will run tests marked with "errorcheck" (and no other flags) also
with the compiler using the new typechecker.
Many tests don't pass yet (due to discrepancies in error messages).
The top-level tests in the test directory which don't pass yet have
been explicitly excluded, permitting to see the current status.
Future CLs will bring error messages in sync and eventually all
tests should pass.
Change-Id: I7caf5eff413e173f68d092af4bbe458434718d74
Reviewed-on: https://go-review.googlesource.com/c/go/+/274313
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
There's not really any use to tracking function-scoped constants and
types on Curfn.Dcl, and there's sloppy code that assumes all of the
declarations are variables (e.g., cmpstackvarlt).
Change-Id: I5d10dc681dac2c161c7b73ba808403052ca0608e
Reviewed-on: https://go-review.googlesource.com/c/go/+/274436
Reviewed-by: Russ Cox <rsc@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
The code for type-checking defined types was scattered between
typecheckdef, typecheckdeftype, and setUnderlying. There was redundant
work between them, and setUnderlying also needed to redo a lot of work
because of its brute-force solution of just copying all Type fields.
This CL reorders things so as many of the defined type's fields are
set in advance (in typecheckdeftype), and then setUnderlying only
copies over the details actually needed from the underlying type.
Incidentally, this evidently improves our error handling for an
existing test case, by allowing us to report an additional error.
Passes toolstash/buildall.
Change-Id: Id59a24341e7e960edd1f7366c3e2356da91b9fe7
Reviewed-on: https://go-review.googlesource.com/c/go/+/274432
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Allows emitting errors about ineffectual //go:linkname directives.
In particular, this exposed: a typo in os2_aix.go; redundant (but
harmless) directives for libc_pipe in both os3_solaris.go and
syscall2_solaris.go; and a bunch of useless //go:linkname directives
in macOS wrapper code.
However, because there's also ineffectual directives in the vendored
macOS code from x/sys, that can't be an error just yet. So instead we
print a warning (including a heads up that it will be promoted to an
error in Go 1.17) to prevent backsliding while we fix and re-vendor
that code.
Passes toolstash-check.
Change-Id: I59badeab5df0d8b3abfd14c6066e9bb00e840f73
Reviewed-on: https://go-review.googlesource.com/c/go/+/273986
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
This matches the error messages after CL 273890.
syntax/semi4.go:11:9: error: unexpected semicolon or newline, expecting ‘{’ after for clause
syntax/semi4.go:10:13: error: reference to undefined name ‘x’
syntax/semi4.go:12:17: error: reference to undefined name ‘z’
Change-Id: Ic88ff6e27d50bf70f5b2114383b84c42c0682f39
Reviewed-on: https://go-review.googlesource.com/c/go/+/273891
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
shift1.go:76:16: error: shift of non-integer operand
shift1.go:77:16: error: shift of non-integer operand
Change-Id: I48584c0b01f9f6912a93b5f9bba55b5803fbeced
Reviewed-on: https://go-review.googlesource.com/c/go/+/273888
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
As of https://golang.org/cl/273886:
fixedbugs/bug340.go:15:18: error: reference to method ‘x’ in interface with no methods
For golang/go#10700
Change-Id: Id29eb0e34bbb524117614229c4c27cfd17dae286
Reviewed-on: https://go-review.googlesource.com/c/go/+/273887
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
These changes match the following gofrontend error messages:
blank1.go:16:1: error: may not define methods on non-local type
chan/perm.go:28:9: error: expected channel
chan/perm.go:29:11: error: left operand of ‘<-’ must be channel
chan/perm.go:69:9: error: argument must be channel
complit1.go:25:16: error: attempt to slice object that is not array, slice, or string
complit1.go:26:16: error: attempt to slice object that is not array, slice, or string
complit1.go:27:17: error: attempt to slice object that is not array, slice, or string
complit1.go:49:41: error: may only omit types within composite literals of slice, array, or map type
complit1.go:50:14: error: expected struct, slice, array, or map type for composite literal
convlit.go:24:9: error: invalid type conversion (cannot use type unsafe.Pointer as type string)
convlit.go:25:9: error: invalid type conversion (cannot use type unsafe.Pointer as type float64)
convlit.go:26:9: error: invalid type conversion (cannot use type unsafe.Pointer as type int)
ddd1.go:63:9: error: invalid use of ‘...’ calling non-variadic function
fixedbugs/bug176.go:12:18: error: index expression is not integer constant
fixedbugs/bug332.go:17:10: error: use of undefined type ‘T’
fixedbugs/issue4232.go:22:16: error: integer constant overflow
fixedbugs/issue4232.go:33:16: error: integer constant overflow
fixedbugs/issue4232.go:44:25: error: integer constant overflow
fixedbugs/issue4232.go:55:16: error: integer constant overflow
fixedbugs/issue4458.go:19:14: error: type has no method ‘foo’
fixedbugs/issue5172.go:24:14: error: too many expressions for struct
init.go:17:9: error: reference to undefined name ‘runtime’
initializerr.go:26:29: error: duplicate value for index 1
interface/explicit.go:60:14: error: type assertion only valid for interface types
label.go:64:9: error: reference to undefined label ‘go2’
label1.go:18:97: error: continue statement not within for
label1.go:22:97: error: continue statement not within for
label1.go:106:89: error: continue statement not within for
label1.go:108:26: error: invalid continue label ‘on’
label1.go:111:118: error: break statement not within for or switch or select
label1.go:113:23: error: invalid break label ‘dance’
map1.go:64:9: error: not enough arguments
map1.go:65:9: error: not enough arguments
map1.go:67:9: error: argument 1 must be a map
method2.go:36:11: error: reference to undefined field or method ‘val’
method2.go:37:11: error: reference to undefined field or method ‘val’
method2.go:41:12: error: method requires pointer (use ‘(*T).g’)
syntax/chan1.go:13:19: error: send statement used as value; use select for non-blocking send
syntax/chan1.go:17:11: error: send statement used as value; use select for non-blocking send
Change-Id: I98047b60a376e3d2788836300f7fcac3f2c285cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/273527
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
In the previous CL, I had incorrectly removed one of the error
messages from issue20232.go, because I thought go/constant was just
handling it. But actually the compiler was panicking in nodlit,
because it didn't handle constant.Unknown. So this CL makes it leave
n.Type == nil for unknown constant.Values.
While here, also address #42732 by making sure to report an error
message when origConst is called with an unknown constant.Value (as
can happen when multiplying two floating-point constants overflows).
Finally, add OXOR and OBITNOT to the list of operations to report
errors about, since they're also constant expressions that can produce
a constant with a greater bit length than their operands.
Fixes#42732.
Change-Id: I4a538fbae9b3ac4c553d7de5625dc0c87d9acce3
Reviewed-on: https://go-review.googlesource.com/c/go/+/272928
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Address outstanding TODO, which simplifies subsequent CLs.
Now the compiler always type checks type-switch case clauses (like
gccgo), but it treats clause variables as broken if an appropriate
type cannot be determined for it (like go/types).
Passes toolstash-check.
Change-Id: Iedfe9cdf38c6865211e4b93391f1cf72c1bed136
Reviewed-on: https://go-review.googlesource.com/c/go/+/272648
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
CL 271906 allows loading single field of typed-interface{} OpIData, but
it does not update the corresponding selector type. So the generated
OpLoad has the named type instead, prevent it from being lowered by
lower pass.
Fixes#42784
Change-Id: Idf32e4f711731be09d508dd712b60bc8c58309bd
Reviewed-on: https://go-review.googlesource.com/c/go/+/272466
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: Cherry Zhang <cherryyz@google.com>
The bug was introduced by https://golang.org/cl/220844.
Fixes#42790.
Change-Id: I44d619a1a4d3f2aee1c5575d5cfddcc4ba10895f
Reviewed-on: https://go-review.googlesource.com/c/go/+/272666
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This issue was already fixed at tip. Just adding the test that
failed on 1.14/1.15.
Update #42753
Change-Id: I00d13ade476b9c17190d762d7fdcb30cf6c83954
Reviewed-on: https://go-review.googlesource.com/c/go/+/272029
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>
Same reason as CL 270057, but for OpLoad.
Fixes#42727
Change-Id: Iebb1a8110f29427a0aed3b5e3e84f0540de3d1b7
Reviewed-on: https://go-review.googlesource.com/c/go/+/271906
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: David Chase <drchase@google.com>
When inlining a function call expression, it's possible that the
function callee subexpression has side effects that need to be
preserved. This used to not be an issue, because inlining wouldn't
recognize these as inlinable anyway. But golang.org/cl/266199 extended
the inlining logic to recognize more cases, but did not notice that
the actual inlining code was discarding side effects.
Issue identified by danscales@.
Fixes#42703.
Change-Id: I95f8fc076b6ca4e9362e80ec26dad9d87a5bc44a
Reviewed-on: https://go-review.googlesource.com/c/go/+/271219
Reviewed-by: Dan Scales <danscales@google.com>
Trust: Dan Scales <danscales@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
Within the frontend, we generally don't guarantee uniqueness of
anonymous types. For example, each struct type literal gets
represented by its own types.Type instance.
However, the field tracking code was using the struct type as a map
key. This broke in golang.org/cl/256457, because that CL started
changing the inlined parameter variables from using the types.Type of
the declared parameter to that of the call site argument. These are
always identical types (e.g., types.Identical would report true), but
they can be different pointer values, causing the map lookup to fail.
The easiest fix is to simply get rid of the map and instead use
Node.Opt for tracking the types.Field. To mitigate against more latent
field tracking failures (e.g., if any other code were to start trying
to use Opt on ODOT/ODOTPTR fields), we store this field
unconditionally. I also expect having the types.Field will be useful
to other frontend code in the future.
Finally, to make it easier to test field tracking without having to
run make.bash with GOEXPERIMENT=fieldtrack, this commit adds a
-d=fieldtrack flag as an alternative way to enable field tracking
within the compiler. See also #42681.
Fixes#42686.
Change-Id: I6923d206d5e2cab1e6798cba36cae96c1eeaea55
Reviewed-on: https://go-review.googlesource.com/c/go/+/271217
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
Some rules for PPC64 were checking for a case
where a shift followed by an 'and' of a mask could
be lowered, depending on the format of the mask. The
function to verify if the mask was valid for this purpose
was not checking if the mask was 0 which we don't want to
allow. This case can happen if previous optimizations
resulted in that mask value.
This fixes isPPC64ValidShiftMask to check for a mask of 0 and return
false.
This also adds a codegen testcase to verify it doesn't try to
match the rules in the future.
Fixes#42610
Change-Id: I565d94e88495f51321ab365d6388c01e791b4dbb
Reviewed-on: https://go-review.googlesource.com/c/go/+/270358
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Paul Murphy <murp@ibm.com>
Reviewed-by: Carlos Eduardo Seo <carlos.seo@linaro.org>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
mips SRA/SLL/SRL shift amounts are used mod 32; this change aligns the
XXXconst rules to mask the shift amount by &31.
Passes
$ GOARCH=mips go build -toolexec 'toolstash -cmp' -a std
$ GOARCH=mipsle go build -toolexec 'toolstash -cmp' -a std
Fixes#42587
Change-Id: I6003ebd0bc500fba4cf6fb10254e1b557bf8c48f
Reviewed-on: https://go-review.googlesource.com/c/go/+/270117
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
In certain cases, the declkared type of an OpIData is interface{}.
This was not expected (since interface{} is a pair, right?) and
thus caused a crash. What is intended is that these be treated as
a byteptr, so do that instead (this is what happens in 1.15).
Fixes#42568.
Change-Id: Id7c9e5dc2cbb5d7c71c6748832491ea62b0b339f
Reviewed-on: https://go-review.googlesource.com/c/go/+/270057
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Change-Id: I9044de7829d22addb5bc570401508082e3f007eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/269057
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When a variable symbol is both imported (possibly through
inlining) and linkname'd, make sure its LSym is marked as
non-package for symbol indexing in the object file, so it is
resolved by name and dedup'd with the original definition.
Fixes#42401.
Change-Id: I8e90c0418c6f46a048945c5fdc06c022b77ed68d
Reviewed-on: https://go-review.googlesource.com/c/go/+/268178
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Fixes#42445
Change-Id: I9653ef094dba2a1ac2e3daaa98279d10df17a2a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/268257
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Trust: Martin Möhrmann <moehrmann@google.com>
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Martin Möhrmann <moehrmann@google.com>
CL 244579 added guard clauses to prevent a faulty state that was
possible under the incorrect logic of the uniquePred loop in
addLocalInductiveFacts. That faulty state was still making the
intended optimization, but not for the correct reason.
Removing the faulty state also removed the overly permissive application
of the optimization, and therefore made these two tests fail.
We disabled the tests of this optimization in CL 244579 to allow us to
quickly apply the fix in the CL. This CL now corrects the logic of the
uniquePred loop in order to apply the optimization correctly.
The comment above the uniquePred loop says that it will follow unique
predecessors until it reaches a join point. Without updating the child
node on each iteration, it cannot follow the chain of unique
predecessors more than one step. Adding the update to the child node
on each iteration of the loop allows the logic to follow the chain of
unique predecessors until reaching a join point (because a non-unique
predecessor will signify a join point).
Updates #40502.
Change-Id: I23d8367046a2ab3ce4be969631f9ba15dc533e6c
Reviewed-on: https://go-review.googlesource.com/c/go/+/246157
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
This CL adds support for inlining type switches, including exporting
and importing them.
Type switches are represented mostly the same as expression switches.
However, if the type switch guard includes a short variable
declaration, then there are two differences: (1) there's an ONONAME
(in the OTYPESW's Left) to represent the overall pseudo declaration;
and (2) there's an ONAME (in each OCASE's Rlist) to represent the
per-case variables.
For simplicity, this CL simply writes out each variable separately
using iimport/iiexport's normal Vargen mechanism for disambiguating
identically named variables within a function. This could be improved
somewhat, but inlinable type switches are probably too uncommon to
merit the complexity.
While here, remove "case OCASE" from typecheck1. We only type check
"case" clauses as part of a "select" or "switch" statement, never as
standalone statements.
Fixes#37837
Change-Id: I8f42f6c9afdd821d6202af4a6bf1dbcbba0ef424
Reviewed-on: https://go-review.googlesource.com/c/go/+/266203
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Optimize combinations of left and right shifts by a constant value
into a 'rotate then insert selected bits [into zero]' instruction.
Use the same instruction for contiguous masks since it has some
benefits over 'and immediate' (not restricted to 32-bits, does not
overwrite source register).
To keep the complexity of this change under control I've only
implemented 64 bit operations for now.
There are a lot more optimizations that can be done with this
instruction family. However, since their function overlaps with other
instructions we need to be somewhat careful not to break existing
optimization rules by creating optimization dead ends. This is
particularly true of the load/store merging rules which contain lots
of zero extensions and shifts.
This CL does interfere with the store merging rules when an operand
is shifted left before it is stored:
binary.BigEndian.PutUint64(b, x << 1)
This is unfortunate but it's not critical and somewhat complex so
I plan to fix that in a follow up CL.
file before after Δ %
addr2line 4117446 4117282 -164 -0.004%
api 4945184 4942752 -2432 -0.049%
asm 4998079 4991891 -6188 -0.124%
buildid 2685158 2684074 -1084 -0.040%
cgo 4553732 4553394 -338 -0.007%
compile 19294446 19245070 -49376 -0.256%
cover 4897105 4891319 -5786 -0.118%
dist 3544389 3542785 -1604 -0.045%
doc 3926795 3927617 +822 +0.021%
fix 3302958 3293868 -9090 -0.275%
link 6546274 6543456 -2818 -0.043%
nm 4102021 4100825 -1196 -0.029%
objdump 4542431 4548483 +6052 +0.133%
pack 2482465 2416389 -66076 -2.662%
pprof 13366541 13363915 -2626 -0.020%
test2json 2829007 2761515 -67492 -2.386%
trace 10216164 10219684 +3520 +0.034%
vet 6773956 6773572 -384 -0.006%
total 107124151 106917891 -206260 -0.193%
Change-Id: I7591cce41e06867ba10a745daae9333513062746
Reviewed-on: https://go-review.googlesource.com/c/go/+/233317
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Michael Munday <mike.munday@ibm.com>
We already remove racefuncenter and racefuncexit if they are not
needed (i.e. the function doesn't have any other race calls).
racefuncenterfp is like racefuncenter but used on LR machines.
Remove unnecessary racefuncenterfp as well.
Change-Id: I65edb00e19c6d9ab55a204cbbb93e9fb710559f1
Reviewed-on: https://go-review.googlesource.com/c/go/+/267099
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>
In golang.org/cl/266199, I reused the existing code in inlining that
recognizes anonymous variables. However, it turns out that code
mistakenly recognizes anonymous return parameters as named when
inlining a function from the same package.
The issue is funcargs (which is only used for functions parsed from
source) synthesizes ~r names for anonymous return parameters, but
funcargs2 (which is only used for functions imported from export data)
does not.
This CL fixes the behavior so that anonymous return parameters are
handled identically whether a function is inlined within the same
package or across packages. It also adds a proper cross-package test
case demonstrating #33160 is fixed in both cases.
Change-Id: Iaa39a23f5666979a1f5ca6d09fc8c398e55b784c
Reviewed-on: https://go-review.googlesource.com/c/go/+/266719
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
reassignVisitor was short-circuiting on assignment statements after
checking the LHS, but there might be further assignment statements
nested within the RHS expressions.
Fixes#42284.
Change-Id: I175eef87513b973ed5ebe6a6527adb9766dde6cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/266618
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>
TryBot-Result: Go Bot <gobot@golang.org>
A method selector expression can pick out a method or promoted method
(represented by ODOTMETH), but it can also pick out an interface
method from an embedded interface-typed field (represented by
ODOTINTER).
In the case that we're picking out an interface method, we're not able
to fully devirtualize the method call. However, we're still able to
improve escape analysis somewhat. E.g., the included test case
demonstrates that we can optimize "i.M()" to "i.(T).I.M()", which
means the T literal can be stack allocated instead of heap allocated.
Fixes#42279.
Change-Id: Ifa21d19011e2f008d84f9624b7055b4676b6d188
Reviewed-on: https://go-review.googlesource.com/c/go/+/266300
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
After inlining, add a pass that looks for interface calls where we can
statically determine the interface value's concrete type. If such a
case is found, insert an explicit type assertion to the concrete type
so that escape analysis can see it.
Fixes#33160.
Change-Id: I36932c691693f0069e34384086d63133e249b06b
Reviewed-on: https://go-review.googlesource.com/c/go/+/264837
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
The inlining pass previously bailed upon encountering a go or defer statement, so it would not inline functions e.g. used to provide arguments to the deferred function. This change preserves the behavior of not inlining the
deferred function itself, but it allows the inlining walk to proceed into its arguments.
Fixes#42194
Change-Id: I4e82029d8dcbe69019cc83ae63a4b29af45ec777
Reviewed-on: https://go-review.googlesource.com/c/go/+/264997
Run-TryBot: 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>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
With previous CLs, internal linking without cgo should work well.
Enable it by default. And stop always requiring cgo.
Enable tests that were previously disabled due to the lack of
internal linking.
Updates #38485.
Change-Id: I45125b9c263fd21d6847aa6b14ecaea3a2989b29
Reviewed-on: https://go-review.googlesource.com/c/go/+/265121
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
pointers to go:notinheap types should be treated as scalars. That
means they shouldn't be stored directly in interfaces, or directly
in reflect.Value.ptr.
Also be sure to use uintpr to compare such pointers in reflect.DeepEqual.
Fixes#42076
Change-Id: I53735f6d434e9c3108d4940bd1bae14c61ef2a74
Reviewed-on: https://go-review.googlesource.com/c/go/+/264480
Trust: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
storeType splits compound stores up into a scalar parts and a pointer parts.
The scalar part happens unconditionally, and the pointer part happens
under the guard of a write barrier check.
Types which are declared as pointers, but are represented as scalars because
they might have "bad" values, were not handled correctly here. They ended
up not getting stored in either set.
Fixes#42032
Change-Id: I46f6600075c0c370e640b807066247237f93c7ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/264300
Trust: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Combine (AND m (SRWconst x)) or (SRWconst (AND m x)) when mask m is
and the shift value produce constant which can be encoded into an
RLWINM instruction.
Combine (CLRLSLDI (SRWconst x)) if the combining of the underling rotate
masks produces a constant which can be encoded into RLWINM.
Likewise for (SLDconst (SRWconst x)) and (CLRLSDI (RLWINM x)).
Combine rotate word + and operations which can be encoded as a single
RLWINM/RLWNM instruction.
The most notable performance improvements arise from the crypto
benchmarks below (GOARCH=power8 on a ppc64le/linux):
pkg:golang.org/x/crypto/blowfish goos:linux goarch:ppc64le
ExpandKeyWithSalt 52.2µs ± 0% 47.5µs ± 0% -8.88%
ExpandKey 44.4µs ± 0% 40.3µs ± 0% -9.15%
pkg:golang.org/x/crypto/ssh/internal/bcrypt_pbkdf goos:linux goarch:ppc64le
Key 57.6ms ± 0% 52.3ms ± 0% -9.13%
pkg:golang.org/x/crypto/bcrypt goos:linux goarch:ppc64le
Equal 90.9ms ± 0% 82.6ms ± 0% -9.13%
DefaultCost 91.0ms ± 0% 82.7ms ± 0% -9.12%
Change-Id: I59a0ca29face38f4ab46e37124c32906f216c4ce
Reviewed-on: https://go-review.googlesource.com/c/go/+/260798
Run-TryBot: Carlos Eduardo Seo <carlos.seo@linaro.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Carlos Eduardo Seo <carlos.seo@linaro.com>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
This change makes a first connection between the compiler and types2.
When the -G flag is provided, the compiler accepts code using type
parameters; with this change generic code is also type-checked (but
then compilation ends).
Change-Id: I0fa6f6213267a458a6b33afe8ff26869fd838a63
Reviewed-on: https://go-review.googlesource.com/c/go/+/264303
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Currently, "x &^ y" gets rewriten into "x & ^y" during walk. It adds
unnecessary complexity to other parts, which must aware about this.
Instead, we can just implement "&^" in the conversion to SSA, so "&^"
can be handled like other binary operators.
However, this CL does not pass toolstash-check. It seems that implements
"&^" in the conversion to SSA causes registers allocation change.
With the parent:
obj: 00212 (.../src/runtime/complex.go:47) MOVQ X0, AX
obj: 00213 (.../src/runtime/complex.go:47) BTRQ $63, AX
obj: 00214 (.../src/runtime/complex.go:47) MOVQ "".n(SP), CX
obj: 00215 (.../src/runtime/complex.go:47) MOVQ $-9223372036854775808, DX
obj: 00216 (.../src/runtime/complex.go:47) ANDQ DX, CX
obj: 00217 (.../src/runtime/complex.go:47) ORQ AX, CX
With this CL:
obj: 00212 (.../src/runtime/complex.go:47) MOVQ X0, AX
obj: 00213 (.../src/runtime/complex.go:47) BTRQ $63, AX
obj: 00214 (.../src/runtime/complex.go:47) MOVQ $-9223372036854775808, CX
obj: 00215 (.../src/runtime/complex.go:47) MOVQ "".n(SP), DX
obj: 00216 (.../src/runtime/complex.go:47) ANDQ CX, DX
obj: 00217 (.../src/runtime/complex.go:47) ORQ AX, DX
Change-Id: I80acf8496a91be4804fb7ef3df04c19baae2754c
Reviewed-on: https://go-review.googlesource.com/c/go/+/264660
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>
For follow up CL, which will defer lowering OANDNOT until SSA.
Change-Id: I5a988d0b8f0ae664580f08b123811b2a31ef55c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/265040
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 top of the merge, the following fixes were applied:
+ Debug["G"] changed to Debug.G, following golang.org/cl/263539.
+ issue42058a.go and issue42058b.go were skipped in
types2/stdlib_test.go. go/types does not produce errors related to
channel element size.
Change-Id: I59fc84e12a2d728ef789fdc616f7afe80e451283
We never supported symbol larger than 2GB (issue #9862), so the
object file uses 32-bit for symbol sizes. Check and reject too
large symbol before truncating its size.
Fixes#42054.
Change-Id: I0d1d585ebdba9556f2fd3a97043bd4296d5cc9e4
Reviewed-on: https://go-review.googlesource.com/c/go/+/263641
Trust: Cherry Zhang <cherryyz@google.com>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
This helps the compiler reports the right place where the type declared,
instead of relying on global lineno, which maybe set to wrong value at
the time the error is reported.
Fixes#42058
Change-Id: I06d34aa9b0236d122f4a0d72e66675ded022baac
Reviewed-on: https://go-review.googlesource.com/c/go/+/263597
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>
OCALLPART is exported in its original form, which is as an OXDOT.
The body of the method value wrapper created in makepartialcall() was
not being typechecked, and that was causing a problem during escape
analysis, so I added code to typecheck the body.
The go executable got slightly bigger with this change (13598111 ->
13598905), because of extra exported methods with OCALLPART (I
believe), while the text size got slightly smaller (9686964 ->
9686643).
This is mainly part of the work to make sure all function bodies can
be exported (for purposes of generics), but might as well fix the
OCALLPART inlining bug as well.
Fixes#18493
Change-Id: If7aa055ff78ed7a6330c6a1e22f836ec567d04fd
Reviewed-on: https://go-review.googlesource.com/c/go/+/263620
Run-TryBot: 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>
asNode(t.Nod).Name.Param will be nil for builtin types (i.e., the
universal predeclared types and unsafe.Pointer). These types can't be
part of a cycle anyway, so we can just skip them.
Fixes#42075.
Change-Id: Ic7a44de65c6bfd16936545dee25e36de8850acf3
Reviewed-on: https://go-review.googlesource.com/c/go/+/263717
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Before generating wrapper function, turn any f(a, b, []T{c, d, e}...)
calls back into f(a, b, c, d, e). This allows the existing code for
recognizing and specially handling unsafe.Pointer->uintptr conversions
to correctly handle variadic arguments too.
Fixes#41460.
Change-Id: I0a1255abdd1bd5dafd3e89547aedd4aec878394c
Reviewed-on: https://go-review.googlesource.com/c/go/+/263297
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.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>
This CL replaces the ad hoc and duplicated logic for detecting
inlinable calls with a single "inlCallee" function, which uses the
"staticValue" helper function introduced in an earlier commit.
Updates #41474.
Change-Id: I103d4091b10366fce1344ef2501222b7df68f21d
Reviewed-on: https://go-review.googlesource.com/c/go/+/256460
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Matthew Dempsky <mdempsky@google.com>
We already allow inlining "if" and "goto" statements, so we might as
well allow "for" loops too. The majority of frontend support is
already there too.
The critical missing feature at the moment is that inlining doesn't
properly reassociate OLABEL nodes with their control statement (e.g.,
OFOR) after inlining. This eventually causes SSA construction to fail.
As a workaround, this CL only enables inlining for unlabeled "for"
loops. It's left to a (yet unplanned) future CL to add support for
labeled "for" loops.
The increased opportunity for inlining leads to a small growth in
binary size. For example:
$ size go.old go.new
text data bss dec hex filename
9740163 320064 230656 10290883 9d06c3 go.old
9793399 320064 230656 10344119 9dd6b7 go.new
Updates #14768.
Fixes#41474.
Change-Id: I827db0b2b9d9fa2934db05caf6baa463f0cd032a
Reviewed-on: https://go-review.googlesource.com/c/go/+/256459
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Escape analysis is currently very naive about identifying calls to
known functions: it only recognizes direct calls to a declared
function, or direct calls to a closure.
This CL adds a new "staticValue" helper function that can trace back
through local variables that were initialized and never reassigned
based on a similar optimization already used by inlining. (And to be
used by inlining in a followup CL.)
Updates #41474.
Change-Id: I8204fd3b1e150ab77a27f583985cf099a8572b2e
Reviewed-on: https://go-review.googlesource.com/c/go/+/256458
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: David Chase <drchase@google.com>
The gofrontend code doesn't correctly handle inlining a function that
refers to a constant with methods.
For #35739
Change-Id: I6bd0b5cd4272dbe9969634b4821e668acacfdcf9
Reviewed-on: https://go-review.googlesource.com/c/go/+/261662
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Providing the -G flag instructs the compiler to accept type parameters.
For now, the compiler only parses such files and then exits.
Added a new test directory (test/typeparam) and initial test case.
Port from dev.go2go branch.
Change-Id: Ic11e33a9d5f012f8def0bdae205043659562ac73
Reviewed-on: https://go-review.googlesource.com/c/go/+/261660
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
We are converting from using error-prone ad-hoc syntax // +build lines
to less error-prone, standard boolean syntax //go:build lines.
The timeline is:
Go 1.16: prepare for transition
- Builds still use // +build for file selection.
- Source files may not contain //go:build without // +build.
- Builds fail when a source file contains //go:build lines without // +build lines. <<<
Go 1.17: start transition
- Builds prefer //go:build for file selection, falling back to // +build
for files containing only // +build.
- Source files may contain //go:build without // +build (but they won't build with Go 1.16).
- Gofmt moves //go:build and // +build lines to proper file locations.
- Gofmt introduces //go:build lines into files with only // +build lines.
- Go vet rejects files with mismatched //go:build and // +build lines.
Go 1.18: complete transition
- Go fix removes // +build lines, leaving behind equivalent // +build lines.
This CL provides part of the <<< marked line above in the Go 1.16 step:
rejecting files containing //go:build but not // +build.
The standard go command checks only consider the top of the file.
This compiler check, along with a separate go vet check for ignored files,
handles the remainder of the file.
For #41184.
Change-Id: I014006eebfc84ab5943de18bc90449e534f150a2
Reviewed-on: https://go-review.googlesource.com/c/go/+/240601
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
We lost a sign extension that was necessary. The nonnegative comparison
didn't have the correct extension on it. If the larger constant is
positive, but its shorter sign extension is negative, the rule breaks.
Fixes#41872
Change-Id: I6592ef103f840fbb786bf8cb94fd8804c760c976
Reviewed-on: https://go-review.googlesource.com/c/go/+/260701
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alberto Donizetti <alb.donizetti@gmail.com>
Backstop support for non-sse2 chips now that 387 is gone.
RELNOTE=yes
Change-Id: Ib10e69c4a3654c15a03568f93393437e1939e013
Reviewed-on: https://go-review.googlesource.com/c/go/+/260017
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Unlike iOS, macOS ARM64 is more of a fully featured OS. Enable
more tests.
Updates #38485.
Change-Id: I2e2240c848d21996db2b950a4a6856987f7a652c
Reviewed-on: https://go-review.googlesource.com/c/go/+/256919
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Two part fix:
1) bring the type "correction" forward from a later CL in the expand calls series
2) when a leaf-selwect is rewritten in place, update the type (it might have been
changed by the type correction in 1).
Fixes#41736.
Change-Id: Id097efd10481bf0ad92aaead81a7207221c144b5
Reviewed-on: https://go-review.googlesource.com/c/go/+/259203
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>
This change renames mustHeapAlloc to heapAllocReason, and changes it
to return the reason why the argument must escape, so we don't have to
re-deduce it in its callers just to print the escape reason. It also
embeds isSmallMakeSlice body in heapAllocReason, since the former was
only used by the latter, and deletes isSmallMakeSlice.
An outdated TODO to remove smallintconst, which the TODO claimed was
only used in one place, was also removed, since grepping shows we
currently call smallintconst in 11 different places.
Change-Id: I0bd11bf29b92c4126f5bb455877ff73217d5a155
Reviewed-on: https://go-review.googlesource.com/c/go/+/258678
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
My last 387 CL. So sad ... ... ... ... not!
Fixes#40255
Change-Id: I8d4ddb744b234b8adc735db2f7c3c7b6d8bbdfa4
Reviewed-on: https://go-review.googlesource.com/c/go/+/258957
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
A recent change to improve shifts was generating some
invalid cases when the rule was based on an AND. The
extended mnemonics CLRLSLDI and CLRLSLWI only allow
certain values for the operands and in the mask case
those values were not being checked properly. This
adds a check to those rules to verify that the
'b' and 'n' values used when an AND was part of the rule
have correct values.
There was a bug in some diag messages in asm9. The
message expected 3 values but only provided 2. Those are
corrected here also.
The test/codegen/shift.go was updated to add a few more
cases to check for the case mentioned here.
Some of the comments that mention the order of operands
in these extended mnemonics were wrong and those have been
corrected.
Fixes#41683.
Change-Id: If5bb860acaa5051b9e0cd80784b2868b85898c31
Reviewed-on: https://go-review.googlesource.com/c/go/+/258138
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Paul Murphy <murp@ibm.com>
Reviewed-by: Carlos Eduardo Seo <carlos.seo@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Similar to how we report initialization loops in initorder.go and type
alias loops in typecheck.go, this CL updates align.go to warn about
invalid recursive types. The code is based on the loop code from
initorder.go, with minimal changes to adapt from detecting
variable/function initialization loops to detecting type declaration
loops.
Thanks to Cuong Manh Le for investigating this, helping come up with
test cases, and exploring solutions.
Fixes#41575
Updates #41669.
Change-Id: Idb2cb8c5e1d645e62900e178fcb50af33e1700a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/258177
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
As part of type checking make's arguments, we were converting untyped
float and complex constant arguments to integers. However, we were
doing this without concern for whether the argument was a declared
constant. Thus a call like "make([]T, n)" could change n from an
untyped float or untyped complex to an untyped integer.
The fix here is to simply change checkmake to not call SetVal, which
will be handled by defaultlit anyway. However, we also need to
properly return the defaultlit result value to the caller, so
checkmake's *Node parameter is also changed to **Node.
Fixes#41680.
Change-Id: I858927a052f384ec38684570d37b10a6906961f7
Reviewed-on: https://go-review.googlesource.com/c/go/+/257966
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
This adds support for the extswsli instruction which combines
extsw followed by a shift.
New benchmark demonstrates the improvement:
name old time/op new time/op delta
ExtShift 1.34µs ± 0% 1.30µs ± 0% -3.15% (p=0.057 n=4+3)
Change-Id: I21b410676fdf15d20e0cbbaa75d7c6dcd3bbb7b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/257017
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Carlos Eduardo Seo <carlos.seo@gmail.com>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
When explaining why the slice from a make() call escapes for the -m -m
message, we print "non-const size" if any one of Isconst(n.Left) and
Isconst(n.Right) return false; but for OMAKESLICE nodes with no cap,
n.Right is nil, so Isconst(n.Right, CTINT) will be always false.
Only call Isconst on n.Right if it's not nil.
Fixes#41635
Change-Id: I8729801a9b234b68ae40adad64d66fa7653adf09
Reviewed-on: https://go-review.googlesource.com/c/go/+/257641
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
We grow the backing store on append by 2x for small sizes and 1.25x
for large sizes. The threshold we use for picking the growth factor
used to depend on the old length, not the old capacity. That's kind of
unfortunate, because then doing append(s, 0, 0) and append(append(s,
0), 0) do different things. (If s has one more spot available, then
the former expression chooses its growth based on len(s) and the
latter on len(s)+1.) If we instead use the old capacity, we get more
consistent behavior. (Both expressions use len(s)+1 == cap(s) to
decide.)
Fixes#41239
Change-Id: I40686471d256edd72ec92aef973a89b52e235d4b
Reviewed-on: https://go-review.googlesource.com/c/go/+/257338
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>
The revised test now checks that unsafe-uintptr correctly works for
variadic uintptr parameters too, and the CL corrects the code so this
code compiles again.
The pointers are still not kept alive properly. That will be fixed by
a followup CL. But this CL at least allows programs not affected by
that to build again.
Updates #24991.
Updates #41460.
Change-Id: If4c39167b6055e602213fb7522c4f527c43ebda9
Reviewed-on: https://go-review.googlesource.com/c/go/+/255877
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
//go:notinheap
type T int
type U T
We already correctly propagate the notinheap-ness of T to U. But we
have an assertion in the typechecker that if there's no explicit
//go:notinheap associated with U, then report an error. Get rid of
that error so that implicit propagation is allowed.
Adjust the tests so that we make sure that uses of types like U
do correctly report an error when U is used in a context that might
cause a Go heap allocation.
Fixes#41451
Update #40954
Update #41432
Change-Id: I1692bc7cceff21ebb3f557f3748812a40887118d
Reviewed-on: https://go-review.googlesource.com/c/go/+/255637
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
This change adds rules to find pairs of instructions that can
be combined into a single shifts. These instruction sequences
are common in array addressing within loops. Improvements can
be seen in many crypto packages and the hash packages.
These are based on the extended mnemonics found in the ISA
sections C.8.1 and C.8.2.
Some rules in PPC64.rules were moved because the ordering prevented
some matching.
The following results were generated on power9.
hash/crc32:
CRC32/poly=Koopman/size=40/align=0 195ns ± 0% 163ns ± 0% -16.41%
CRC32/poly=Koopman/size=40/align=1 200ns ± 0% 163ns ± 0% -18.50%
CRC32/poly=Koopman/size=512/align=0 1.98µs ± 0% 1.67µs ± 0% -15.46%
CRC32/poly=Koopman/size=512/align=1 1.98µs ± 0% 1.69µs ± 0% -14.80%
CRC32/poly=Koopman/size=1kB/align=0 3.90µs ± 0% 3.31µs ± 0% -15.27%
CRC32/poly=Koopman/size=1kB/align=1 3.85µs ± 0% 3.31µs ± 0% -14.15%
CRC32/poly=Koopman/size=4kB/align=0 15.3µs ± 0% 13.1µs ± 0% -14.22%
CRC32/poly=Koopman/size=4kB/align=1 15.4µs ± 0% 13.1µs ± 0% -14.79%
CRC32/poly=Koopman/size=32kB/align=0 137µs ± 0% 105µs ± 0% -23.56%
CRC32/poly=Koopman/size=32kB/align=1 137µs ± 0% 105µs ± 0% -23.53%
crypto/rc4:
RC4_128 733ns ± 0% 650ns ± 0% -11.32% (p=1.000 n=1+1)
RC4_1K 5.80µs ± 0% 5.17µs ± 0% -10.89% (p=1.000 n=1+1)
RC4_8K 45.7µs ± 0% 40.8µs ± 0% -10.73% (p=1.000 n=1+1)
crypto/sha1:
Hash8Bytes 635ns ± 0% 613ns ± 0% -3.46% (p=1.000 n=1+1)
Hash320Bytes 2.30µs ± 0% 2.18µs ± 0% -5.38% (p=1.000 n=1+1)
Hash1K 5.88µs ± 0% 5.38µs ± 0% -8.62% (p=1.000 n=1+1)
Hash8K 42.0µs ± 0% 37.9µs ± 0% -9.75% (p=1.000 n=1+1)
There are other improvements found in golang.org/x/crypto which are all in the
range of 5-15%.
Change-Id: I193471fbcf674151ffe2edab212799d9b08dfb8c
Reviewed-on: https://go-review.googlesource.com/c/go/+/252097
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: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com>
"cannot assign to" compiler errors are very laconic: they never
explain why the lhs cannot be assigned to (with one exception, when
assigning to a struct field in a map).
This change makes them a little more specific, in two more cases: when
assigning to a string, or to a const; by giving a very brief reason
why the lhs cannot be assigned to.
Change-Id: I244cca7fc3c3814e00e0ccadeec62f747c293979
Reviewed-on: https://go-review.googlesource.com/c/go/+/255199
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Update #40954
Change-Id: Ifaab7349631ccb12fc892882bbdf7f0ebf3d845f
Reviewed-on: https://go-review.googlesource.com/c/go/+/251158
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Keith Randall <khr@golang.org>
They can't reasonably be allocated on the heap. Not a huge deal, but
it has an interesting and useful side effect.
After CL 249917, the compiler and runtime treat pointers to
go:notinheap types as uintptrs instead of real pointers (no write
barrier, not processed during stack scanning, ...). That feature is
exactly what we want for cgo to fix#40954. All the cases we have of
pointers declared in C, but which might actually be filled with
non-pointer data, are of this form (JNI's jobject heirarch, Darwin's
CFType heirarchy, ...).
Fixes#40954
Change-Id: I44a3b9bc2513d4287107e39d0cbbd0efd46a3aae
Reviewed-on: https://go-review.googlesource.com/c/go/+/250940
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The alias doesn't need to be marked go:notinheap. It gets its
notinheap-ness from the target type.
Without this change, the type alias test in the notinheap.go file
generates these two errors:
notinheap.go:62: misplaced compiler directive
notinheap.go:63: type nih must be go:notinheap
The first is a result of go:notinheap pragmas not applying
to type alias declarations.
The second is the result of then trying to match the notinheap-ness
of the alias and the target type.
Add a few more go:notinheap tests while we are here.
Update #40954
Change-Id: I067ec47698df6e9e593e080d67796fd05a1d480f
Reviewed-on: https://go-review.googlesource.com/c/go/+/250939
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Trust: Keith Randall <khr@golang.org>
This allows the global initializers function to go through normal
mid-end optimizations (e.g., inlining, escape analysis) like any other
function.
Updates #33485.
Change-Id: I9bcfe98b8628d1aca09b4c238d8d3b74c69010a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/254839
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
runtime.GC() doesn't guarantee the finalizer has run, so use a channel
instead to make sure finalizer was run in call to "after()".
Fixes#41361
Change-Id: I69c801e29aea49757ea72c52e8db13239de19ddc
Reviewed-on: https://go-review.googlesource.com/c/go/+/254401
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
So we can insert theses OVARLIVE nodes right after OpStaticCall in SSA.
This helps fixing issue that unsafe-uintptr arguments are not kept alive
during return statement, or can be kept alive longer than expected.
Fixes#24491
Change-Id: Ic04a5d1bbb5c90dcfae65bd95cdd1da393a66800
Reviewed-on: https://go-review.googlesource.com/c/go/+/254397
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This CL changes "T literal.M" error message to "T{...}.M". It's clearer
expression and focusing user on actual issue.
Updates #38745
Change-Id: I84b455a86742f37e0bde5bf390aa02984eecc3c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/253677
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Currently, the statement:
go g(uintptr(f()))
gets rewritten into:
tmp := f()
newproc(8, g, uintptr(tmp))
runtime.KeepAlive(tmp)
which doesn't guarantee that tmp is still alive by time the g call is
scheduled to run.
This CL fixes the issue, by wrapping g call in a closure:
go func(p unsafe.Pointer) {
g(uintptr(p))
}(f())
then this will be rewritten into:
tmp := f()
go func(p unsafe.Pointer) {
g(uintptr(p))
runtime.KeepAlive(p)
}(tmp)
runtime.KeepAlive(tmp) // superfluous, but harmless
So the unsafe.Pointer p will be kept alive at the time g call runs.
Updates #24491
Change-Id: Ic10821251cbb1b0073daec92b82a866c6ebaf567
Reviewed-on: https://go-review.googlesource.com/c/go/+/253457
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The order array was zero initialized by the compiler, but ends up being
overwritten by the runtime anyway.
So let the runtime takes full responsibility for initializing, save us
one instruction per select.
Fixes#40399
Change-Id: Iec1eca27ad7180d4fcb3cc9ef97348206b7fe6b8
Reviewed-on: https://go-review.googlesource.com/c/go/+/251517
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The current command will run this entire set of tests, which takes a
noticeable amount of time. Contributors may wish to run only a subset of
these tests to save time/compute (e.g. when iterating on a CL that
failed tests in that subset). Listing file(s) as operands to the command
will run only those tests.
Change-Id: I1874c43681a594190bc40b61cee0b8d321be73f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/242997
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Flag constant Ops on arm and arm64 are under refactoring, this change adds
a couple of testcases that verify the behavior of 'noov' branches.
Updates #39505
Updates #38740
Updates #39303
Change-Id: I493344b52276900cd296c32da494d72932dfc9be
Reviewed-on: https://go-review.googlesource.com/c/go/+/238677
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
We're using sort.SliceStable, so no need to keep track of indexes as well.
Use a more robust test for whether a node is a call.
Add a test that we're actually reordering comparisons. This test fails
without the alg.go changes in this CL because eqstring uses OCALLFUNC
instead of OCALL for its data comparisons.
Update #8606
Change-Id: Ieeec33434c72e3aa328deb11cc415cfda05632e2
Reviewed-on: https://go-review.googlesource.com/c/go/+/237921
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This merges an lis + subf into subfic, and for 32b constants
lwa + subf into oris + ori + subf.
The carry bit is no longer used in code generation, therefore
I think we can clobber it as needed. Note, lowered borrow/carry
arithmetic is self-contained and thus is not affected.
A few extra rules are added to ensure early transformations to
SUBFCconst don't trip up earlier rules, fold constant operations,
or otherwise simplify lowering. Likewise, tests are added to
ensure all rules are hit. Generic constant folding catches
trivial cases, however some lowering rules insert arithmetic
which can introduce new opportunities (e.g BitLen or Slicemask).
I couldn't find a specific benchmark to demonstrate noteworthy
improvements, but this is generating subfic in many of the default
bent test binaries, so we are at least saving a little code space.
Change-Id: Iad7c6e5767eaa9dc24dc1c989bd1c8cfe1982012
Reviewed-on: https://go-review.googlesource.com/c/go/+/249461
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com>
Right now we just prevent such types from being on the heap. This CL
makes it so they cannot appear on the stack either. The distinction
between heap and stack is pretty vague at the language level (e.g. it
is affected by -N), and we don't need the flexibility anyway.
Once go:notinheap types cannot be in either place, we don't need to
consider pointers to such types to be pointers, at least according to
the garbage collector and stack copying. (This is the big win of this
CL, in my opinion.)
The distinction between HasPointers and HasHeapPointer no longer
exists. There is only HasPointers.
This CL is cleanup before possible use of go:notinheap to fix#40954.
Update #13386
Change-Id: Ibd895aadf001c0385078a6d4809c3f374991231a
Reviewed-on: https://go-review.googlesource.com/c/go/+/249917
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
With this patch, opt pass can expose more obvious constant-folding
opportunites.
Example:
func test(i int) int {return (i+8)-(i+4)}
The previous version:
MOVD "".i(FP), R0
ADD $8, R0, R1
ADD $4, R0, R0
SUB R0, R1, R0
MOVD R0, "".~r1+8(FP)
RET (R30)
The optimized version:
MOVD $4, R0
MOVD R0, "".~r1+8(FP)
RET (R30)
This patch removes some existing reassociation rules, such as "x+(z-C)",
because the current generic rewrite rules will canonicalize "x-const"
to "x+(-const)", making "x+(z-C)" equal to "x+(z+(-C))".
This patch also adds test cases.
Change-Id: I857108ba0b5fcc18a879eeab38e2551bc4277797
Reviewed-on: https://go-review.googlesource.com/c/go/+/237137
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
go1.14 drop nacl support, as go1.15 was released, go1.13 is not
supported anymore, nacl is absolutely gone.
Change-Id: I05efb46891ec875b08da8f2996751a8e9cb57d0c
Reviewed-on: https://go-review.googlesource.com/c/go/+/249977
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
checkptr has code to recognize &^ expressions, but it didn't take into
account that "p &^ x" gets rewritten to "p & ^x" during walk, which
resulted in false positive diagnostics.
This CL changes walkexpr to mark OANDNOT expressions with Implicit
when they're rewritten to OAND, so that walkCheckPtrArithmetic can
still recognize them later.
It would be slightly more idiomatic to instead mark the OBITNOT
expression as Implicit (as it's a compiler-generated Node), but the
OBITNOT expression might get constant folded. It's not worth the extra
complexity/subtlety of relying on n.Right.Orig, so we set Implicit on
the OAND node instead.
To atone for this transgression, I add documentation for nodeImplicit.
Fixes#40917.
Change-Id: I386304171ad299c530e151e5924f179e9a5fd5b8
Reviewed-on: https://go-review.googlesource.com/c/go/+/249477
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Add a new lowering rule to match and replace such instances
with the MADDLD instruction available on power9 where
possible.
Likewise, this plumbs in a new ppc64 ssa opcode to house
the newly generated MADDLD instructions.
When testing ed25519, this reduced binary size by 936B.
Similarly, MADDLD combination occcurs in a few other less
obvious cases such as division by constant.
Testing of golang.org/x/crypto/ed25519 shows non-trivial
speedup during keygeneration:
name old time/op new time/op delta
KeyGeneration 65.2µs ± 0% 63.1µs ± 0% -3.19%
Signing 64.3µs ± 0% 64.4µs ± 0% +0.16%
Verification 147µs ± 0% 147µs ± 0% +0.11%
Similarly, this test binary has shrunk by 66488B.
Change-Id: I077aeda7943119b41f07e4e62e44a648f16e4ad0
Reviewed-on: https://go-review.googlesource.com/c/go/+/248723
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Some of the existing optimizations aren't triggered because they
are handled by the generic rules so this CL removes them. Also
some constraints were copied without much thought from the amd64
rules and they don't make sense on s390x, so we remove those
constraints.
Finally, add a 'multiply by the sum of two powers of two'
optimization. This makes sense on s390x as shifts are low latency
and can also sometimes be optimized further (especially if we add
support for RISBG instructions).
name old time/op new time/op delta
IntMulByConst/3-8 1.70ns ±11% 1.10ns ± 5% -35.26% (p=0.000 n=10+10)
IntMulByConst/5-8 1.64ns ± 7% 1.10ns ± 4% -32.94% (p=0.000 n=10+9)
IntMulByConst/12-8 1.65ns ± 6% 1.20ns ± 4% -27.16% (p=0.000 n=10+9)
IntMulByConst/120-8 1.66ns ± 4% 1.22ns ±13% -26.43% (p=0.000 n=10+10)
IntMulByConst/-120-8 1.65ns ± 7% 1.19ns ± 4% -28.06% (p=0.000 n=9+10)
IntMulByConst/65537-8 0.86ns ± 9% 1.12ns ±12% +30.41% (p=0.000 n=10+10)
IntMulByConst/65538-8 1.65ns ± 5% 1.23ns ± 5% -25.11% (p=0.000 n=10+10)
Change-Id: Ib196e6bff1e97febfd266134d0a2b2a62897989f
Reviewed-on: https://go-review.googlesource.com/c/go/+/248937
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
For an unsigned integer, it's useful to convert its order test with 0/1
to its equality test with 0. We can save a comparison instruction that
followed by a conditional branch on arm64 since it supports
compare-with-zero-and-branch instructions. For example,
if x > 0 { ... } else { ... }
the original version:
CMP $0, R0
BLS 9
the optimized version:
CBZ R0, 8
Updates #21439
Change-Id: Id1de6f865f6aa72c5d45b29f7894818857288425
Reviewed-on: https://go-review.googlesource.com/c/go/+/246857
Reviewed-by: Keith Randall <khr@golang.org>
If the AND has other uses, we end up saving an argument to the AND
in another register, so we can use it for the TEST. No point in doing that.
Change-Id: I73444a6aeddd6f55e2328ce04d77c3e6cf4a83e0
Reviewed-on: https://go-review.googlesource.com/c/go/+/241280
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
There are some architecture-independent rules in #21439, since an
unsigned integer >= 0 is always true and < 0 is always false. This CL
adds these optimizations to generic rules.
Updates #21439
Change-Id: Iec7e3040b761ecb1e60908f764815fdd9bc62495
Reviewed-on: https://go-review.googlesource.com/c/go/+/246617
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Makes sure the copyright notice is not interpreted as the package level
godoc.
Change-Id: I2afce7c9d620f19d51ec1438b1d0db1774b57146
Reviewed-on: https://go-review.googlesource.com/c/go/+/248760
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dave Cheney <dave@cheney.net>
The previous array length was large enough to exceed
maxImplicitStackSize on 64-bit architectures, but not on 32-bit
architectures.
Fixes#40808.
Change-Id: I69e9abb447454b2e7875ba503a0cb772e965ae31
Reviewed-on: https://go-review.googlesource.com/c/go/+/248680
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Currently, generated struct wrapper for closure is not handled in
mustHeapAlloc. That causes compiler crashes when the wrapper struct
is too large for stack, and must be heap allocated instead.
Fixes#39292
Change-Id: I14c1e591681d9d92317bb2396d6cf5207aa93e08
Reviewed-on: https://go-review.googlesource.com/c/go/+/244917
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
CL 230121 fixed the bug that struct literal blank fields type array/struct
can not be initialized. But it still misses some cases when an expression
causes "candiscard(value)" return false. When these happen, we recursively
call fixedlit with "var_" set to "_", and hit the bug again.
To fix it, just making splitnode return "nblank" whenever "var_" is "nblank".
Fixes#38905
Change-Id: I281941b388acbd551a4d8ca1a235477f8d26fb6e
Reviewed-on: https://go-review.googlesource.com/c/go/+/232617
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Taking the live variable set from the last return point is problematic.
See #40629 for details, but there may not be a return point, or it may
be before the final defer.
Additionally, keeping track of the last call as a *Value doesn't quite
work. If it is dead-code eliminated, the storage for the Value is reused
for some other random instruction. Its live variable information,
if it is available at all, is wrong.
Instead, just mark all the open-defer argument slots as live
throughout the function. (They are already zero-initialized.)
Fixes#40629
Change-Id: Ie456c7db3082d0de57eaa5234a0f32525a1cce13
Reviewed-on: https://go-review.googlesource.com/c/go/+/247522
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Currently in addLocalInductiveFacts, we only check whether
direct edge from if block to phi block exists. If not, the
following logic will treat the phi block as the first successor,
which is wrong.
This patch makes prove pass more conservative, so we disable
some cases in test/prove.go. We will do some optimization in
the following CL and enable these cases then.
Fixes#40367.
Change-Id: I27cf0248f3a82312a6f7dabe11c79a1a34cf5412
Reviewed-on: https://go-review.googlesource.com/c/go/+/244579
Reviewed-by: Zach Jones <zachj1@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
They were missed as part of the refactoring to use a separate
addressing modes pass.
Fixes#40426
Change-Id: Ie0418b2fac4ba1ffe720644ac918f6d728d5e420
Reviewed-on: https://go-review.googlesource.com/c/go/+/244859
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The ICE reported as #33308 was fixed by a related CL; this change adds
a regression test with the crasher.
Fixes#33308
Change-Id: I3260075dbe3823b56b8825e6269e57a0fad185a6
Reviewed-on: https://go-review.googlesource.com/c/go/+/243458
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
It doesn't have to. The type in the aux field is authoritative.
There are cases involving casting from interface{} where pointers
have a placeholder pointer type (because the type is not known when
the IData op is generated).
The check was introduced in CL 13447.
Fixes#39459
Change-Id: Id77a57577806a271aeebd20bea5d92d08ee7aa6b
Reviewed-on: https://go-review.googlesource.com/c/go/+/239817
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
reflect.assignTo writes to the target using write barriers. Make sure
that the memory it is writing to is zeroed, so the write barrier does
not read pointers from uninitialized memory.
Fixes#39541
Change-Id: Ia64b2cacc193bffd0c1396bbce1dfb8182d4905b
Reviewed-on: https://go-review.googlesource.com/c/go/+/238760
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
These conversion instructions set the condition code and so should
be marked as clobbering flags.
Fixes#39651.
Change-Id: I91cc9687ea70ef0551bb3139c1875071c349d43e
Reviewed-on: https://go-review.googlesource.com/c/go/+/238628
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Make sure that if a field comparison might panic, we evaluate
(and short circuit if not equal) all previous fields, and don't
evaluate any subsequent fields.
Add a bunch more tests to the equality+panic checker.
Update #8606
Change-Id: I6a159bbc8da5b2b7ee835c0cd1fc565575b58c46
Reviewed-on: https://go-review.googlesource.com/c/go/+/237919
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The scheduler assumes two special invariants that apply to tuple
selectors (Select0 and Select1 ops):
1. There is only one tuple selector of each type per generator.
2. Tuple selectors and generators reside in the same block.
Prior to this CL the assumption was that these invariants would
only be broken by the CSE pass. The CSE pass therefore contained
code to move and de-duplicate selectors to fix these invariants.
However it is also possible to write relatively basic optimization
rules that cause these invariants to be broken. For example:
(A (Select0 (B))) -> (Select1 (B))
This rule could result in the newly added selector (Select1) being
in a different block to the tuple generator (see issue #38356). It
could also result in duplicate selectors if this rule matches
multiple times for the same tuple generator (see issue #39472).
The CSE pass will 'fix' these invariants. However it will only do
so when optimizations are enabled (since disabling optimizations
disables the CSE pass).
This CL moves the CSE tuple selector fixup code into its own pass
and makes it mandatory even when optimizations are disabled. This
allows tuple selectors to be treated like normal ops for most of
the compilation pipeline until after the new pass has run, at which
point we need to be careful to maintain the invariant again.
Fixes#39472.
Change-Id: Ia3f79e09d9c65ac95f897ce37e967ee1258a080b
Reviewed-on: https://go-review.googlesource.com/c/go/+/237118
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This is a followup to CL 96495.
It should be simpler and more robust to achieve .bat files having
CRLF line endings by treating it as a binary file, like all other
files, and checking it in with the desired CRLF line endings.
A test is used to check the entire Go tree, short of directories
starting with "." and named "testdata", for any .bat files that
have anything other than strict CRLF line endings. This will help
catch any accidental modifications to existing .bat files or check
ins of new .bat files.
Importantly, this is compatible with how Gerrit serves .tar.gz files,
making it so that CRLF line endings are preserved.
The Go project is supported on many different environments, some of
which may have limited git implementations available, or none at all.
Relying on fewer git features and special rules makes it easier to
have confidence in the exact content of all files. Additionally, Go
development started in Subversion, moved to Perforce, then Mercurial,
and now uses Git.¹ Reducing its reliance on git-specific features will
help if there will be another transition in the project's future.
There are only 5 .bat files in the entire Go source tree, so a new one
being added is a rare event, and we prefer to do things in Go instead.
We still have the option of improving the experience for developers by
adding a pre-commit converter for .bat files to the git-codereview tool.
¹ https://groups.google.com/d/msg/golang-dev/sckirqOWepg/YmyT7dWJiocJFixes#39391.
For #37791.
Change-Id: I6e202216322872f0307ac96f1b8d3f57cb901e6b
Reviewed-on: https://go-review.googlesource.com/c/go/+/236437
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Add interfaces which differ in type. Those used so far only
differ in value, not type.
These additional tests are needed to generate a failure
before CL 236278 went in.
Update #8606
Change-Id: Icdb7647b1973c2fff7e5afe2bd8b8c1b384f583e
Reviewed-on: https://go-review.googlesource.com/c/go/+/236418
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Make sure that we compare fields of structs and elements of arrays in order,
with proper short-circuiting.
Update #8606
Change-Id: I0a66ad92ea0af7bcc56dfdb275dec2b8d7e8b4fe
Reviewed-on: https://go-review.googlesource.com/c/go/+/236147
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This change fixes a race condition between beforeIdle waking up the
innermost event handler and a timer causing a different goroutine to
wake up at the exact same moment. This messes up the wasm event handling
and leads to memory corruption. The solution is to make beforeIdle
return the goroutine that must run next and have findrunnable pick
this goroutine without considering timers again.
Fixes#38093Fixes#38574
Change-Id: Iffbe99411d25c2730953d1c8b0741fd892f8e540
Reviewed-on: https://go-review.googlesource.com/c/go/+/230178
Run-TryBot: Richard Musiol <neelance@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
CL 233857 fixed the underlying issue for #37246,
which had arisen again as #38916.
Add the test case from #37246 to ensure it stays fixed.
Fixes#37246
Change-Id: If7fd75a096d2ce4364dc15509253c3882838161d
Reviewed-on: https://go-review.googlesource.com/c/go/+/233941
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Munday <mike.munday@ibm.com>
When tuple generators and selectors are eliminated as part of the
CSE pass we may end up with tuple selectors that are in different
blocks to the tuple generators that they correspond to. This breaks
the invariant that tuple generators and their corresponding
selectors must be in the same block. Therefore after CSE this
situation must be corrected.
Unfortunately the fixup code did not take into account that selectors
could be eliminated by CSE. It assumed that only the tuple generators
could be eliminated. In some situations this meant that it got into
a state where it was replacing references to selectors with references
to dead selectors in the wrong block.
To fix this we move the fixup code after the CSE rewrites have been
applied. This removes any difficult-to-reason-about interactions
with the CSE rewriter.
Fixes#38916.
Change-Id: I2211982dcdba399d03299f0a819945b3eb93b291
Reviewed-on: https://go-review.googlesource.com/c/go/+/233857
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Taking over Zach's CL 212277. Just cleaned up and added a test.
For a positive, signed integer, an arithmetic right shift of count
(bit-width - 1) equals zero. e.g. int64(22) >> 63 -> 0. This CL makes
prove replace these right shifts with a zero-valued constant.
These shifts may arise in source code explicitly, but can also be
created by the generic rewrite of signed division by a power of 2.
// Signed divide by power of 2.
// n / c = n >> log(c) if n >= 0
// = (n+c-1) >> log(c) if n < 0
// We conditionally add c-1 by adding n>>63>>(64-log(c))
(first shift signed, second shift unsigned).
(Div64 <t> n (Const64 [c])) && isPowerOfTwo(c) ->
(Rsh64x64
(Add64 <t> n (Rsh64Ux64 <t>
(Rsh64x64 <t> n (Const64 <typ.UInt64> [63]))
(Const64 <typ.UInt64> [64-log2(c)])))
(Const64 <typ.UInt64> [log2(c)]))
If n is known to be positive, this rewrite includes an extra Add and 2
extra Rsh. This CL will allow prove to replace one of the extra Rsh with
a 0. That replacement then allows lateopt to remove all the unneccesary
fixups from the generic rewrite.
There is a rewrite rule to handle this case directly:
(Div64 n (Const64 [c])) && isNonNegative(n) && isPowerOfTwo(c) ->
(Rsh64Ux64 n (Const64 <typ.UInt64> [log2(c)]))
But this implementation of isNonNegative really only handles constants
and a few special operations like len/cap. The division could be
handled if the factsTable version of isNonNegative were available.
Unfortunately, the first opt pass happens before prove even has a
chance to deduce the numerator is non-negative, so the generic rewrite
has already fired and created the extra Ops discussed above.
Fixes#36159
By Printf count, this zeroes 137 right shifts when building std and cmd.
Change-Id: Iab486910ac9d7cfb86ace2835456002732b384a2
Reviewed-on: https://go-review.googlesource.com/c/go/+/232857
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Improve the error user experience when users try to set/refer
to unexported fields and methods of struct literals, by directly saying
"cannot refer to unexported field or method"
Fixes#31053
Change-Id: I6fd3caf64b7ca9f9d8ea60b7756875e340792d59
Reviewed-on: https://go-review.googlesource.com/c/go/+/201657
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Omits printing the file:line:column when trying to
open non-existent files
Given:
go tool compile x.go
* Before:
x.go:0: open x.go: no such file or directory
* After:
open x.go: no such file or directory
Reverts the revert in CL 231043 by only fixing the case
of non-existent errors which is what the original bug
was about. The fix for "permission errors" will come later
on when I have bandwidth to investigate the differences
between running with root and why os.Open works for some
builders and not others.
Fixes#36437
Change-Id: I9c8a0981ad708b504bb43990a4105b42266fa41f
Reviewed-on: https://go-review.googlesource.com/c/go/+/230941
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
match:
m = make([]T, x); copy(m, s)
for pointer free T and x==len(s) rewrite to:
m = mallocgc(x*elemsize(T), nil, false); memmove(&m, &s, x*elemsize(T))
otherwise rewrite to:
m = makeslicecopy([]T, x, s)
This avoids memclear and shading of pointers in the newly created slice
before the copy.
With this CL "s" is only be allowed to bev a variable and not a more
complex expression. This restriction could be lifted in future versions
of this optimization when it can be proven that "s" is not referencing "m".
Triggers 450 times during make.bash..
Reduces go binary size by ~8 kbyte.
name old time/op new time/op delta
MakeSliceCopy/mallocmove/Byte 71.1ns ± 1% 65.8ns ± 0% -7.49% (p=0.000 n=10+9)
MakeSliceCopy/mallocmove/Int 71.2ns ± 1% 66.0ns ± 0% -7.27% (p=0.000 n=10+8)
MakeSliceCopy/mallocmove/Ptr 104ns ± 4% 99ns ± 1% -5.13% (p=0.000 n=10+10)
MakeSliceCopy/makecopy/Byte 70.3ns ± 0% 68.0ns ± 0% -3.22% (p=0.000 n=10+9)
MakeSliceCopy/makecopy/Int 70.3ns ± 0% 68.5ns ± 1% -2.59% (p=0.000 n=9+10)
MakeSliceCopy/makecopy/Ptr 102ns ± 0% 99ns ± 1% -2.97% (p=0.000 n=9+9)
MakeSliceCopy/nilappend/Byte 75.4ns ± 0% 74.9ns ± 2% -0.63% (p=0.015 n=9+9)
MakeSliceCopy/nilappend/Int 75.6ns ± 0% 76.4ns ± 3% ~ (p=0.245 n=9+10)
MakeSliceCopy/nilappend/Ptr 107ns ± 0% 108ns ± 1% +0.93% (p=0.005 n=9+10)
Fixes#26252
Change-Id: Iec553dd1fef6ded16197216a472351c8799a8e71
Reviewed-on: https://go-review.googlesource.com/c/go/+/146719
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The {AND,OR,XOR}const ops can only take an int32 as an argument.
Make sure that when rewriting a BTx op to one of these, the result
has no high-order bits.
Fixes#38746
Change-Id: Ia7c5f76952329f60974bc033c29a5433610f3b28
Reviewed-on: https://go-review.googlesource.com/c/go/+/231977
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
This reverts commit 4f7053c87f.
Reason for revert: Newly added test is failing on several builders.
Change-Id: I22dcbfebf2f57735b2f479886bbeb623f95b132f
Reviewed-on: https://go-review.googlesource.com/c/go/+/231043
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Omits printing the file:line:column when trying to open either
* non-existent files
* files without permission
Given:
go tool compile x.go
For either of x.go not existing, or if no read permissions:
* Before:
x.go:0: open x.go: no such file or directory
x.go:0: open x.go: permission denied
* After:
open x.go: no such file or directory
open x.go: permission denied
While here, noticed an oddity with the Linux builders, that appear
to always be running under root, hence the test for permission errors
with 0222 -W-*-W-*-W- can't pass on linux-amd64 builders.
The filed bug is #38608.
Fixes#36437
Change-Id: I9645ef73177c286c99547e3a0f3719fa07b35cb5
Reviewed-on: https://go-review.googlesource.com/c/go/+/229357
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
We set up static symbols during walk that
we later make copies of to initialize local variables.
It is difficult to ascertain at that time exactly
when copying a symbol is profitable vs locally
initializing an autotmp.
During SSA, we are much better placed to optimize.
This change recognizes when we are copying from a
global readonly all-zero symbol and replaces it with
direct zeroing.
This often allows the all-zero symbol to be
deadcode eliminated at link time.
This is not ideal--it makes for large object files,
and longer link times--but it is the cleanest fix I could find.
This makes the final binary for the program in #38554
shrink from >500mb to ~2.2mb.
It also shrinks the standard binaries:
file before after Δ %
addr2line 4412496 4404304 -8192 -0.186%
buildid 2893816 2889720 -4096 -0.142%
cgo 4841048 4832856 -8192 -0.169%
compile 19926480 19922432 -4048 -0.020%
cover 5281816 5277720 -4096 -0.078%
link 6734648 6730552 -4096 -0.061%
nm 4366240 4358048 -8192 -0.188%
objdump 4755968 4747776 -8192 -0.172%
pprof 14653060 14612100 -40960 -0.280%
trace 11805940 11777268 -28672 -0.243%
vet 7185560 7181416 -4144 -0.058%
total 113588440 113465560 -122880 -0.108%
And not just by removing unnecessary symbols;
the program text shrinks a bit as well.
Fixes#38554
Change-Id: I8381ae6084ae145a5e0cd9410c451e52c0dc51c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/229704
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
This CL uses fixVariadicCall before escape analyzing function calls.
This has a number of benefits, though also some minor obstacles:
Most notably, it allows us to remove ODDDARG along with the logic
involved in setting it up, manipulating EscHoles, and later copying
its escape analysis flags to the actual slice argument. Instead, we
uniformly handle all variadic calls the same way. (E.g., issue31573.go
is updated because now f() and f(nil...) are handled identically.)
It also allows us to simplify handling of builtins and generic
function calls. Previously handling of calls was hairy enough to
require multiple dispatches on n.Op, whereas now the logic is uniform
enough that we can easily handle it with a single dispatch.
The downside is handling //go:uintptrescapes is now somewhat clumsy.
(It used to be clumsy, but it still is, too.) The proper fix here is
probably to stop using escape analysis tags for //go:uintptrescapes
and unsafe-uintptr, and have an earlier pass responsible for them.
Finally, note that while we now call fixVariadicCall in Escape, we
still have to call it in Order, because we don't (yet) run Escape on
all compiler-generated functions. In particular, the generated "init"
function for initializing package-level variables can contain calls to
variadic functions and isn't escape analyzed.
Passes toolstash-check -race.
Change-Id: I4cdb92a393ac487910aeee58a5cb8c1500eef881
Reviewed-on: https://go-review.googlesource.com/c/go/+/229759
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Triggers a handful of times in std+cmd.
Change-Id: I9bb8ce9a5f8bae2547cb61157cd8f256e1b63e76
Reviewed-on: https://go-review.googlesource.com/c/go/+/229602
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This CL optimizes code that uses a carry from a function such as
bits.Add64 as the condition in an if statement. For example:
x, c := bits.Add64(a, b, 0)
if c != 0 {
panic("overflow")
}
Rather than converting the carry into a 0 or a 1 value and using
that as an input to a comparison instruction the carry flag is now
used as the input to a conditional branch directly. This typically
removes an ADD LOGICAL WITH CARRY instruction when user code is
doing overflow detection and is closer to the code that a user
would expect to generate.
Change-Id: I950431270955ab72f1b5c6db873b6abe769be0da
Reviewed-on: https://go-review.googlesource.com/c/go/+/219757
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Previously for a method value "x.M", we always flowed x directly to
the heap, which led to the receiver argument generally needing to be
heap allocated.
This CL changes it to flow x to the closure and M's receiver
parameter. This allows receiver arguments to be stack allocated as
long as (1) the closure never escapes, *and* (2) method doesn't leak
its receiver parameter.
Within the standard library, this allows a handful of objects to be
stack allocated instead. Listed here are diagnostics that were
previously emitted by "go build -gcflags=-m std cmd" that are no
longer emitted:
archive/tar/writer.go:118:6: moved to heap: f
archive/tar/writer.go:208:6: moved to heap: f
archive/tar/writer.go:248:6: moved to heap: f
cmd/compile/internal/gc/initorder.go:252:2: moved to heap: d
cmd/compile/internal/gc/initorder.go:75:2: moved to heap: s
cmd/go/internal/generate/generate.go:206:7: &Generator literal escapes to heap
cmd/internal/obj/arm64/asm7.go:910:2: moved to heap: c
cmd/internal/obj/mips/asm0.go:415:2: moved to heap: c
cmd/internal/obj/pcln.go:294:22: new(pcinlineState) escapes to heap
cmd/internal/obj/s390x/asmz.go:459:2: moved to heap: c
crypto/tls/handshake_server.go:56:2: moved to heap: hs
Thanks to Cuong Manh Le for help coming up with this solution.
Fixes#27557.
Change-Id: I8c85d671d07fb9b53e11d2dd05949a34dbbd7e17
Reviewed-on: https://go-review.googlesource.com/c/go/+/228263
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
When generating code for unsigned equals (==) and not equals (!=)
comparisons we currently, on s390x, always use signed comparisons.
This mostly works well, however signed comparisons on s390x sign
extend their immediates and unsigned comparisons zero extend them.
For compare-and-branch instructions which can only have 8-bit
immediates this significantly changes the range of immediate values
we can represent: [-128, 127] for signed comparisons and [0, 255]
for unsigned comparisons.
When generating equals and not equals checks we don't neet to worry
about whether the comparison is signed or unsigned. This CL
therefore adds rules to allow us to switch signedness for such
comparisons if it means that it brings a constant into range for an
8-bit immediate.
For example, a signed equals with an integer in the range [128, 255]
will now be implemented using an unsigned compare-and-branch
instruction rather than separate compare and branch instructions.
As part of this change I've also added support for adding a name
to block control values using the same `x:(...)` syntax we use for
value rules.
Triggers 792 times when compiling cmd and std.
Change-Id: I77fa80a128f0a8ce51a2888d1e384bd5e9b61a77
Reviewed-on: https://go-review.googlesource.com/c/go/+/228642
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Thie CL changes cmd/compile/internal/syntax to give the gc half of
the compiler more control over pragma handling, so that it can prepare
better errors, diagnose misuse, and so on. Before, the API between
the two was hard-coded as a uint16. Now it is an interface{}.
This should set us up better for future directives.
In addition to the split, this CL emits a "misplaced compiler directive"
error for any directive that is in a place where it has no effect.
I've certainly been confused in the past by adding comments
that were doing nothing and not realizing it. This should help
avoid that kind of confusion.
The rule, now applied consistently, is that a //go: directive
must appear on a line by itself immediately before the declaration
specifier it means to apply to. See cmd/compile/doc.go for
precise text and test/directive.go for examples.
This may cause some code to stop compiling, but that code
was broken. For example, this code formerly applied the
//go:noinline to f (not c) but now will fail to compile:
//go:noinline
const c = 1
func f() {}
Change-Id: Ieba9b8d90a27cfab25de79d2790a895cefe5296f
Reviewed-on: https://go-review.googlesource.com/c/go/+/228578
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This optimization works on any integer with exactly one bit set.
This is identical to being a power of two, except in the
most negative number. Use oneBit instead.
The rule now triggers in a few more places in std+cmd,
in packages encoding/asn1, crypto/elliptic, and
vendor/golang.org/x/crypto/cryptobyte.
This change obviates the need for CL 222479
by doing this optimization consistently in the compiler.
Change-Id: I983c6235290fdc634fda5e11b10f1f8ce041272f
Reviewed-on: https://go-review.googlesource.com/c/go/+/229124
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
reflect.Type.Method (and MethodByName) can be used to obtain a
reference of a method by reflection. The linker needs to know
if reflect.Type.Method is called, and retain all exported methods
accordingly. This is handled by the compiler, which marks the
caller of reflect.Type.Method with REFLECTMETHOD attribute. The
current code failed to handle the reflect package itself, so the
method wrapper reflect.Type.Method is not marked. This CL fixes
it.
Fixes#38515.
Change-Id: I12904d23eda664cf1794bc3676152f3218fb762b
Reviewed-on: https://go-review.googlesource.com/c/go/+/228880
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This test started failing at CL 228106 and was fixed by CL 228677.
Fixes#38496
Change-Id: I2dadcd99227347e8d28179039f5f345e728c4595
Reviewed-on: https://go-review.googlesource.com/c/go/+/228698
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Benchmarking suggests that the combo instruction is notably slower,
at least in the places where we measure.
Updates #37955
Change-Id: I829f1975dd6edf38163128ba51d84604055512f4
Reviewed-on: https://go-review.googlesource.com/c/go/+/228157
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
When inserting Select0 and Select1 ops we need to ensure that they
live in the same block as their argument. This is because they need
to be scheduled immediately after their argument for register and
flag allocation to work correctly.
Fixes#38356.
Change-Id: Iba384dbe87010f1c7c4ce909f08011e5f1de7fd5
Reviewed-on: https://go-review.googlesource.com/c/go/+/227879
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Consider
switch x:= x.(type) {
case int:
// int stmts
case error:
// error stmts
}
Prior to this change, we lowered this roughly as:
if x, ok := x.(int); ok {
// int stmts
} else if x, ok := x.(error); ok {
// error stmts
}
x, ok := x.(error) is implemented with a call to runtime.assertE2I2 or runtime.assertI2I2.
x, ok := x.(int) generates inline code that checks whether x has type int,
and populates x and ok as appropriate. We then immediately branch again on ok.
The shortcircuit pass in the SSA backend is designed to recognize situations
like this, in which we are immediately branching on a bool value
that we just calculated with a branch.
However, the shortcircuit pass has limitations when the intermediate state has phis.
In this case, the phi value is x (the int).
CL 222923 improved the situation, but many cases are still unhandled.
I have further improvements in progress, which is how I found this particular problem,
but they are expensive, and may or may not see the light of day.
In the common case of a lone concrete type in a type switch case,
it is easier and cheaper to simply lower a different way, roughly:
if _, ok := x.(int); ok {
x := x.(int)
// int stmts
}
Instead of using a type assertion, though, we extract the value of x
from the interface directly.
This removes the need to track x (the int) across the branch on ok,
which removes the phi, which lets the shortcircuit pass do its job.
Benchmarks for encoding/binary show improvements, as well as some
wild swings on the super fast benchmarks (alignment effects?):
name old time/op new time/op delta
ReadSlice1000Int32s-8 5.25µs ± 2% 4.87µs ± 3% -7.11% (p=0.000 n=44+49)
ReadStruct-8 451ns ± 2% 417ns ± 2% -7.39% (p=0.000 n=45+46)
WriteStruct-8 412ns ± 2% 405ns ± 3% -1.58% (p=0.000 n=46+48)
ReadInts-8 296ns ± 8% 275ns ± 3% -7.23% (p=0.000 n=48+50)
WriteInts-8 324ns ± 1% 318ns ± 2% -1.67% (p=0.000 n=44+49)
WriteSlice1000Int32s-8 5.21µs ± 2% 4.92µs ± 1% -5.67% (p=0.000 n=46+44)
PutUint16-8 0.58ns ± 2% 0.59ns ± 2% +0.63% (p=0.000 n=49+49)
PutUint32-8 0.87ns ± 1% 0.58ns ± 1% -33.10% (p=0.000 n=46+44)
PutUint64-8 0.66ns ± 2% 0.87ns ± 2% +33.07% (p=0.000 n=47+48)
LittleEndianPutUint16-8 0.86ns ± 2% 0.87ns ± 2% +0.55% (p=0.003 n=47+50)
LittleEndianPutUint32-8 0.87ns ± 1% 0.87ns ± 1% ~ (p=0.547 n=45+47)
LittleEndianPutUint64-8 0.87ns ± 2% 0.87ns ± 1% ~ (p=0.451 n=46+47)
ReadFloats-8 79.8ns ± 5% 75.9ns ± 2% -4.83% (p=0.000 n=50+47)
WriteFloats-8 89.3ns ± 1% 88.9ns ± 1% -0.48% (p=0.000 n=46+44)
ReadSlice1000Float32s-8 5.51µs ± 1% 4.87µs ± 2% -11.74% (p=0.000 n=47+46)
WriteSlice1000Float32s-8 5.51µs ± 1% 4.93µs ± 1% -10.60% (p=0.000 n=48+47)
PutUvarint32-8 25.9ns ± 2% 24.0ns ± 2% -7.02% (p=0.000 n=48+50)
PutUvarint64-8 75.1ns ± 1% 61.5ns ± 2% -18.12% (p=0.000 n=45+47)
[Geo mean] 57.3ns 54.3ns -5.33%
Despite the rarity of type switches, this generates noticeably smaller binaries.
file before after Δ %
addr2line 4413296 4409200 -4096 -0.093%
api 5982648 5962168 -20480 -0.342%
cgo 4854168 4833688 -20480 -0.422%
compile 19694784 19682560 -12224 -0.062%
cover 5278008 5265720 -12288 -0.233%
doc 4694824 4682536 -12288 -0.262%
fix 3411336 3394952 -16384 -0.480%
link 6721496 6717400 -4096 -0.061%
nm 4371152 4358864 -12288 -0.281%
objdump 4760960 4752768 -8192 -0.172%
pprof 14810820 14790340 -20480 -0.138%
trace 11681076 11668788 -12288 -0.105%
vet 8285464 8244504 -40960 -0.494%
total 115824120 115627576 -196544 -0.170%
Compiler performance is marginally improved (note that go/types has many type switches):
name old alloc/op new alloc/op delta
Template 35.0MB ± 0% 35.0MB ± 0% +0.09% (p=0.008 n=5+5)
Unicode 28.5MB ± 0% 28.5MB ± 0% ~ (p=0.548 n=5+5)
GoTypes 114MB ± 0% 114MB ± 0% -0.76% (p=0.008 n=5+5)
Compiler 541MB ± 0% 541MB ± 0% -0.03% (p=0.008 n=5+5)
SSA 1.17GB ± 0% 1.17GB ± 0% ~ (p=0.841 n=5+5)
Flate 21.9MB ± 0% 21.9MB ± 0% ~ (p=0.421 n=5+5)
GoParser 26.9MB ± 0% 26.9MB ± 0% ~ (p=0.222 n=5+5)
Reflect 74.6MB ± 0% 74.6MB ± 0% ~ (p=1.000 n=5+5)
Tar 32.9MB ± 0% 32.8MB ± 0% ~ (p=0.056 n=5+5)
XML 42.4MB ± 0% 42.1MB ± 0% -0.77% (p=0.008 n=5+5)
[Geo mean] 73.2MB 73.1MB -0.15%
name old allocs/op new allocs/op delta
Template 377k ± 0% 377k ± 0% +0.06% (p=0.008 n=5+5)
Unicode 354k ± 0% 354k ± 0% ~ (p=0.095 n=5+5)
GoTypes 1.31M ± 0% 1.30M ± 0% -0.73% (p=0.008 n=5+5)
Compiler 5.44M ± 0% 5.44M ± 0% -0.04% (p=0.008 n=5+5)
SSA 11.7M ± 0% 11.7M ± 0% ~ (p=1.000 n=5+5)
Flate 239k ± 0% 239k ± 0% ~ (p=1.000 n=5+5)
GoParser 302k ± 0% 302k ± 0% -0.04% (p=0.008 n=5+5)
Reflect 977k ± 0% 977k ± 0% ~ (p=0.690 n=5+5)
Tar 346k ± 0% 346k ± 0% ~ (p=0.889 n=5+5)
XML 431k ± 0% 430k ± 0% -0.25% (p=0.008 n=5+5)
[Geo mean] 806k 806k -0.10%
For packages with many type switches, this considerably shrinks function text size.
Some examples:
file before after Δ %
encoding/binary.s 30726 29504 -1222 -3.977%
go/printer.s 77597 76005 -1592 -2.052%
cmd/vendor/golang.org/x/tools/go/ast/astutil.s 65704 63318 -2386 -3.631%
cmd/vendor/golang.org/x/tools/go/analysis/passes/unreachable.s 8047 7714 -333 -4.138%
Text size regressions are rare.
Change-Id: Ic10982bbb04876250eaa5bfee97990141ae5fc28
Reviewed-on: https://go-review.googlesource.com/c/go/+/228106
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
If -d=ssa/PASS/debug=N is specified (N >= 2) for a rewrite pass
(e.g. lower), when a Value (or Block) is rewritten, print the
Value (or Block) before and after.
For #31915.
Updates #19013.
Change-Id: I80eadd44302ae736bc7daed0ef68529ab7a16776
Reviewed-on: https://go-review.googlesource.com/c/go/+/176718
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Missed as part of CL 221790. It isn't just * and / that can make NaNs.
Update #36400Fixes#38359
Change-Id: I3fa562f772fe03b510793a6dc0cf6189c0c3e652
Reviewed-on: https://go-review.googlesource.com/c/go/+/227860
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alberto Donizetti <alb.donizetti@gmail.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
This changes the code generated for variable length shift
counts to use isel instead of instructions that set and
read the carry flag.
This reduces the generated code for shifts like this
by 1 instruction and avoids the use of instructions to
set and read the carry flag.
This sequence can be found in strconv with these results
on power9:
Atof64Decimal 71.6ns ± 0% 68.3ns ± 0% -4.61%
Atof64Float 95.3ns ± 0% 90.9ns ± 0% -4.62%
Atof64FloatExp 153ns ± 0% 149ns ± 0% -2.61%
Atof64Big 234ns ± 0% 232ns ± 0% -0.85%
Atof64RandomBits 348ns ± 0% 369ns ± 0% +6.03%
Atof64RandomFloats 262ns ± 0% 262ns ± 0% ~
Atof32Decimal 72.0ns ± 0% 68.2ns ± 0% -5.28%
Atof32Float 92.1ns ± 0% 87.1ns ± 0% -5.43%
Atof32FloatExp 159ns ± 0% 158ns ± 0% -0.63%
Atof32Random 194ns ± 0% 191ns ± 0% -1.55%
Some tests in codegen/shift.go are enabled to verify the
expected instructions are generated.
Change-Id: I968715d10ada405a8c46132bf19b8ed9b85796d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/227337
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This removes all files that are only used on darwin/arm and cleans up
build tags in files that are still used on other platforms.
Updates #37611.
Change-Id: Ic9490cf0edfc157c6276a7ca950c1768b34a998f
Reviewed-on: https://go-review.googlesource.com/c/go/+/227197
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
I took some of the infrastructure from Austin's lock logging CR
https://go-review.googlesource.com/c/go/+/192704 (with deadlock
detection from the logs), and developed a setup to give static lock
ranking for runtime locks.
Static lock ranking establishes a documented total ordering among locks,
and then reports an error if the total order is violated. This can
happen if a deadlock happens (by acquiring a sequence of locks in
different orders), or if just one side of a possible deadlock happens.
Lock ordering deadlocks cannot happen as long as the lock ordering is
followed.
Along the way, I found a deadlock involving the new timer code, which Ian fixed
via https://go-review.googlesource.com/c/go/+/207348, as well as two other
potential deadlocks.
See the constants at the top of runtime/lockrank.go to show the static
lock ranking that I ended up with, along with some comments. This is
great documentation of the current intended lock ordering when acquiring
multiple locks in the runtime.
I also added an array lockPartialOrder[] which shows and enforces the
current partial ordering among locks (which is embedded within the total
ordering). This is more specific about the dependencies among locks.
I don't try to check the ranking within a lock class with multiple locks
that can be acquired at the same time (i.e. check the ranking when
multiple hchan locks are acquired).
Currently, I am doing a lockInit() call to set the lock rank of most
locks. Any lock that is not otherwise initialized is assumed to be a
leaf lock (a very high rank lock), so that eliminates the need to do
anything for a bunch of locks (including all architecture-dependent
locks). For two locks, root.lock and notifyList.lock (only in the
runtime/sema.go file), it is not as easy to do lock initialization, so
instead, I am passing the lock rank with the lock calls.
For Windows compilation, I needed to increase the StackGuard size from
896 to 928 because of the new lock-rank checking functions.
Checking of the static lock ranking is enabled by setting
GOEXPERIMENT=staticlockranking before doing a run.
To make sure that the static lock ranking code has no overhead in memory
or CPU when not enabled by GOEXPERIMENT, I changed 'go build/install' so
that it defines a build tag (with the same name) whenever any experiment
has been baked into the toolchain (by checking Expstring()). This allows
me to avoid increasing the size of the 'mutex' type when static lock
ranking is not enabled.
Fixes#38029
Change-Id: I154217ff307c47051f8dae9c2a03b53081acd83a
Reviewed-on: https://go-review.googlesource.com/c/go/+/207619
Reviewed-by: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Extend CL 220417 (which removed the integer Greater and Geq ops) to
floating point comparisons. Greater and Geq can always be
implemented using Less and Leq.
Fixes#37316.
Change-Id: Ieaddb4877dd0ff9037a1dd11d0a9a9e45ced71e7
Reviewed-on: https://go-review.googlesource.com/c/go/+/222397
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Before using some CPU instructions, we must check for their presence.
We use global variables in the runtime package to record features.
Prior to this CL, we issued a regular memory load for these features.
The downside to this is that, because it is a regular memory load,
it cannot be hoisted out of loops or otherwise reordered with other loads.
This CL introduces a new intrinsic just for checking cpu features.
It still ends up resulting in a memory load, but that memory load can
now be floated to the entry block and rematerialized as needed.
One downside is that the regular load could be combined with the comparison
into a CMPBconstload+NE. This new intrinsic cannot; it generates MOVB+TESTB+NE.
(It is possible that MOVBQZX+TESTQ+NE would be better.)
This CL does only amd64. It is easy to extend to other architectures.
For the benchmark in #36196, on my machine, this offers a mild speedup.
name old time/op new time/op delta
FMA-8 1.39ns ± 6% 1.29ns ± 9% -7.19% (p=0.000 n=97+96)
NonFMA-8 2.03ns ±11% 2.04ns ±12% ~ (p=0.618 n=99+98)
Updates #15808
Updates #36196
Change-Id: I75e2fcfcf5a6df1bdb80657a7143bed69fca6deb
Reviewed-on: https://go-review.googlesource.com/c/go/+/212360
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Giovanni Bajo <rasky@develer.com>
We still disallow inlining for an immediately-recursive function, but allow
inlining if a function is in a recursion chain.
If all functions in the recursion chain are simple, then we could inline
forever down the recursion chain (eventually running out of stack on the
compiler), so we add a map to keep track of the functions we have
already inlined at a call site. We stop inlining when we reach a
function that we have already inlined in the recursive chain. Of course,
normally the inlining will have stopped earlier, because of the cost
function.
We could also limit the depth of inlining by a simple count (say, limit
max inlining of 10 at any given site). Would that limit other
opportunities too much?
Added a test in test/inline.go. runtime.BenchmarkStackCopyNoCache() is
also already a good test that triggers the check to stop inlining
when we reach the start of the recursive chain again.
For the bent benchmark suite, the performance improvement was mostly not
statistically significant, but the geomean averaged out to: -0.68%. The text size
increase was less than .1% for all bent benchmarks. The cmd/go text size increase
was 0.02% and the cmd/compile text size increase was .1%.
Fixes#29737
Change-Id: I892fa84bb07a947b3125ec8f25ed0e508bf2bdf5
Reviewed-on: https://go-review.googlesource.com/c/go/+/226818
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
If slice cap is not set, it will be equal to slice len. So
isSmallMakeSlice only needs to check whether slice cap is constant.
While at it, also add test to make sure panicmakeslicecap is called
when make slice contains invalid non-constant len.
For this benchmark:
func BenchmarkMakeSliceNonConstantLen(b *testing.B) {
len := 1
for i := 0; i < b.N; i++ {
s := make([]int, len, 2)
_ = s
}
}
Result compare with parent:
name old time/op new time/op delta
MakeSliceNonConstantLen-12 18.4ns ± 1% 0.2ns ± 2% -98.66% (p=0.008 n=5+5)
Fixes#37975
Change-Id: I4bc926361bc2ffeab4cfaa888ef0a30cbc3b80e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/226278
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
In CL 187657, I refactored constant conversion logic without realizing
that conversions between int/float and complex types are allowed for
constants (assuming the constant values are representable by the
destination type), but are never allowed for non-constant expressions.
This CL expands convertop to take an extra srcConstant parameter to
indicate whether the source expression is a constant; and if so, to
allow any numeric-to-numeric conversion. (Conversions of values that
cannot be represented in the destination type are rejected by
evconst.)
Fixes#38117.
Change-Id: Id7077d749a14c8fd910be38da170fa5254819f2b
Reviewed-on: https://go-review.googlesource.com/c/go/+/226197
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Make sure we don't use the rewrite ptr + (c + x) -> c + (ptr + x), as
that may create an ephemeral out-of-bounds pointer.
I have not seen an actual bug caused by this yet, but we've seen
them in the 386 port so I'm fixing this issue for amd64 as well.
The load-combining rules needed to be reworked somewhat to still
work without the above broken rule.
Update #37881
Change-Id: I8046d170e89e2035195f261535e34ca7d8aca68a
Reviewed-on: https://go-review.googlesource.com/c/go/+/226437
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Retrying CL 222782, with a fix that will hopefully stop the random crashing.
The issue with the previous CL is that it does pointer arithmetic
in a way that may briefly generate an out-of-bounds pointer. If an
interrupt happens to occur in that state, the referenced object may
be collected incorrectly.
Suppose there was code that did s[x+c]. The previous CL had a rule
to the effect of ptr + (x + c) -> c + (ptr + x). But ptr+x is not
guaranteed to point to the same object as ptr. In contrast,
ptr+(x+c) is guaranteed to point to the same object as ptr, because
we would have already checked that x+c is in bounds.
For example, strconv.trim used to have this code:
MOVZX -0x1(BX)(DX*1), BP
CMPL $0x30, AL
After CL 222782, it had this code:
LEAL 0(BX)(DX*1), BP
CMPB $0x30, -0x1(BP)
An interrupt between those last two instructions could see BP pointing
outside the backing store of the slice involved.
It's really hard to actually demonstrate a bug. First, you need to
have an interrupt occur at exactly the right time. Then, there must
be no other pointers to the object in question. Since the interrupted
frame will be scanned conservatively, there can't even be a dead
pointer in another register or on the stack. (In the example above,
a bug can't happen because BX still holds the original pointer.)
Then, the object in question needs to be collected (or at least
scanned?) before the interrupted code continues.
This CL needs to handle load combining somewhat differently than CL 222782
because of the new restriction on arithmetic. That's the only real
difference (other than removing the bad rules) from that old CL.
This bug is also present in the amd64 rewrite rules, and we haven't
seen any crashing as a result. I will fix up that code similarly to
this one in a separate CL.
Update #37881
Change-Id: I5f0d584d9bef4696bfe89a61ef0a27c8d507329f
Reviewed-on: https://go-review.googlesource.com/c/go/+/225798
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The "runindir" tests used "go run", but relied on relative imports
(which are not supported by "go run" in module mode). Instead, such
tests must use fully-qualified imports, which require either a go.mod
file (in module mode) or that the package be in an appropriate
subdirectory of GOPATH/src (in GOPATH mode).
To set up such a directory, we use yet another copy of the same
overlayDir function currently found in the misc subdirectory of this
repository.
Fixes#33912
Updates #30228
Change-Id: If3d7ea2f7942ba496d98aaaf24a90bcdcf4df9f7
Reviewed-on: https://go-review.googlesource.com/c/go/+/225205
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The load and test instructions compare the given value
against zero and will produce a condition code indicating
one of the following scenarios:
0: Result is zero
1: Result is less than zero
2: Result is greater than zero
3: Result is not a number (NaN)
The instruction can be used to simplify floating point comparisons
against zero, which can enable further optimizations.
This CL also reduces the size of .text section of math.test binary by around
0.7 KB (in hexadecimal, from 1358f0 to 135620).
Change-Id: I33cb714f0c6feebac7a1c46dfcc735e7daceff9c
Reviewed-on: https://go-review.googlesource.com/c/go/+/209159
Reviewed-by: Michael Munday <mike.munday@ibm.com>
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
riscv64 now has atomic intrinsics, so re-enable the atomic intrinsic tests.
Fixes#36765
Change-Id: I838f27570a94d7fa5774c43f1ca5f4df2ca104cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/223560
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This reverts commit CL 222782.
Reason for revert: Reverting to see if 386 errors go away
Update #37881
Change-Id: I74f287404c52414db1b6ff1649effa4ed9e5cc0c
Reviewed-on: https://go-review.googlesource.com/c/go/+/225218
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Rolling back portions of CL 222782 to see if that helps
issue #37881 any.
Update #37881
Change-Id: I9cc3ff8c469fa5e4b22daec715d04148033f46f7
Reviewed-on: https://go-review.googlesource.com/c/go/+/224837
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Batch files should use CRLF endings. LF endings mostly
work but in some situations they cause random errors like
goto commands failing for mysterious reasons. See
golang.org/issue/37791 for more information.
Next CL triggered one of such bug (a label was not being
recognized), so prepare for it by converting to CRLF.
This CL also touches all existing batch files to force git
to update the line endings (unfortunately, changing
.gitattributes only has effect next time the file is checked
out or modified).
Fixes#37791
Updates #9281
Change-Id: I6f9a114351cb7ac9881914400aa210c930eb8cc1
Reviewed-on: https://go-review.googlesource.com/c/go/+/96495
Run-TryBot: Giovanni Bajo <rasky@develer.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
This commit extends the -spectre flag to cmd/asm and adds
a new Spectre mitigation mode "ret", which enables the use
of retpolines.
Retpolines prevent speculation about the target of an indirect
jump or call and are described in more detail here:
https://support.google.com/faqs/answer/7625886
Change-Id: I4f2cb982fa94e44d91e49bd98974fd125619c93a
Reviewed-on: https://go-review.googlesource.com/c/go/+/222661
Reviewed-by: Keith Randall <khr@golang.org>
This commit adds a new cmd/compile flag -spectre,
which accepts a comma-separated list of possible
Spectre mitigations to apply, or the empty string (none),
or "all". The only known mitigation right now is "index",
which uses conditional moves to ensure that x86-64 CPUs
do not speculate past index bounds checks.
Speculating past index bounds checks may be problematic
on systems running privileged servers that accept requests
from untrusted users who can execute their own programs
on the same machine. (And some more constraints that
make it even more unlikely in practice.)
The cases this protects against are analogous to the ones
Microsoft explains in the "Array out of bounds load/store feeding ..."
sections here:
https://docs.microsoft.com/en-us/cpp/security/developer-guidance-speculative-execution?view=vs-2019#array-out-of-bounds-load-feeding-an-indirect-branch
Change-Id: Ib7532d7e12466b17e04c4e2075c2a456dc98f610
Reviewed-on: https://go-review.googlesource.com/c/go/+/222660
Reviewed-by: Keith Randall <khr@golang.org>
//line bogo.go:9999999 will cause 'go tool objdump' to crash
unless bogo.go has that many lines. Guard the array index
and return innocuous values (nil, nil) from the file cache.
Fixes#36683
Change-Id: I4a9f8444dc611654d270cc876e8848dfd2f84770
Reviewed-on: https://go-review.googlesource.com/c/go/+/223081
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
With a clean cache on a laptop
before change
time go run run.go -- . fixedbugs
real 2m10.195s
user 3m16.547s
sys 1m52.939s
Or, before, directly after make.bash (the actual use case we care about)
time go run run.go -- . fixedbugs
real 2m8.704s
user 3m12.327s
sys 1m49.123s
after change
time go run run.go -- . fixedbugs
real 1m38.915s
user 2m38.389s
sys 1m8.490s
Tests, fortunately, still seem to pass.
Latest version of this takes the slow route for cross-compilation, which includes wasm.
Change-Id: Iad19951612defa96c4e9830bce920c5e8733834a
Reviewed-on: https://go-review.googlesource.com/c/go/+/223083
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The default is for later flags to override earlier ones,
so if the asmcheck set flags, it lost the important -S=2.
Change-Id: Id538254908d658da2acb55157ac4f6fa44f6a467
Reviewed-on: https://go-review.googlesource.com/c/go/+/222820
Reviewed-by: Keith Randall <khr@golang.org>
If typehash (used by reflect) does not match the built-in map's hash,
then problems occur. If a map is built using reflect, and then
assigned to a variable of map type, the hash function can change. That
causes very bad things.
This issue is rare. MapOf consults a cache of all types that occur in
the binary before making a new one. To make a true new map type (with
a hash function derived from typehash) that map type must not occur in
the binary anywhere. But to cause the bug, we need a variable of that
type in order to assign to it. The only way to make that work is to
use a named map type for the variable, so it is distinct from the
unnamed version that MapOf looks for.
Fixes#37716
Change-Id: I3537bfceca8cbfa1af84202f432f3c06953fe0ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/222357
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Use a separate compiler pass to introduce complicated x86 addressing
modes. Loads in the normal architecture rules (for x86 and all other
platforms) can have constant offsets (AuxInt values) and symbols (Aux
values), but no more.
The complex addressing modes (x+y, x+2*y, etc.) are introduced in a
separate pass that combines loads with LEAQx ops.
Organizing rewrites this way simplifies the number of rewrites
required, as there are lots of different rule orderings that have to
be specified to ensure these complex addressing modes are always found
if they are possible.
Update #36468
Change-Id: I5b4bf7b03a1e731d6dfeb9ef19b376175f3b4b44
Reviewed-on: https://go-review.googlesource.com/c/go/+/217097
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
CL 212777 added a check to isNonNegative
to return true for unsigned values.
However, the SSA backend isn't type safe
enough for that to be sound.
The other checks in isNonNegative
look only at the pattern of bits.
Remove the type-based check.
Updates #37753
Change-Id: I059d0e86353453133f2a160dce53af299f42e533
Reviewed-on: https://go-review.googlesource.com/c/go/+/222620
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
-gcflags=-flag means apply the flags only to the package named
on the command line (the main package, for these tests).
-gcflags=all=-flag means apply the flags to everything in the build,
including the standard library.
cmd/dist uses -gcflags=all=$GO_GCFLAGS, so test/run should do the same,
as the comment already explains, to avoid rebuilding the entire standard
library without the flags during test/run's builds.
We changed the scope of the flags without a pattern a few releases
ago and missed this one.
Change-Id: I039e60ca619d39e5b502261d4a73e1afc7e3f9fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/213827
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This is one of several changes that were part of a larger rewrite
which I made in early 2019 after switching to the new number literal
syntax implementation. The purpose of the rewrite was to simplify
reading of source code (Unicode character by character) and speed up
the scanner but was never submitted for review due to other priorities.
Part 2 of 3:
This change contains improvements to the scanner error messages:
- Use "rune literal" rather than "character literal" to match the
spec nomenclature.
- Shorter, more to the point error messages.
(For instance, "more than one character in rune literal" rather
than "invalid character literal (more than one character)", etc.)
Change-Id: I1aaf79003374a68dbb05926437ed305cf2a8ec96
Reviewed-on: https://go-review.googlesource.com/c/go/+/221602
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
There are still two places in src/runtime/string.go that use
staticbytes, so we cannot delete it just yet.
There is a new codegen test to verify that the index calculation
is constant-folded, at least on amd64. ppc64, mips[64] and s390x
cannot currently do that.
There is also a new runtime benchmark to ensure that this does not
slow down performance (tested against parent commit):
name old time/op new time/op delta
ConvT2EByteSized/bool-4 1.07ns ± 1% 1.07ns ± 1% ~ (p=0.060 n=14+15)
ConvT2EByteSized/uint8-4 1.06ns ± 1% 1.07ns ± 1% ~ (p=0.095 n=14+15)
Updates #37612
Change-Id: I5ec30738edaa48cda78dfab4a78e24a32fa7fd6a
Reviewed-on: https://go-review.googlesource.com/c/go/+/221957
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Trying this CL again, with a fixed test that allows platforms
to disagree on the exact behavior of converting NaNs.
We store 32-bit floating point constants in a 64-bit field, by
converting that 32-bit float to 64-bit float to store it, and convert
it back to use it.
That works for *almost* all floating-point constants. The exception is
signaling NaNs. The round trip described above means we can't represent
a 32-bit signaling NaN, because conversions strip the signaling bit.
To fix this issue, just forbid NaNs as floating-point constants in SSA
form. This shouldn't affect any real-world code, as people seldom
constant-propagate NaNs (except in test code).
Additionally, NaNs are somewhat underspecified (which of the many NaNs
do you get when dividing 0/0?), so when cross-compiling there's a
danger of using the compiler machine's NaN regime for some math, and
the target machine's NaN regime for other math. Better to use the
target machine's NaN regime always.
Update #36400
Change-Id: Idf203b688a15abceabbd66ba290d4e9f63619ecb
Reviewed-on: https://go-review.googlesource.com/c/go/+/221790
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Print the bytes of the instruction that generated a SIGILL.
This should help us respond to bug reports without having to
go back-and-forth with the reporter to get the instruction involved.
Might also help with SIGILL problems that are difficult to reproduce.
Update #37513
Change-Id: I33059b1dbfc97bce16142a843f32a88a6547e280
Reviewed-on: https://go-review.googlesource.com/c/go/+/221431
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Open-coded defers were fixed and re-enabled on riscv64, however this test was
inadvertantly left disabled.
Updates #36786
Change-Id: I128fc84baa3d51f50d173e19e52051dc4d9a07c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/220920
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The existing implementation outputs inline cost iff function cannot be inlined with Debug['m'] > 1, the cost info is also useful if the function is inlineable.
Fixes#36780
Change-Id: Ic96f6baf96aee25fb4b33d31d4d644dc2310e536
Reviewed-on: https://go-review.googlesource.com/c/go/+/216778
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
The generic Greater and Geq ops can always be replaced with the Less and
Leq ops. This CL therefore removes them. This simplifies the compiler since
it reduces the number of operations that need handling in both code and in
rewrite rules. This will be especially true when adding control flow
optimizations such as the integer-in-range optimizations in CL 165998.
Change-Id: If0648b2b19998ac1bddccbf251283f3be4ec3040
Reviewed-on: https://go-review.googlesource.com/c/go/+/220417
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Ensure that any comparison between two values has the same argument
order. This helps ensure that they can be eliminated during the
lowered CSE pass which will be particularly important if we eliminate
the Greater and Geq ops (see #37316).
Example:
CMP R0, R1
BLT L1
CMP R1, R0 // different order, cannot eliminate
BEQ L2
CMP R0, R1
BLT L1
CMP R0, R1 // same order, can eliminate
BEQ L2
This does have some drawbacks. Notably comparisons might 'flip'
direction in the assembly output after even small changes to the
code or compiler. It should help make optimizations more reliable
however.
compilecmp master -> HEAD
master (218f4572f5): text/template: make reflect.Value indirections more robust
HEAD (f1661fef3e): cmd/compile: canonicalize comparison argument order
platform: linux/amd64
file before after Δ %
api 6063927 6068023 +4096 +0.068%
asm 5191757 5183565 -8192 -0.158%
cgo 4893518 4901710 +8192 +0.167%
cover 5330345 5326249 -4096 -0.077%
fix 3417778 3421874 +4096 +0.120%
pprof 14889456 14885360 -4096 -0.028%
test2json 2848138 2844042 -4096 -0.144%
trace 11746239 11733951 -12288 -0.105%
total 132739173 132722789 -16384 -0.012%
Change-Id: I11736b3fe2a4553f6fc65018f475e88217fa22f9
Reviewed-on: https://go-review.googlesource.com/c/go/+/220425
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This reverts CL 213477.
Reason for revert: tests are failing on linux-mips*-rtrk builders.
Change-Id: I8168f7450890233f1bd7e53930b73693c26d4dc0
Reviewed-on: https://go-review.googlesource.com/c/go/+/220897
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
We store 32-bit floating point constants in a 64-bit field, by
converting that 32-bit float to 64-bit float to store it, and convert
it back to use it.
That works for *almost* all floating-point constants. The exception is
signaling NaNs. The round trip described above means we can't represent
a 32-bit signaling NaN, because conversions strip the signaling bit.
To fix this issue, just forbid NaNs as floating-point constants in SSA
form. This shouldn't affect any real-world code, as people seldom
constant-propagate NaNs (except in test code).
Additionally, NaNs are somewhat underspecified (which of the many NaNs
do you get when dividing 0/0?), so when cross-compiling there's a
danger of using the compiler machine's NaN regime for some math, and
the target machine's NaN regime for other math. Better to use the
target machine's NaN regime always.
This has been a bug since 1.10, and there's an easy workaround
(declare a global varaible containing the signaling NaN pattern, and
use that as the argument to math.Float32frombits) so we'll fix it in
1.15.
Fixes#36400
Update #36399
Change-Id: Icf155e743281560eda2eed953d19a829552ccfda
Reviewed-on: https://go-review.googlesource.com/c/go/+/213477
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
The address calculations in the example end up doing x << 4 + y + 0.
Before this CL we use a SHLQ+LEAQ. Since the constant offset is 0,
we can use SHLQ+ADDQ instead.
Change-Id: Ia048c4fdbb3a42121c7e1ab707961062e8247fca
Reviewed-on: https://go-review.googlesource.com/c/go/+/209959
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The wrapper takes a pointer to the argument, not the argument itself.
Fixes#36705
Change-Id: I566d4457d00bf5b84e4a8315a26516975f0d7e10
Reviewed-on: https://go-review.googlesource.com/c/go/+/215942
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
We should panic in this situation. Rewriting to a SSA op just leads
to a compiler panic.
Fixes#36259
Change-Id: I6e0bccbed7dd0fdac7ebae76b98a211947947386
Reviewed-on: https://go-review.googlesource.com/c/go/+/212405
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
• Inline check function because it's more readable.
• Delete toolPath because it was unused.
• Use strings.TrimPrefix because it's simpler.
• Remove out variable because its value was unused.
• Rename serr to err because it's more consistent.
Change-Id: I084fb4f8b399578834d5eea29a673c386cf3a357
Reviewed-on: https://go-review.googlesource.com/c/go/+/218701
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Hajime Hoshi <hajimehoshi@gmail.com>
The error message is now positioned at the statement position (which is
an identifing token, such as the '=' for assignments); and in case of
assignments it emphasizes the assignment by putting the Lhs and Rhs
in parentheses. Finally, the wording is changed from "use of * as value"
to the stronger "cannot use * as value" (for which there is precedent
elsewhere in the parser).
Fixes#36858.
Change-Id: Ic3f101bba50f58e3a1d9b29645066634631f2d61
Reviewed-on: https://go-review.googlesource.com/c/go/+/218337
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Brad's battery died on a plane and the file stayed open for 8 years
without anyone noticing. 😄
Someone noticed in https://github.com/gopherjs/gopherjs/pull/950.
Updates #2833
Change-Id: I46b28ac014a8c355be94e026615f119f96e5d51a
Reviewed-on: https://go-review.googlesource.com/c/go/+/218700
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
The R_CALLRISCV relocation marker is on the JALR instruction, however the actual
relocation is currently two instructions previous for the AUIPC+ADDI sequence.
Adjust the platform dependent offset accordingly and re-enable open-coded defers.
Fixes#36786.
Change-Id: I71597c193c447930fbe94ce44b7355e89ae877bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/216797
Run-TryBot: Joel Sing <joel@sing.id.au>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This test expects that open-coded defers are enabled, which is not currently
the case on riscv64.
Updates issue #27532 and #36786.
Change-Id: I94bb558c5b0734b4cfe5ae12873be81026009bcf
Reviewed-on: https://go-review.googlesource.com/c/go/+/216777
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Open-coded defers are currently broken on riscv64 - disable them for the
time being. All of the standard package tests now pass on linux/riscv64.
Updates issue #27532 and #36786
Change-Id: I20fc25ce91dfad48be32409ba5c64ca9a6acef1d
Reviewed-on: https://go-review.googlesource.com/c/go/+/216517
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
On PPC64, MOVWload, MOVDload, and MOVDstore are assembled to a
"DS from" instruction which requiers the offset is a multiple of
4. Only fold offset to such instructions if it is a multiple of 4.
Fixes#36723.
"GOARCH=ppc64 GOOS=linux go build -gcflags=all=-d=ssa/check/on std cmd"
passes now.
Change-Id: I67f2a6ac02f0d33d470f68ff54936c289a4c765b
Reviewed-on: https://go-review.googlesource.com/c/go/+/216379
Reviewed-by: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com>
This disables some tests that are unsupported on riscv64 and adds support
for risc64 to test/nosplit.
Updates #27532, #36739 and #36765
Change-Id: I0a57797a05bc80236709fc240c0a0efb0ee0d16b
Reviewed-on: https://go-review.googlesource.com/c/go/+/216263
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
CL 214679 added a -race test which shouldn't be run when cgo is not
enabled.
Fixes the nocgo builder.
Change-Id: Iceddf802c4ef6c0de2c3a968e86342303d2d27d8
Reviewed-on: https://go-review.googlesource.com/c/go/+/215477
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This avoids the security problem in #29312 where two very deep, but
distinct, types are given the same name. They both make it to the
linker which chooses one, and the use of the other is now type unsafe.
Instead, give every very deep type its own name. This errs on the
other side, in that very deep types that should be convertible to each
other might now not be. But at least that's not a security hole.
Update #29312.
Change-Id: Iac0ebe73fdc50594fd6fbf7432eef65f9a053126
Reviewed-on: https://go-review.googlesource.com/c/go/+/213517
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
The gccgo compiler did not generate type descriptor for a pointer
to a type alias defined in another package, causing linking error.
The fix is CL 210787. This CL adds a test.
Updates #36085.
Change-Id: I3237c7fedb4d92fb2dc610ee2b88087f96dc2a1a
Reviewed-on: https://go-review.googlesource.com/c/go/+/210858
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This test was recently added in CL 209961.
Apparently Windows can't seek a directory filehandle?
And move the test from test/fixedbugs (which is mostly for compiler bugs) to
an os package test.
Updates #36019
Change-Id: I626b69b0294471014901d0ccfeefe5e2c7651788
Reviewed-on: https://go-review.googlesource.com/c/go/+/210283
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
The first Readdirnames calls opendir and caches the result.
The behavior of that cached opendir result isn't specified on a seek
of the underlying fd. Free the opendir result on a seek so that
we'll allocate a new one the next time around.
Also fix wasm behavior in this regard, so that a seek to the
file start resets the Readdirnames position, regardless of platform.
p.s. I hate the Readdirnames API.
Fixes#35767.
Change-Id: Ieffb61b3c5cdd42591f69ab13f932003966f2297
Reviewed-on: https://go-review.googlesource.com/c/go/+/209961
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The fix for #35652 did not guarantee that it was using a non-empty
src position to replace an empty one. The new code checks again
and falls back to a more certain position. (The input in question
compiles to a single empty infinite loop, and none of the actual instructions
had any source position at all. That is a bug, but given the pathology
of this input, not one worth dealing with this late in the release cycle,
if ever.)
Literally:
00000 (5) TEXT "".f(SB), ABIInternal
00001 (5) PCDATA $0, $-2
00002 (5) PCDATA $1, $-2
00003 (5) FUNCDATA $0, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
00004 (5) FUNCDATA $1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
00005 (5) FUNCDATA $2, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
b2
00006 (?) XCHGL AX, AX
b6
00007 (+1048575) JMP 6
00008 (?) END
TODO: Add runtime.InfiniteLoop(), replace infinite loops with a call to
that, and use an eco-friendly runtime.gopark instead. (This was Cherry's
excellent idea.)
Updates #35652Fixes#35695
Change-Id: I4b9a841142ee4df0f6b10863cfa0721a7e13b437
Reviewed-on: https://go-review.googlesource.com/c/go/+/207964
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The old recipe for making an infinite loop not be infinite
in the debugger could create an instruction (Prog) with a
line number not tied to any file (index == 0). This caused
downstream failures in DWARF processing.
So don't do that. Also adds a test, also adds a check+panic
to ensure that the next time this happens the error is less
mystifying.
Fixes#35652
Change-Id: I04f30bc94fdc4aef20dd9130561303ff84fd945e
Reviewed-on: https://go-review.googlesource.com/c/go/+/207613
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This reverts CL 207477, restoring CL 207352 with a fix for the
regression observed in the Windows builders.
cmd/compile evidently does not fully support NUL as an output on
Windows, so this time we write ignored 'compile' outputs
to temporary files (instead of os.DevNull as in CL 207352).
Updates #28387Fixes#35619
Change-Id: I2edc5727c3738fa1bccb4b74e50d114cf2a7fcff
Reviewed-on: https://go-review.googlesource.com/c/go/+/207602
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This allows maphash.Hash to be allocated on the stack for typical uses.
Fixes#35636
Change-Id: I8366507d26ea717f47a9fb46d3bd69ba799845ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/207444
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This CL detects infinite loops due to negative dereference cycles
during escape analysis, and terminates the loop gracefully. We still
fail to print a complete explanation of the escape path, but esc.go
didn't print *any* explanation for these test cases, so the release
blocking issue here is simply that we don't infinite loop.
Updates #35518.
Change-Id: I39beed036e5a685706248852f1fa619af3b7abbc
Reviewed-on: https://go-review.googlesource.com/c/go/+/206619
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Unlike function calls, when processing instructions that directly
fault we must not subtract 1 from the pc before looking up the
file/line information.
Since the file/line lookup unconditionally subtracts 1, add 1 to
the faulting instruction PCs to compensate.
Fixes#34123
Change-Id: Ie7361e3d2f84a0d4f48d97e5a9e74f6291ba7a8b
Reviewed-on: https://go-review.googlesource.com/c/go/+/196962
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
This API was added for #25819, where it was discussed as math.FMA.
The commit adding it used math.Fma, presumably for consistency
with the rest of the unusual names in package math
(Sincos, Acosh, Erfcinv, Float32bits, etc).
I believe that using an idiomatic Go name is more important here
than consistency with these other names, most of which are historical
baggage from C's standard library.
Early additions like Float32frombits happened before "uppercase for export"
(so they were originally like "float32frombits") and they were not properly
reconsidered when we uppercased the symbols to export them.
That's a mistake we live with.
The names of functions we have added since then, and even a few
that were legacy, are more properly Go-cased, such as IsNaN, IsInf,
and RoundToEven, rather than Isnan, Isinf, and Roundtoeven.
And also constants like MaxFloat32.
For new API, we should keep using proper Go-cased symbols
instead of minimally-upper-cased-C symbols.
So math.FMA, not math.Fma.
This API has not yet been released, so this change does not break
the compatibility promise.
This CL also modifies cmd/compile, since the compiler knows
the name of the function. I could have stopped at changing the
string constants, but it seemed to make more sense to use a
consistent casing everywhere.
Change-Id: I0f6f3407f41e99bfa8239467345c33945088896e
Reviewed-on: https://go-review.googlesource.com/c/go/+/205317
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
We seem to lack any tests for some corner cases of itab.init
(multiple methods with the same name, breaking itab.init doesn't
seem to fail any tests). We also lack tests that fix text of panics.
Add more tests for itab.init.
Change-Id: Id6b536179ba6b0d45c3cb9dc1c66b9311d0ab85e
Reviewed-on: https://go-review.googlesource.com/c/go/+/202451
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
In the dev.link branch we implemented the new object file format
and (part of) the linker improvements described in
https://golang.org/s/better-linker
The new object file is index-based and provides random access.
The linker maps the object files into read-only memory, and
access symbols on-demand using indices, as opposed to reading
all object files sequentially into the heap with the old format.
The linker carries symbol informations using indices (as opposed
to Symbol data structure). Symbols are created after the
reachability analysis, and only created for reachable symbols.
This reduces the linker's memory usage.
Linking cmd/compile, it creates ~25% fewer Symbols, and reduces
memory usage (inuse_space) by ~15%. (More results from Than.)
Currently, both the old and new object file formats are supported.
The old format is used by default. The new format can be turned
on by using the compiler/assembler/linker's -newobj flag. Note
that the flag needs to be specified consistently to all
compilations, i.e.
go build -gcflags=all=-newobj -asmflags=all=-newobj -ldflags=-newobj
Change-Id: Ia0e35306b5b9b5b19fdc7fa7c602d4ce36fa6abd
The logic for keeping arguments alive for calls to //go:uintptrescapes
functions was only applying to direct function calls. This CL changes
it to also apply to direct method calls, which should address most
uses of Proc.Call and LazyProc.Call.
It's still an open question (#34684) whether other call forms (e.g.,
method expressions, or indirect calls via function values, method
values, or interfaces).
Fixes#34474.
Change-Id: I874f97145972b0e237a4c9e8926156298f4d6ce0
Reviewed-on: https://go-review.googlesource.com/c/go/+/198043
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
CL 200958 adds skipping empty init function feature without any tests
for it. A codegen test sounds ideal, but it's unlikely that we can make
one for now, so use a program to manipulate runtime/proc.go:initTask
directly.
Updates #34869
Change-Id: I2683b9a1ace36af6861af02a3a9fb18b3110b282
Reviewed-on: https://go-review.googlesource.com/c/go/+/204217
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
When we do a successful recover of a panic, we resume normal execution by
returning from the frame that had the deferred call that did the recover (after
executing any remaining deferred calls in that frame).
However, suppose we have called runtime.Goexit and there is a panic during one of the
deferred calls run by the Goexit. Further assume that there is a deferred call in
the frame of the Goexit or a parent frame that does a recover. Then the recovery
process will actually resume normal execution above the Goexit frame and hence
abort the Goexit. We will not terminate the thread as expected, but continue
running in the frame above the Goexit.
To fix this, we explicitly create a _panic object for a Goexit call. We then
change the "abort" behavior for Goexits, but not panics. After a recovery, if the
top-level panic is actually a Goexit that is marked to be aborted, then we return
to the Goexit defer-processing loop, so that the Goexit is not actually aborted.
Actual code changes are just panic.go, runtime2.go, and funcid.go. Adjusted the
test related to the new Goexit behavior (TestRecoverBeforePanicAfterGoexit) and
added several new tests of aborted panics (whose behavior has not changed).
Fixes#29226
Change-Id: Ib13cb0074f5acc2567a28db7ca6912cfc47eecb5
Reviewed-on: https://go-review.googlesource.com/c/go/+/200081
Run-TryBot: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
"declared and not used" is technically correct, but might confuse
the user. Switching "and" to "but" will hopefully create the
contrast for the users: they did one thing (declaration), but
not the other --- actually using the variable.
This new message is still not ideal (specifically, declared is not
entirely precise here), but at least it matches the other parsers
and is one step in the right direction.
Change-Id: I725c7c663535f9ab9725c4b0bf35b4fa74b0eb20
Reviewed-on: https://go-review.googlesource.com/c/go/+/203282
Run-TryBot: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Updates #35157 (the bug there was fixed by CL200861)
Change-Id: I67069207b4cdc2ad4a475dd0bbc8555ecc5f534f
Reviewed-on: https://go-review.googlesource.com/c/go/+/203598
Run-TryBot: Giovanni Bajo <rasky@develer.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alberto Donizetti <alb.donizetti@gmail.com>
Generate inline code at defer time to save the args of defer calls to unique
(autotmp) stack slots, and generate inline code at exit time to check which defer
calls were made and make the associated function/method/interface calls. We
remember that a particular defer statement was reached by storing in the deferBits
variable (always stored on the stack). At exit time, we check the bits of the
deferBits variable to determine which defer function calls to make (in reverse
order). These low-cost defers are only used for functions where no defers
appear in loops. In addition, we don't do these low-cost defers if there are too
many defer statements or too many exits in a function (to limit code increase).
When a function uses open-coded defers, we produce extra
FUNCDATA_OpenCodedDeferInfo information that specifies the number of defers, and
for each defer, the stack slots where the closure and associated args have been
stored. The funcdata also includes the location of the deferBits variable.
Therefore, for panics, we can use this funcdata to determine exactly which defers
are active, and call the appropriate functions/methods/closures with the correct
arguments for each active defer.
In order to unwind the stack correctly after a recover(), we need to add an extra
code segment to functions with open-coded defers that simply calls deferreturn()
and returns. This segment is not reachable by the normal function, but is returned
to by the runtime during recovery. We set the liveness information of this
deferreturn() to be the same as the liveness at the first function call during the
last defer exit code (so all return values and all stack slots needed by the defer
calls will be live).
I needed to increase the stackguard constant from 880 to 896, because of a small
amount of new code in deferreturn().
The -N flag disables open-coded defers. '-d defer' prints out the kind of defer
being used at each defer statement (heap-allocated, stack-allocated, or
open-coded).
Cost of defer statement [ go test -run NONE -bench BenchmarkDefer$ runtime ]
With normal (stack-allocated) defers only: 35.4 ns/op
With open-coded defers: 5.6 ns/op
Cost of function call alone (remove defer keyword): 4.4 ns/op
Text size increase (including funcdata) for go binary without/with open-coded defers: 0.09%
The average size increase (including funcdata) for only the functions that use
open-coded defers is 1.1%.
The cost of a panic followed by a recover got noticeably slower, since panic
processing now requires a scan of the stack for open-coded defer frames. This scan
is required, even if no frames are using open-coded defers:
Cost of panic and recover [ go test -run NONE -bench BenchmarkPanicRecover runtime ]
Without open-coded defers: 62.0 ns/op
With open-coded defers: 255 ns/op
A CGO Go-to-C-to-Go benchmark got noticeably faster because of open-coded defers:
CGO Go-to-C-to-Go benchmark [cd misc/cgo/test; go test -run NONE -bench BenchmarkCGoCallback ]
Without open-coded defers: 443 ns/op
With open-coded defers: 347 ns/op
Updates #14939 (defer performance)
Updates #34481 (design doc)
Change-Id: I63b1a60d1ebf28126f55ee9fd7ecffe9cb23d1ff
Reviewed-on: https://go-review.googlesource.com/c/go/+/202340
Reviewed-by: Austin Clements <austin@google.com>
This change introduces an arm intrinsic that generates the FMULAD
instruction for the fused-multiply-add operation on systems that
support it. System support is detected via cpu.ARM.HasVFPv4. A rewrite
rule translates the generic intrinsic to FMULAD.
Updates #25819.
Change-Id: I8459e5dd1cdbdca35f88a78dbeb7d387f1e20efa
Reviewed-on: https://go-review.googlesource.com/c/go/+/142117
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
To permit ssa-level optimization, this change introduces an amd64 intrinsic
that generates the VFMADD231SD instruction for the fused-multiply-add
operation on systems that support it. System support is detected via
cpu.X86.HasFMA. A rewrite rule can then translate the generic ssa intrinsic
("Fma") to VFMADD231SD.
The benchmark compares the software implementation (old) with the intrinsic
(new).
name old time/op new time/op delta
Fma-4 27.2ns ± 1% 1.0ns ± 9% -96.48% (p=0.008 n=5+5)
Updates #25819.
Change-Id: I966655e5f96817a5d06dff5942418a3915b09584
Reviewed-on: https://go-review.googlesource.com/c/go/+/137156
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
In order to make math.FMA a compiler intrinsic for ISAs like ARM64,
PPC64[le], and S390X, a generic 3-argument opcode "Fma" is provided and
rewritten as
ARM64: (Fma x y z) -> (FMADDD z x y)
PPC64: (Fma x y z) -> (FMADD x y z)
S390X: (Fma x y z) -> (FMADD z x y)
Updates #25819.
Change-Id: Ie5bc628311e6feeb28ddf9adaa6e702c8c291efa
Reviewed-on: https://go-review.googlesource.com/c/go/+/131959
Run-TryBot: Akhil Indurti <aindurti@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
We need to explicitly convert pointers to unsafe.Pointer before
passing to the runtime checkptr instrumentation in case the user
declared their own type with underlying type unsafe.Pointer.
Updates #22218.
Fixes#34966.
Change-Id: I3baa2809d77f8257167cd78f57156f819130baa8
Reviewed-on: https://go-review.googlesource.com/c/go/+/201782
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Generate inline code at defer time to save the args of defer calls to unique
(autotmp) stack slots, and generate inline code at exit time to check which defer
calls were made and make the associated function/method/interface calls. We
remember that a particular defer statement was reached by storing in the deferBits
variable (always stored on the stack). At exit time, we check the bits of the
deferBits variable to determine which defer function calls to make (in reverse
order). These low-cost defers are only used for functions where no defers
appear in loops. In addition, we don't do these low-cost defers if there are too
many defer statements or too many exits in a function (to limit code increase).
When a function uses open-coded defers, we produce extra
FUNCDATA_OpenCodedDeferInfo information that specifies the number of defers, and
for each defer, the stack slots where the closure and associated args have been
stored. The funcdata also includes the location of the deferBits variable.
Therefore, for panics, we can use this funcdata to determine exactly which defers
are active, and call the appropriate functions/methods/closures with the correct
arguments for each active defer.
In order to unwind the stack correctly after a recover(), we need to add an extra
code segment to functions with open-coded defers that simply calls deferreturn()
and returns. This segment is not reachable by the normal function, but is returned
to by the runtime during recovery. We set the liveness information of this
deferreturn() to be the same as the liveness at the first function call during the
last defer exit code (so all return values and all stack slots needed by the defer
calls will be live).
I needed to increase the stackguard constant from 880 to 896, because of a small
amount of new code in deferreturn().
The -N flag disables open-coded defers. '-d defer' prints out the kind of defer
being used at each defer statement (heap-allocated, stack-allocated, or
open-coded).
Cost of defer statement [ go test -run NONE -bench BenchmarkDefer$ runtime ]
With normal (stack-allocated) defers only: 35.4 ns/op
With open-coded defers: 5.6 ns/op
Cost of function call alone (remove defer keyword): 4.4 ns/op
Text size increase (including funcdata) for go cmd without/with open-coded defers: 0.09%
The average size increase (including funcdata) for only the functions that use
open-coded defers is 1.1%.
The cost of a panic followed by a recover got noticeably slower, since panic
processing now requires a scan of the stack for open-coded defer frames. This scan
is required, even if no frames are using open-coded defers:
Cost of panic and recover [ go test -run NONE -bench BenchmarkPanicRecover runtime ]
Without open-coded defers: 62.0 ns/op
With open-coded defers: 255 ns/op
A CGO Go-to-C-to-Go benchmark got noticeably faster because of open-coded defers:
CGO Go-to-C-to-Go benchmark [cd misc/cgo/test; go test -run NONE -bench BenchmarkCGoCallback ]
Without open-coded defers: 443 ns/op
With open-coded defers: 347 ns/op
Updates #14939 (defer performance)
Updates #34481 (design doc)
Change-Id: I51a389860b9676cfa1b84722f5fb84d3c4ee9e28
Reviewed-on: https://go-review.googlesource.com/c/go/+/190098
Reviewed-by: Austin Clements <austin@google.com>
Switch the default to new object files.
Internal linking cgo is disabled for now, as it does not work yet
in newobj mode.
Shared libraries are also broken.
Disable some tests that are known broken for now.
Change-Id: I8ca74793423861d607a2aa7b0d89a4f4d4ca7671
Reviewed-on: https://go-review.googlesource.com/c/go/+/200161
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
The Go spec requires
If a deferred function value evaluates to nil, execution
panics when the function is invoked, not when the "defer"
statement is executed.
On Wasm and AIX, currently we actually emit a nil check at the
point of defer statement, which will make it panic too early.
This CL fixes this.
Also, on Wasm, now the nil function will be passed through
deferreturn to jmpdefer, which does an explicit nil check and
calls sigpanic if it is nil. This sigpanic, being called from
assembly, is ABI0. So change the assembler backend to also
handle sigpanic in ABI0.
Fixes#34926.
Updates #8047.
Change-Id: I28489a571cee36d2aef041f917b8cfdc31d557d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/201297
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
When a subsequent load/store of a ptr makes the nil check of that pointer
unnecessary, if their lines differ, change the line of the load/store
to that of the nilcheck, and attempt to rehome the load/store position
instead.
This fix makes profiling less accurate in order to make panics more
informative.
Fixes#33724
Change-Id: Ib9afaac12fe0d0320aea1bf493617facc34034b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/200197
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Add to the testcase originally created for issue 34577 so
as to also trigger the error condition for issue 34852 (the
two bugs are closely related).
Updates #34577.
Updates #34852.
Change-Id: I2347369652ce500184347606b2bb3e76d802b204
Reviewed-on: https://go-review.googlesource.com/c/go/+/201017
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
When assessing whether A <= B, the poset's OrderedOrEqual has a passing
condition which permits A <= B, but is not sufficient to infer that A <= B.
This CL removes that incorrect passing condition.
Having identified that A and B are in the poset, the method will report that
A <= B if any of these three conditions are true:
(1) A and B are the same node in the poset.
- This means we know that A == B.
(2) There is a directed path, strict or not, from A -> B
- This means we know that, at least, A <= B, but A < B is possible.
(3) There is a directed path from B -> A, AND that path has no strict edges.
- This means we know that B <= A, but do not know that B < A.
In condition (3), we do not have enough information to say that A <= B, rather
we only know that B == A (which satisfies A <= B) is possible. The way I
understand it, a strict edge shows a known, strictly-ordered relation (<) but
the lack of a strict edge does not show the lack of a strictly-ordered relation.
The difference is highlighted by the example in #34802, where a bounds check is
incorrectly removed by prove, such that negative indexes into a slice
succeed:
n := make([]int, 1)
for i := -1; i <= 0; i++ {
fmt.Printf("i is %d\n", i)
n[i] = 1 // No Bounds check, program runs, assignment to n[-1] succeeds!!
}
When prove is checking the negative/failed branch from the bounds check at n[i],
in the signed domain we learn (0 > i || i >= len(n)). Because prove can't learn
the OR condition, we check whether we know that i is non-negative so we can
learn something, namely that i >= len(n). Prove uses the poset to check whether
we know that i is non-negative. At this point the poset holds the following
relations as a directed graph:
-1 <= i <= 0
-1 < 0
In poset.OrderedOrEqual, we are testing for 0 <= i. In this case, condition (3)
above is true because there is a non-strict path from i -> 0, and that path
does NOT have any strict edges. Because this condition is true, the poset
reports to prove that i is known to be >= 0. Knowing, incorrectly, that i >= 0,
prove learns from the failed bounds check that i >= len(n) in the signed domain.
When the slice, n, was created, prove learned that len(n) == 1. Because i is
also the induction variable for the loop, upon entering the loop, prove previously
learned that i is in [-1,0]. So when prove attempts to learn from the failed
bounds check, it finds the new fact, i > len(n), unsatisfiable given that it
previously learned that i <= 0 and len(n) = 1.
Fixes#34802
Change-Id: I235f4224bef97700c3aa5c01edcc595eb9f13afc
Reviewed-on: https://go-review.googlesource.com/c/go/+/200759
Run-TryBot: Zach Jones <zachj1@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Giovanni Bajo <rasky@develer.com>
Reviewed-by: Keith Randall <khr@golang.org>
Increases the exec timeout from 5sec to 1min, but
also print out the error value on any test failure.
Fixes#34836
Change-Id: Ida2b8bd460243491ef0f90dfe0f978dfe02a0703
Reviewed-on: https://go-review.googlesource.com/c/go/+/200519
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Test case with code that caused a gccgo error while emitting export
data for an inlinable function.
Updates #34577.
Change-Id: I28b598c4c893c77f4a76bb4f2d27e5b42f702992
Reviewed-on: https://go-review.googlesource.com/c/go/+/198057
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Currently, escape analysis is able to record at most one dereference
when a parameter leaks to the heap; that is, at call sites, it can't
distinguish between any of these three functions:
func x1(p ****int) { sink = *p }
func x2(p ****int) { sink = **p }
func x3(p ****int) { sink = ***p }
Similarly, it's limited to recording parameter leaks to only the first
4 parameters, and only up to 6 dereferences.
All of these limitations are due to the awkward encoding scheme used
at the moment.
This CL replaces the encoding scheme with a simple [8]uint8 array,
which can handle up to the first 7 parameters, and up to 254
dereferences, which ought to be enough for anyone. And if not, it's
much more easily increased.
Shrinks export data size geometric mean for Kubernetes by 0.07%.
Fixes#33981.
Change-Id: I10a94b9accac9a0c91490e0d6d458316f5ca1e13
Reviewed-on: https://go-review.googlesource.com/c/go/+/197680
Reviewed-by: Cherry Zhang <cherryyz@google.com>
CL 170950 had a regression that makes the compiler produce
an invalid wasm binary if the data section is too large.
Loading such a binary gives the following error:
"LinkError: WebAssembly.instantiate(): data segment is out of bounds"
This change fixes the issue by ensuring that the minimum size of the
linear memory is larger than the end of the data section.
Fixes#34395.
Change-Id: I0c8629de7ffd0d85895ad31bf8c9d45fef197a57
Reviewed-on: https://go-review.googlesource.com/c/go/+/199358
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
We're allowed to remove a write barrier when both the old
value in memory and the new value we're writing are not heap pointers.
Improve both those checks a little bit.
A pointer is known to not be a heap pointer if it is read from
read-only memory. This sometimes happens for loads of pointers
from string constants in read-only memory.
Do a better job of tracking which parts of memory are known to be
zero. Before we just kept track of a range of offsets in the most
recently allocated object. For code that initializes the new object's
fields in a nonstandard order, that tracking is imprecise. Instead,
keep a bit map of the first 64 words of that object, so we can track
precisely what we know to be zeroed.
The new scheme is only precise up to the first 512 bytes of the object.
After that, we'll use write barriers unnecessarily. Hopefully most
initializers of large objects will use typedmemmove, which does only one
write barrier check for the whole initialization.
Fixes#34723
Update #21561
Change-Id: Idf6e1b7d525042fb67961302d4fc6f941393cac8
Reviewed-on: https://go-review.googlesource.com/c/go/+/199558
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
For commuting ops, check whether the second argument is dead before
checking if the first argument is rematerializeable. Reusing the register
holding a dead value is always best.
Fixes#33580
Change-Id: I7372cfc03d514e6774d2d9cc727a3e6bf6ce2657
Reviewed-on: https://go-review.googlesource.com/c/go/+/199559
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
CL 188317 introduced a compiler crash during dwarf generation which
was reported as Issue #34520. After CL 188217, the issue appears to be
fixed. Add a testcase to avoid future regressions.
Fixes#34520
Change-Id: I73544a9e9baf8dbfb85c19eb6d202beea05affb6
Reviewed-on: https://go-review.googlesource.com/c/go/+/198546
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Nilcheck would move statements from NilCheck values to others that
turned out were already dead, which leads to lost statements. Better
to eliminate the dead code first.
One "error" is removed from test/prove.go because the code is
actually dead, and the additional deadcode pass removes it before
prove can run.
Change-Id: If75926ca1acbb59c7ab9c8ef14d60a02a0a94f8b
Reviewed-on: https://go-review.googlesource.com/c/go/+/198479
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
During package initialization, the compiler tries to optimize:
var A = "foo"
var B = A
into
var A = "foo"
var B = "foo"
so that we can statically initialize both A and B and skip emitting
dynamic initialization code to assign "B = A".
However, this isn't safe in the presence of cmd/link's -X flag, which
might overwrite an initialized string-typed variable at link time. In
particular, if cmd/link changes A's static initialization, it won't
know it also needs to change B's static initialization.
To address this, this CL disables this optimization for string-typed
variables.
Fixes#34675.
Change-Id: I1c18f3b855f6d7114aeb39f96aaaf1b452b88236
Reviewed-on: https://go-review.googlesource.com/c/go/+/198657
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
By lazily starting the signal watch loop only on Notify,
we are able to have deadlock detection even when
"os/signal" is imported.
Thanks to Ian Lance Taylor for the solution and discussion.
With this change in, fix a runtime gorountine count test that
assumed that os/signal.init would unconditionally start the
signal watching goroutine, but alas no more.
Fixes#21576.
Change-Id: I6eecf82a887f59f2ec8897f1bcd67ca311ca42ff
Reviewed-on: https://go-review.googlesource.com/c/go/+/101036
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
ORUNESTR represents the special case of integer->string conversion. If
the integer is a constant, then the string is a constant too, so
evconst needs to perform constant folding here.
Passes toolstash-check.
Fixes#34563.
Change-Id: Ieab3d76794d8ce570106b6b707a4bcd725d156e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/197677
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
prove wasn't able to detect induction variables that was bound
by another inducation variable. This happened because an indvar
is a Phi, and thus in case of a dependency, the loop bounding
condition looked as Phi < Phi. This triggered an existing
codepath that checked whether the upper bound was a Phi to
detect loop conditions written in reversed order respect to the
idiomatic way (eg: for i:=0; len(n)>i; i++).
To fix this, we call the indvar pattern matching on both operands
of the loop condition, so that the first operand that matches
will be treated as the indvar.
Updates #24660 (removes a boundcheck from Fannkuch)
Change-Id: Iade83d8deb54f14277ed3f2e37b190e1ed173d11
Reviewed-on: https://go-review.googlesource.com/c/go/+/195220
Reviewed-by: David Chase <drchase@google.com>
Previously, we would recognize &(T{...}) expressions during type
checking, rewrite them into (*T){...}, and then do a lot of extra work
to make sure the user doesn't write (*T){...} themselves and
resynthesizing the OPTRLIT later on.
This CL simply handles &T{...} directly in the straight forward
manner, by changing OADDR directly to OPTRLIT when appropriate.
While here, match go/types's invalid composite literal type error
message.
Passes toolstash-check.
Change-Id: I902b14c7e2cd9fa93e6915dd58272d2352ba38f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/197120
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Now that OpSliceMake is called by runtime.makeslice callers,
prove can see and record the actual length and cap of each
slice being constructed.
This small patch is enough to remove 260 additional bound checks
from cmd+std.
Thanks to Martin Möhrmann for pointing me to CL141822 that
I had missed.
Updates #24660
Change-Id: I14556850f285392051f3f07d13b456b608b64eb9
Reviewed-on: https://go-review.googlesource.com/c/go/+/196784
Run-TryBot: Giovanni Bajo <rasky@develer.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Add a bunch of extra tests and benchmarks for defer, in preparation for new
low-cost (open-coded) implementation of defers (see #34481),
- New file defer_test.go that tests a bunch more unusual defer scenarios,
including things that might have problems for open-coded defers.
- Additions to callers_test.go actually verifying what the stack trace looks like
for various panic or panic-recover scenarios.
- Additions to crash_test.go testing several more crash scenarios involving
recursive panics.
- New benchmark in runtime_test.go measuring speed of panic-recover
- New CGo benchmark in cgo_test.go calling from Go to C back to Go that
shows defer overhead
Updates #34481
Change-Id: I423523f3e05fc0229d4277dd00073289a5526188
Reviewed-on: https://go-review.googlesource.com/c/go/+/197017
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Currently, when we create an OPTRLIT node, it defaults to the
OCOMPLIT's final element's position. But it improves error messages to
use the OCOMPLIT's own position instead.
Change-Id: Ibb031f543c7248d88d99fd0737685e01d86e2500
Reviewed-on: https://go-review.googlesource.com/c/go/+/197119
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This commit just adds a regress test for a few of the important corner
cases that I identified in #27557, which turn out to not be tested
anywhere.
While here, annotate a few of the existing test cases where we could
improve escape analysis.
Updates #27557.
Change-Id: Ie57792a538f7899bb17915485fabc86100f469a3
Reviewed-on: https://go-review.googlesource.com/c/go/+/197137
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
On modern 64bit CPUs a SHR, SHL or AND instruction take 1 cycle to execute.
A pair of shifts that operate on the same register will take 2 cycles
and needs to wait for the input register value to be available.
Large constants used to mask the high bits of a register with an AND
instruction can not be encoded as an immediate in the AND instruction
on amd64 and therefore need to be loaded into a register with a MOV
instruction.
However that MOV instruction is not dependent on the output register and
on many CPUs does not compete with the AND or shift instructions for
execution ports.
Using a pair of shifts to mask high bits instead of an AND to mask high
bits of a register has a shorter encoding and uses one less general
purpose register but is slower due to taking one clock cycle longer
if there is no register pressure that would make the AND variant need to
generate a spill.
For example the instructions emitted for (x & 1 << 63) before this CL are:
48c1ea3f SHRQ $0x3f, DX
48c1e23f SHLQ $0x3f, DX
after this CL the instructions are the same as GCC and LLVM use:
48b80000000000000080 MOVQ $0x8000000000000000, AX
4821d0 ANDQ DX, AX
Some platforms such as arm64 already have SSA optimization rules to fuse
two shift instructions back into an AND.
Removing the general rule to rewrite AND to SHR+SHL speeds up this benchmark:
var GlobalU uint
func BenchmarkAndHighBits(b *testing.B) {
x := uint(0)
for i := 0; i < b.N; i++ {
x &= 1 << 63
}
GlobalU = x
}
amd64/darwin on Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz:
name old time/op new time/op delta
AndHighBits-4 0.61ns ± 6% 0.42ns ± 6% -31.42% (p=0.000 n=25+25):
'go run run.go -all_codegen -v codegen' passes with following adjustments:
ARM64: The BFXIL pattern ((x << lc) >> rc | y & ac) needed adjustment
since ORshiftRL generation fusing '>> rc' and '|' interferes
with matching ((x << lc) >> rc) to generate UBFX. Previously
ORshiftLL was created first using the shifts generated for (y & ac).
S390X: Add rules for abs and copysign to match use of AND instead of SHIFTs.
Updates #33826
Updates #32781
Change-Id: I5a59f6239660d53c029cd22dfb44ddf39f93a56c
Reviewed-on: https://go-review.googlesource.com/c/go/+/196810
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
On modern 64bit CPUs a SHR, SHL or AND instruction take 1 cycle to execute.
A pair of shifts that operate on the same register will take 2 cycles
and needs to wait for the input register value to be available.
Large constants used to mask the high bits of a register with an AND
instruction can not be encoded as an immediate in the AND instruction
on amd64 and therefore need to be loaded into a register with a MOV
instruction.
However that MOV instruction is not dependent on the output register and
on many CPUs does not compete with the AND or shift instructions for
execution ports.
Using a pair of shifts to mask high bits instead of an AND to mask high
bits of a register has a shorter encoding and uses one less general
purpose register but is slower due to taking one clock cycle longer
if there is no register pressure that would make the AND variant need to
generate a spill.
For example the instructions emitted for (x & 1 << 63) before this CL are:
48c1ea3f SHRQ $0x3f, DX
48c1e23f SHLQ $0x3f, DX
after this CL the instructions are the same as GCC and LLVM use:
48b80000000000000080 MOVQ $0x8000000000000000, AX
4821d0 ANDQ DX, AX
Some platforms such as arm64 already have SSA optimization rules to fuse
two shift instructions back into an AND.
Removing the general rule to rewrite AND to SHR+SHL speeds up this benchmark:
var GlobalU uint
func BenchmarkAndHighBits(b *testing.B) {
x := uint(0)
for i := 0; i < b.N; i++ {
x &= 1 << 63
}
GlobalU = x
}
amd64/darwin on Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz:
name old time/op new time/op delta
AndHighBits-4 0.61ns ± 6% 0.42ns ± 6% -31.42% (p=0.000 n=25+25):
'go run run.go -all_codegen -v codegen' passes with following adjustments:
ARM64: The BFXIL pattern ((x << lc) >> rc | y & ac) needed adjustment
since ORshiftRL generation fusing '>> rc' and '|' interferes
with matching ((x << lc) >> rc) to generate UBFX. Previously
ORshiftLL was created first using the shifts generated for (y & ac).
S390X: Add rules for abs and copysign to match use of AND instead of SHIFTs.
Updates #33826
Updates #32781
Change-Id: I43227da76b625de03fbc51117162b23b9c678cdb
Reviewed-on: https://go-review.googlesource.com/c/go/+/194297
Run-TryBot: Martin Möhrmann <martisch@uos.de>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
i32.eqz instructions don't appear unless needed in if conditions anymore
after CL 195204. I forgot to run the codegen tests while submitting the CL.
Thanks to @martisch for catching it.
Fixes#34442
Change-Id: I177b064b389be48e39d564849714d7a8839be13e
Reviewed-on: https://go-review.googlesource.com/c/go/+/196580
Run-TryBot: Agniva De Sarker <agniva.quicksilver@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Martin Möhrmann <moehrmann@google.com>
When compiling expression switches, we try to optimize runs of
constants into binary searches. The ordering used isn't visible to the
application, so it's unimportant as long as we're consistent between
sorting and searching.
For strings, it's much cheaper to compare string lengths than strings
themselves, so instead of ordering strings by "si <= sj", we currently
order them by "len(si) < len(sj) || len(si) == len(sj) && si <= sj"
(i.e., the lexicographical ordering on the 2-tuple (len(s), s)).
However, it's also somewhat cheaper to compare strings for equality
(i.e., ==) than for ordering (i.e., <=). And if there were two or
three string constants of the same length in a switch statement, we
might unnecessarily emit ordering comparisons.
For example, given:
switch s {
case "", "1", "2", "3": // ordered by length then content
goto L
}
we currently compile this as:
if len(s) < 1 || len(s) == 1 && s <= "1" {
if s == "" { goto L }
else if s == "1" { goto L }
} else {
if s == "2" { goto L }
else if s == "3" { goto L }
}
This CL switches to using a 2-level binary search---first on len(s),
then on s itself---so that string ordering comparisons are only needed
when there are 4 or more strings of the same length. (4 being the
cut-off for when using binary search is actually worthwhile.)
So the above switch instead now compiles to:
if len(s) == 0 {
if s == "" { goto L }
} else if len(s) == 1 {
if s == "1" { goto L }
else if s == "2" { goto L }
else if s == "3" { goto L }
}
which is better optimized by walk and SSA. (Notably, because there are
only two distinct lengths and no more than three strings of any
particular length, this example ends up falling back to simply using
linear search.)
Test case by khr@ from CL 195138.
Fixes#33934.
Change-Id: I8eeebcaf7e26343223be5f443d6a97a0daf84f07
Reviewed-on: https://go-review.googlesource.com/c/go/+/195340
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
golang.org/cl/109517 optimized the compiler to avoid the allocation for make in
append(x, make([]T, y)...). This was only implemented for the case that y has type int.
This change extends the optimization to trigger for all integer types where the value
is known at compile time to fit into an int.
name old time/op new time/op delta
ExtendInt-12 106ns ± 4% 106ns ± 0% ~ (p=0.351 n=10+6)
ExtendUint64-12 1.03µs ± 5% 0.10µs ± 4% -90.01% (p=0.000 n=9+10)
name old alloc/op new alloc/op delta
ExtendInt-12 0.00B 0.00B ~ (all equal)
ExtendUint64-12 13.6kB ± 0% 0.0kB -100.00% (p=0.000 n=10+10)
name old allocs/op new allocs/op delta
ExtendInt-12 0.00 0.00 ~ (all equal)
ExtendUint64-12 1.00 ± 0% 0.00 -100.00% (p=0.000 n=10+10)
Updates #29785
Change-Id: Ief7760097c285abd591712da98c5b02bc3961fcd
Reviewed-on: https://go-review.googlesource.com/c/go/+/182559
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This CL expands the test for #29612 to check that type switches also
work correctly when type hashes collide.
Change-Id: Ia153743e6ea0736c1a33191acfe4d8ba890be527
Reviewed-on: https://go-review.googlesource.com/c/go/+/195782
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Support for overlapping interfaces is a new (proposed) Go language
feature to be supported in Go 1.14, so it shouldn't be supported under
-lang=go1.13 or earlier.
Fixes#34329.
Change-Id: I5fea5716b7d135476980bc40b4f6e8c611b67735
Reviewed-on: https://go-review.googlesource.com/c/go/+/195678
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This reverts CL 192101.
Reason for revert: The same paragraph was added 2 weeks ago
(look a few lines above)
Change-Id: I05efb2631d7b4966f66493f178f2a649c715a3cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/195637
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This information is redundant with the position information already
provided. Also, no other -m diagnostics print out function name.
While here, report parameter leak diagnostics against the parameter
declaration position rather than the function, and use Warnl for
"moved to heap" messages.
Test cases updated programmatically by removing the first word from
every "no match for" error emitted by run.go:
go run run.go |& \
sed -E -n 's/^(.*):(.*): no match for `([^ ]* (.*))` in:$/\1!\2!\3!\4/p' | \
while IFS='!' read -r fn line before after; do
before=$(echo "$before" | sed 's/[.[\*^$()+?{|]/\\&/g')
after=$(echo "$after" | sed -E 's/(\&|\\)/\\&/g')
fn=$(find . -name "${fn}" | head -1)
sed -i -E -e "${line}s/\"${before}\"/\"${after}\"/" "${fn}"
done
Passes toolstash-check.
Change-Id: I6e02486b1409e4a8dbb2b9b816d22095835426b5
Reviewed-on: https://go-review.googlesource.com/c/go/+/195040
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
It is useful to know about the -all_codegen option for running
codegen tests for all platforms. I was puzzling that some codegen
test was not failing on my local machine or on trybot, until I
found this option.
Change-Id: I062cf4d73f6a6c9ebc2258195779d2dab21bc36d
Reviewed-on: https://go-review.googlesource.com/c/go/+/192101
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This change adds an intrinsic for Mul64 on s390x. To achieve that,
a new assembly instruction, MLGR, is introduced in s390x/asmz.go. This assembly
instruction directly uses an existing instruction on Z and supports multiplication
of two 64 bit unsigned integer and stores the result in two separate registers.
In this case, we require the multiplcand to be stored in register R3 and
the output result (the high and low 64 bit of the product) to be stored in
R2 and R3 respectively.
A test case is also added.
Benchmark:
name old time/op new time/op delta
Mul-18 11.1ns ± 0% 1.4ns ± 0% -87.39% (p=0.002 n=8+10)
Mul32-18 2.07ns ± 0% 2.07ns ± 0% ~ (all equal)
Mul64-18 11.1ns ± 1% 1.4ns ± 0% -87.42% (p=0.000 n=10+10)
Change-Id: Ieca6ad1f61fff9a48a31d50bbd3f3c6d9e6675c1
Reviewed-on: https://go-review.googlesource.com/c/go/+/194572
Reviewed-by: Michael Munday <mike.munday@ibm.com>
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Part of the general trend of moving yyerror calls out of walk and into
typecheck.
Notably, this requires splitting test/typeswitch2.go into two files,
because now some of the errors are reported during typecheck and
others are still reported during walk; and if there were any errors
during typecheck, then cmd/compile exits without invoking walk.
Passes toolstash-check.
Change-Id: I05ee0c00b99af659ee1eef098d342d0d736cf31e
Reviewed-on: https://go-review.googlesource.com/c/go/+/194659
Reviewed-by: Robert Griesemer <gri@golang.org>
This CL moves parameter tagging to before escape analysis is complete,
so we still have access to EscLocation. This will be useful once
EscLocation starts tracking higher-fidelity escape details.
Notably, this CL stops using n.Esc to record parameter escape analysis
details. Now escape analysis only ever sets n.Esc to EscNone or
EscHeap. (It still defaults to EscUnknown, and is set to EscNever in
some places though.)
Passes toolstash-check.
Updates #33981.
Change-Id: I50a91ea1e38c442092de6cd14e20b211f8f818c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/193178
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This CL gets rid of the MOVDreg and MOVDnop SSA operations on
s390x. They were originally inserted to help avoid situations
where a sign/zero extension was elided but a spill invalidated
the optimization. It's not really clear we need to do this though
(amd64 doesn't have these ops for example) so long as we are
careful when removing sign/zero extensions. Also, the MOVDreg
technique doesn't work if the register is spilled before the
MOVDreg op (I haven't seen that in practice).
Removing these ops reduces the complexity of the rules and also
allows us to unblock optimizations. For example, the compiler can
now merge the loads in binary.{Big,Little}Endian.PutUint16 which
it wasn't able to do before. This CL reduces the size of the .text
section in the go tool by about 4.7KB (0.09%).
Change-Id: Icaddae7f2e4f9b2debb6fabae845adb3f73b41db
Reviewed-on: https://go-review.googlesource.com/c/go/+/173897
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Previously, we used a single "untyped number" type for all untyped
numeric constants. This led to vague error messages like "string(1.0)"
reporting that "1 (type untyped number)" can't be converted to string,
even though "string(1)" is valid.
This CL makes cmd/compile more like go/types by utilizing
types.Ideal{int,rune,float,complex} instead of types.Types[TIDEAL],
and keeping n.Type in sync with n.Val().Ctype() during constant
folding.
Thanks to K Heller for looking into this issue, and for the included
test case.
Fixes#21979.
Change-Id: Ibfea88c05704bc3c0a502a455d018a375589754d
Reviewed-on: https://go-review.googlesource.com/c/go/+/194019
Reviewed-by: Robert Griesemer <gri@golang.org>
On modern 64bit CPUs a SHR, SHL or AND instruction take 1 cycle to execute.
A pair of shifts that operate on the same register will take 2 cycles
and needs to wait for the input register value to be available.
Large constants used to mask the high bits of a register with an AND
instruction can not be encoded as an immediate in the AND instruction
on amd64 and therefore need to be loaded into a register with a MOV
instruction.
However that MOV instruction is not dependent on the output register and
on many CPUs does not compete with the AND or shift instructions for
execution ports.
Using a pair of shifts to mask high bits instead of an AND to mask high
bits of a register has a shorter encoding and uses one less general
purpose register but is slower due to taking one clock cycle longer
if there is no register pressure that would make the AND variant need to
generate a spill.
For example the instructions emitted for (x & 1 << 63) before this CL are:
48c1ea3f SHRQ $0x3f, DX
48c1e23f SHLQ $0x3f, DX
after this CL the instructions are the same as GCC and LLVM use:
48b80000000000000080 MOVQ $0x8000000000000000, AX
4821d0 ANDQ DX, AX
Some platforms such as arm64 already have SSA optimization rules to fuse
two shift instructions back into an AND.
Removing the general rule to rewrite AND to SHR+SHL speeds up this benchmark:
var GlobalU uint
func BenchmarkAndHighBits(b *testing.B) {
x := uint(0)
for i := 0; i < b.N; i++ {
x &= 1 << 63
}
GlobalU = x
}
amd64/darwin on Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz:
name old time/op new time/op delta
AndHighBits-4 0.61ns ± 6% 0.42ns ± 6% -31.42% (p=0.000 n=25+25):
Updates #33826
Updates #32781
Change-Id: I862d3587446410c447b9a7265196b57f85358633
Reviewed-on: https://go-review.googlesource.com/c/go/+/191780
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Use the following (suboptimal) script to obtain a list of possible
typos:
#!/usr/bin/env sh
set -x
git ls-files |\
grep -e '\.\(c\|cc\|go\)$' |\
xargs -n 1\
awk\
'/\/\// { gsub(/.*\/\//, ""); print; } /\/\*/, /\*\// { gsub(/.*\/\*/, ""); gsub(/\*\/.*/, ""); }' |\
hunspell -d en_US -l |\
grep '^[[:upper:]]\{0,1\}[[:lower:]]\{1,\}$' |\
grep -v -e '^.\{1,4\}$' -e '^.\{16,\}$' |\
sort -f |\
uniq -c |\
awk '$1 == 1 { print $2; }'
Then, go through the results manually and fix the most obvious typos in
the non-vendored code.
Change-Id: I3cb5830a176850e1a0584b8a40b47bde7b260eae
Reviewed-on: https://go-review.googlesource.com/c/go/+/193848
Reviewed-by: Robert Griesemer <gri@golang.org>
This CL detangles the hairy mess that was convlit+defaultlit. In
particular, it makes the following changes:
1. convlit1 now follows the standard typecheck behavior of setting
"n.Type = nil" if there's an error. Notably, this means for a lot of
test cases, we now avoid reporting useless follow-on error messages.
For example, after reporting that "1 << s + 1.0" has an invalid shift,
we no longer also report that it can't be assigned to string.
2. Previously, assignconvfn had some extra logic for trying to
suppress errors from convlit/defaultlit so that it could provide its
own errors with better context information. Instead, this extra
context information is now passed down into convlit1 directly.
3. Relatedly, this CL also removes redundant calls to defaultlit prior
to assignconv. As a consequence, when an expression doesn't make sense
for a particular assignment (e.g., assigning an untyped string to an
integer), the error messages now say "untyped string" instead of just
"string". This is more consistent with go/types behavior.
4. defaultlit2 is now smarter about only trying to convert pairs of
untyped constants when it's likely to succeed. This allows us to
report better error messages for things like 3+"x"; instead of "cannot
convert 3 to string" we now report "mismatched types untyped number
and untyped string".
Passes toolstash-check.
Change-Id: I26822a02dc35855bd0ac774907b1cf5737e91882
Reviewed-on: https://go-review.googlesource.com/c/go/+/187657
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This reverts commit 2da9c3e0f9.
Reason for revert: while the new error messages are more informative,
they're not strictly correct. This CL also conflicts with CL 187657.
Change-Id: I1c36cf7e86c2f35ee83a4f98918ee38aa1f59965
Reviewed-on: https://go-review.googlesource.com/c/go/+/193977
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Follow-up to Change-Id: If6e52c59eab438599d641ecf6f110ebafca740a9
This addresses the remaining tech debt on issue 21979.
The aforementioned previous CL silenced one of two mostly redundant
compiler errors. However, the silenced error was the more expressive
error. This CL now imbues the surviving error with the same level
of expressiveness as the old semi-redundant error.
Fixes#21979
Change-Id: I3273d48c88bbab073fabe53421d801df621ce321
Reviewed-on: https://go-review.googlesource.com/c/go/+/191079
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Test with some code that triggered a compilation error bug in gccgo.
Updates #33866.
Change-Id: Ib2f226bbbebbfae33b41037438fe34dc5f2ad034
Reviewed-on: https://go-review.googlesource.com/c/go/+/193261
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Add block method to preserve loop depth when evaluating statements in a
block, so escape analysis can handle looping label more precisely.
Updates #22438
Change-Id: I39b306544a6c0ee3fcbebbe0d0ee735cb71773e6
Reviewed-on: https://go-review.googlesource.com/c/go/+/193517
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Right now we generate hash functions for all types, just in case they
are used as map keys. That's a lot of wasted effort and binary size
for types which will never be used as a map key. Instead, generate
hash functions only for types that we know are map keys.
Just doing that is a bit too simple, since maps with an interface type
as a key might have to hash any concrete key type that implements that
interface. So for that case, implement hashing of such types at
runtime (instead of with generated code). It will be slower, but only
for maps with interface types as keys, and maybe only a bit slower as
the aeshash time probably dominates the dispatch time.
Reorg where we keep the equals and hash functions. Move the hash function
from the key type to the map type, saving a field in every non-map type.
That leaves only one function in the alg structure, so get rid of that and
just keep the equal function in the type descriptor itself.
cmd/go now has 10 generated hash functions, instead of 504. Makes
cmd/go 1.0% smaller. Update #6853.
Speed on non-interface keys is unchanged. Speed on interface keys
is ~20% slower:
name old time/op new time/op delta
MapInterfaceString-8 23.0ns ±21% 27.6ns ±14% +20.01% (p=0.002 n=10+10)
MapInterfacePtr-8 19.4ns ±16% 23.7ns ± 7% +22.48% (p=0.000 n=10+8)
Change-Id: I7c2e42292a46b5d4e288aaec4029bdbb01089263
Reviewed-on: https://go-review.googlesource.com/c/go/+/191198
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Martin Möhrmann <moehrmann@google.com>
Assinging to 1-element array/1-field struct variable is considered clobbering
the whole variable. By emitting OpVarDef in this case, liveness analysis
can now know the variable is redefined.
Also, the isfat is not necessary anymore, and will be removed in follow up CL.
Fixes#33916
Change-Id: Iece0d90b05273f333d59d6ee5b12ee7dc71908c2
Reviewed-on: https://go-review.googlesource.com/c/go/+/192979
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
In general, a conversion to interface type may require values to be
boxed, which in turn necessitates escape analysis to determine whether
the boxed representation can be stack allocated.
However, esc.go used to unconditionally print escape analysis
decisions about OCONVIFACE, even for conversions that don't require
boxing (e.g., pointers, channels, maps, functions).
For test compatibility with esc.go, escape.go similarly printed these
useless diagnostics. This CL removes the diagnostics, and updates test
expectations accordingly.
Change-Id: I97c57a4a08e44d265bba516c78426ff4f2bf1e12
Reviewed-on: https://go-review.googlesource.com/c/go/+/192697
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This CL extends {defer,resume}checkwidth to support nesting, which
simplifies usage.
Updates #33658.
Change-Id: Ib3ffb8a7cabfae2cbeba74e21748c228436f4726
Reviewed-on: https://go-review.googlesource.com/c/go/+/192721
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
For performance reasons (avoiding costly cross-compilations) CL 177577
changed the codegen test harness to only run the tests for the
machine's GOARCH by default.
This change updates the codegen README accordingly, explaining what
all.bash does run by default and how to perform the tests for all
architectures.
Fixes#33924
Change-Id: I43328d878c3e449ebfda46f7e69963a44a511d40
Reviewed-on: https://go-review.googlesource.com/c/go/+/192619
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
This CL eliminates unnecessary pairs of I32WrapI64 and
I64ExtendI32U generated by the WASM backend for IF
statements. And it makes the total size of pkg/js_wasm/
decreases about 490KB.
Change-Id: I16b0abb686c4e30d5624323166ec2d0ec57dbe2d
Reviewed-on: https://go-review.googlesource.com/c/go/+/191758
Run-TryBot: Ben Shi <powerman1st@163.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Richard Musiol <neelance@gmail.com>
This CL reverts CL 192097 and fixes the issue in CL 189277.
Change-Id: Icd271262e1f5019a8e01c91f91c12c1261eeb02b
Reviewed-on: https://go-review.googlesource.com/c/go/+/192519
Run-TryBot: Ben Shi <powerman1st@163.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Raising an out-of-bounds panic is confusing. There's no indication
that the underlying problem is a race.
The runtime already does a pretty good job of detecting this kind of
race (modification while iterating). We might as well just reorganize
a bit to avoid the out-of-bounds panic.
Fixes#33275
Change-Id: Icdd337ad2eb3c84f999db0850ec1d2ff2c146b6e
Reviewed-on: https://go-review.googlesource.com/c/go/+/191197
Reviewed-by: Martin Möhrmann <moehrmann@google.com>
- only convert literal strings if there were no syntax errors
(some of the conversion routines exit if there is an error)
- mark nodes for literals with syntax errors to avoid follow-on
errors
- don't attempt to import packages whose path had syntax errors
Fixes#32133.
Change-Id: I1803ad48c65abfecf6f48ddff1e27eded5e282c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/192437
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The existing pointer comparison optimizations
don't include pointer arithmetic. Add them.
These rules trigger a few times in std cmd, while compiling:
time.Duration.String
cmd/go/internal/tlog.NodeHash
crypto/tls.ticketKeyFromBytes (3 times)
crypto/elliptic.(*p256Point).p256ScalarMult (15 times!)
crypto/elliptic.initTable
These weird comparisons occur when using the copy builtin,
which does a pointer comparison between src and dst.
This also happens to fix#32454, by optimizing enough
early on that all values can be eliminated.
Fixes#32454
Change-Id: I799d45743350bddd15a295dc1e12f8d03c11d1c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/180940
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
The original report in #5172 was that cmd/compile was generating bogus
follow-on error messages when typechecking a struct failed. Instead of
fixing those follow-on error messages, golang.org/cl/9614044 suppress all
follow-on error messages after struct typecheck fails. We should
continue emitting error messages instead.
While at it, also add the test case for original report.
Fixes#33947
Change-Id: I4a5c6878977128abccd704350a12df743631c7bf
Reviewed-on: https://go-review.googlesource.com/c/go/+/191944
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Complex type is the only TIDEAL that lack of support for all comparison
operators. When rewriting constant comparison into literal node, that
missing cause compiler raise an internal error.
Checking the operator is available for complex type before that fix the
problem.
We can make this check works more generally if there's more type lack of
supporting all comparison operators added, but it does not seem to be
happened, so just check explicitly for complex only.
Fixes#32723
Change-Id: I4938b1bdcbcdae9a9d87436024984bd2ab12995e
Reviewed-on: https://go-review.googlesource.com/c/go/+/183459
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
typecheck only set n.Type.Nod for declared type, and leave it nil for
anonymous types, type alias. It leads to compiler crashes, because
n.Type.Nod is nil at the time dowidth was called.
Fixing it by set n.Type.Nod right after n.Type initialization if n.Op is
OTYPE.
When embedding interface cycles involve in type alias, it also helps
pointing the error message to the position of the type alias
declaration, instead of position of embedding interface.
Fixes#31872
Change-Id: Ia18391e987036a91f42ba0c08b5506f52d07f683
Reviewed-on: https://go-review.googlesource.com/c/go/+/191540
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Testcase for a gollvm bug (assert in Llvm_backend::materializeComposite).
Updates golang/go#33020.
Change-Id: Icdf5b4b2b6eb55a5b48a31a61c41215b1ae4cf01
Reviewed-on: https://go-review.googlesource.com/c/go/+/191743
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The syntax of a shifted operation does not have a "$" sign for
the shift amount. Remove it.
Change-Id: I50782fe942b640076f48c2fafea4d3175be8ff99
Reviewed-on: https://go-review.googlesource.com/c/go/+/192100
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This will improve liveness analysis slightly, the same logic as
isdirectiface curently does. In:
type T struct {
m map[int]int
}
v := T{}
v.m = make(map[int]int)
T is considered "fat", now it is not. So assigning to v.m is considered
to clobber the entire v.
This is follow up of CL 179057.
Change-Id: Id6b4807b8e8521ef5d8bcb14fedb6dceb9dbf18c
Reviewed-on: https://go-review.googlesource.com/c/go/+/179578
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
In interface-to-concrete comparisons, we are short circuiting on the interface
value's dynamic type before evaluating the concrete expression for side effects,
causing concrete expression won't panic at runtime, while it should.
To fix it, evaluating the RHS of comparison before we do the short-circuit.
We also want to prioritize panics in the LHS over the RHS, so evaluating
the LHS too.
Fixes#32187
Change-Id: I15b58a523491b7fd1856b8fdb9ba0cba5d11ebb4
Reviewed-on: https://go-review.googlesource.com/c/go/+/178817
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Prep for subsequent CLs to remove old escape analysis pass.
This CL removes -newescape=true from tests that use it, and deletes
tests that use -newescape=false. (For history, see CL 170447.)
Notably, this removes escape_because.go without any replacement, but
this is being tracked by #31489.
Change-Id: I6f6058d58fff2c5d210cb1d2713200cc9f501ca7
Reviewed-on: https://go-review.googlesource.com/c/go/+/187617
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Extend the optimization introduced in CL 141118 to the wasm architecture.
And for reference, the rules trigger 212 times while building std and cmd
$GOOS=js GOARCH=wasm gotip build std cmd
$grep -E "Wasm.rules:44(1|2|3|4)" rulelog | wc -l
212
Updates #26498
Change-Id: I153684a2b98589ae812b42268da08b65679e09d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/185477
Run-TryBot: Agniva De Sarker <agniva.quicksilver@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Richard Musiol <neelance@gmail.com>
Use the shiftIsBounded function to generate more efficient
Shift instructions.
Updates #25167
Change-Id: Id350f8462dc3a7ed3bfed0bcbea2860b8f40048a
Reviewed-on: https://go-review.googlesource.com/c/go/+/182558
Run-TryBot: Agniva De Sarker <agniva.quicksilver@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Richard Musiol <neelance@gmail.com>
This CL optimizes math.bits.TrailingZeros16 on 386 with
a pair of BSFL and ORL instrcutions.
The case TrailingZeros16-4 of the benchmark test in
math/bits shows big improvement.
name old time/op new time/op delta
TrailingZeros16-4 1.55ns ± 1% 0.87ns ± 1% -43.87% (p=0.000 n=50+49)
Change-Id: Ia899975b0e46f45dcd20223b713ed632bc32740b
Reviewed-on: https://go-review.googlesource.com/c/go/+/189277
Run-TryBot: Ben Shi <powerman1st@163.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This CL add test cases for the unary FP negative
operation.
Change-Id: I54e7292ca9df05da0c2b113adefc97ee1e94c6e2
Reviewed-on: https://go-review.googlesource.com/c/go/+/190937
Run-TryBot: Ben Shi <powerman1st@163.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This CL performs the branchelim optimization on WASM with its
select instruction. And the total size of pkg/js_wasm decreased
about 80KB by this optimization.
Change-Id: I868eb146120a1cac5c4609c8e9ddb07e4da8a1d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/190957
Run-TryBot: Ben Shi <powerman1st@163.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Richard Musiol <neelance@gmail.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Because the Node AST represents references to declared objects (e.g.,
variables, packages, types, constants) by directly pointing to the
referred object, we don't have use-position info for these objects.
For switch statements with duplicate cases, we report back where the
first duplicate value appeared. However, due to the AST
representation, if the value was a declared constant, we mistakenly
reported the constant declaration position as the previous case
position.
This CL reports back against the 'case' keyword's position instead, if
there's no more precise information available to us.
It also refactors code to emit the same "previous at" error message
for duplicate values in map literals.
Thanks to Emmanuel Odeke for the test case.
Fixes#33460.
Change-Id: Iec69542ccd4aad594dde8df02d1b880a422c5622
Reviewed-on: https://go-review.googlesource.com/c/go/+/188901
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The assembly output for x & c == c, where c is power of 2:
MOVQ "".set+8(SP), AX
ANDQ $8, AX
CMPQ AX, $8
SETEQ "".~r2+24(SP)
With optimization using bitset:
MOVQ "".set+8(SP), AX
BTL $3, AX
SETCS "".~r2+24(SP)
output less than 1 instruction.
However, there is no speed improvement:
name old time/op new time/op delta
AllBitSet-8 0.35ns ± 0% 0.35ns ± 0% ~ (all equal)
Fixes#31904
Change-Id: I5dca4e410bf45716ed2145e3473979ec997e35d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/175957
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Array accesses with index types smaller than the machine word size may
involve a sign or zero extension of the index value before bounds
checking. Currently, this defeats prove because the facts about the
original index value don't flow through the sign/zero extension.
This CL fixes this by looking back through value-preserving sign/zero
extensions when adding facts via Update and, where appropriate, applying
the same facts using the pre-extension value. This fix is enhanced by
also looking back through value-preserving extensions within
ft.isNonNegative to infer whether the extended value is known to be
non-negative. Without this additional isNonNegative enhancement, this
logic is rendered significantly less effective by the limitation
discussed in the next paragraph.
In Update, the application of facts to pre-extension values is limited
to cases where the domain of the new fact is consistent with the type of
the pre-extension value. There may be cases where this cross-domain
passing of facts is valid, but distinguishing them from the invalid
cases is difficult for me to reason about and to implement.
Assessing which cases to allow requires details about the context and
inferences behind the fact being applied which are not available
within Update. Additional difficulty arises from the fact that the SSA
does not curently differentiate extensions added by the compiler for
indexing operations, extensions added by the compiler for implicit
conversions, or explicit extensions from the source.
Examples of some cases that would need to be filtered correctly for
cross-domain facts:
(1) A uint8 is zero-extended to int for indexing (a value-preserving
zeroExt). When, if ever, can signed domain facts learned about the int be
applied to the uint8?
(2) An int8 is sign-extended to int16 (value-preserving) for an equality
comparison. Equality comparison facts are currently always learned in both
the signed and unsigned domains. When, if ever, can the unsigned facts
learned about the int16, from the int16 != int16 comparison, be applied
to the original int8?
This is an alternative to CL 122695 and CL 174309. Compared to CL 122695,
this CL differs in that the facts added about the pre-extension value will
pass through the Update method, where additional inferences are processed
(e.g. fence-post implications, see #29964). CL 174309 is limited to bounds
checks, so is narrower in application, and makes the code harder to read.
Fixes#26292.
Fixes#29964.
Fixes#15074
Removes 238 bounds checks from std/cmd.
Change-Id: I1f87c32ee672bfb8be397b27eab7a4c2f304893f
Reviewed-on: https://go-review.googlesource.com/c/go/+/174704
Run-TryBot: Zach Jones <zachj1@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Giovanni Bajo <rasky@develer.com>
Don't skip closing parentheses of any kind after a missing
expression. They are likely part of the lexical construct
enclosing the expression.
Fixes#33386.
Change-Id: Ic0abc2037ec339a345ec357ccc724b7ad2a64c00
Reviewed-on: https://go-review.googlesource.com/c/go/+/188502
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Dan Scales
Cuong Manh Le
Keith Randall
Meng Zhuo
Ian Lance Taylor
Robert Griesemer
Cherry Mui
Matthew Dempsky
Than McIntosh
nimelehin
Gerrit Code Review
Zachary Burkett
Joel Sing
Ruslan Andreev
David Chase
eric fang
Josh Bleecher Snyder
Cuong Manh Le
Russ Cox
Austin Clements
KimMachineGun
fanzha02
Pat Gavlin
Bryan C. Mills
Lynn Boger
Paul E. Murphy
John Bampton
Egon Elbre
Alejandro García Montoro
zhengjianxun
Rob Findley
Tom Thorogood
Junchen Li
Alexander Rakoczy
Jason A. Donenfeld
Alberto Donizetti
Cholerae Hu
Michael Munday
Branden J Brown
zdjones
Xiangdong Ji
Agniva De Sarker
diaxu01
Tobias Klauser
Dmitri Shuralyov
Richard Musiol
Emmanuel T Odeke
Martin Möhrmann
alex-semenyuk
Ruixin(Peter) Bao
sjnam
Giovanni Bajo
Diogo Pinela
TennyZhuang
Brad Fitzpatrick
Keith Randall
Brian Kessler
Dmitry Vyukov
Shenghou Ma
smasher164
Meng Zhuo
Keith Randall
Ainar Garipov
K. "pestophagous" Heller
Ben Shi