We used to warn for calls to print(), because it doesn't do anything.
However, a Go 1.18 test uses that call, and it is valid Go. Change
the compiler to just accept it and compile it; this will produce calls
to printlock and printunlock, and nothing else.
Change-Id: I11710ae38478d1860cf8e2708bec8b0f7e1b8373
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/384355
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
We used to pointlessly set the pointer of a zero length string
constant to point to a zero byte constant. Instead, just use nil.
Change-Id: I73fb28dcfcf547565dcab4ec26412f6e6e7ca951
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/384354
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
By definition, a type is marked notinheap doesn't contain any pointers
that the garbage collector cares about, and neither does a pointer to
such a type. Change the type descriptors to consistently treat such
types as not being pointers, by setting ptrdata to 0 and gcdata to nil.
Change-Id: Id8466555ec493456ff5ff09f1670551414619bd2
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/384118
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The Go 1.18 library introduces specific types in runtime/internal/atomic.
Recognize and optimize the methods on those types, as we do with the
functions in runtime/internal/atomic.
While we're here avoid getting confused by methods in any other
package that we recognize specially.
Change-Id: I75c31f75dcf65ce13f3c69022e8ec36e05eab994
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/383654
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The Go 1.18 standard library uses an internal/abi package with two
functions that are implemented in the compiler. This patch implements
them in the gofrontend, to support the upcoming update to 1.18.
Change-Id: I645f0c65ccf18646b212f23add94a618843bff7c
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/383514
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Adding type parameters was about to add a partial third version.
Remove the duplication to avoid that.
Change-Id: I0f9ca818c9ff030520690c085d9651681b2dae32
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/375234
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Change the compiler to not add zero padding because of zero-sized
fields named "_", since those can't be referenced anyhow.
Change the sparc-linux64 epollevent struct to name the alignment
field "_", to avoid zero padding.
Fixes https://gcc.gnu.org/PR103847
Change-Id: I591b3b798a24141e3d0e1ccf6ff0f7f0570af9d4
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/374914
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Fix the Create_func_descriptors pass to traverse the subexpressions of
the function in a Call_expression. There are no subexpressions in the
normal case of calling a function a method directly, but there are
subexpressions when in code like F().M() when F returns an interface type.
Forgetting to traverse the function subexpressions was almost entirely
hidden by the fact that we also created the necessary thunks in
Bound_method_expression::do_flatten and
Interface_field_reference_expression::do_get_backend. However, when
the thunks were created there, they did not go through the
order_evaluations pass. This almost always worked, but failed in the
case in which the function being thunked returned multiple results, as
order_evaluations takes the necessary step of moving the
Call_expression into its own statement, and that would not happen when
order_evaluations was not called. Avoid hiding errors like this by
changing those methods to only lookup the previously created thunk,
rather than creating it if it was not already created.
The test case for this is https://golang.org/cl/363156.
Fixesgolang/go#49512
Change-Id: I6b273156f16ed6ed22e600097628a1cb6499de64
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/363274
Trust: Ian Lance Taylor <iant@golang.org>
Trust: Benny Siegert <bsiegert@gmail.com>
Reviewed-by: Than McIntosh <thanm@google.com>
The original compiler directive support was only for //line at the
start of a line and for //go: comments before function declarations.
When support was added for //go:notinheap for types and //go:embed for
variables the code did not adapt to permit spaces before the comment
or to permit the comments in var() or type() groups. This change
corrects those omissions.
Change-Id: I0d533a7f13d33115dca1eab842a24f6f294df09d
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/358699
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Tweak a couple of places in the types code to use nullptr instead of
NULL to work around a template matching quirk when using certain build
compilers.
Change-Id: Ia349c998a7dd90b4c2df589c7ceeaedcee6cde01
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/354151
Trust: Than McIntosh <thanm@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This is a minor cleanup to ensure that the various Expression::do_type
methods don't have to worry about the possibility that the Expression
has not been lowered.
Change-Id: I4c255b6b126617931ff961f0f7fd4691a9828d67
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/353140
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
In Go 1.17 the gc toolchain changed to set runtime.GOROOT in cmd/link
(previously it was runtime/internal/sys.GOROOT). Do the same in libgo.
Change-Id: Ia684a17fbb8f436d05afbcce14fc63fd16353be2
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/351313
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
When compiling append(s, make([]typ, ln)...), where typ has a pointer,
and the append fits within the existing capacity of s, the condition
used to clear out the new elements was reversed.
Fixesgolang/go#47771
Change-Id: Ia880adc08ab723afe3f927e65c9e081f9f717f90
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/344189
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Change-Id: I8cac79c01f3086294c40bfe5568ca13b3c4558da
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/343729
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Didn't notice earlier because this code is only used on systems that
do not support -fsplit-stack.
Change-Id: I101f91b67a09526867c940fe33a0778d0f7f6be4
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/342051
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Following the previous CL, in the escape analysis list all the
expected runtime calls, and fail if an unexpected one is seen.
Change-Id: I2847141c7bebb4b3daee930d862cb3cf5b83db60
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/340397
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
In the places where we handle builtin functions, list all
supported ones, and fail if an unexpected one is seen. So if a
new builtin function is added in the future we can detect it,
instead of silently treating it as nonescaping.
Change-Id: Ia5efc4a51edf677c5c619ff5894bb5374d021763
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/339992
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Previous CLs add new language constructs in Go 1.17, specifically,
unsafe.Add, unsafe.Slice, and conversion from a slice to a pointer
to an array. This CL handles them in the escape analysis.
At the point of the escape analysis, unsafe.Add and unsafe.Slice
are still builtin calls, so just handle them in data flow.
Conversion from a slice to a pointer to an array has already been
lowered to a combination of compound expression, conditional
expression and slice info expressions, so handle them in the
escape analysis.
Change-Id: Iccac4f0135f2bd6081ca93707db1c7b608350052
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/339671
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The only different between selectnbrecv and selectnbrecv2 is the later
set the input pointer value by second return value from chanrecv.
So by making selectnbrecv return two values from chanrecv, we can get
rid of selectnbrecv2, the compiler can now call only selectnbrecv and
generate simpler code.
This is the gofrontend version of https://golang.org/cl/292890.
Change-Id: Ied87c4ab6c36e48669aeba22cbbb80a34d99d3d7
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/339529
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
When checking a slice to pointer-to-array conversion, I forgot to
verify that the elements types are identical.
For golang/go#395
Change-Id: I533ac52c0b390af96fce78a8c468ae9d8ad79da9
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/339329
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
If a package declares a method on an alias type, the alias would be
used in the export data. This would then trigger a compiler
assertion on import: we should not be adding methods to aliases.
Fix the problem by ensuring that receiver types do not use alias types.
This seems preferable to consistently avoiding aliases in export data,
as aliases can cross packages. And it's painful to try to patch this
while writing the export data, as at that point all the types are known.
Test case is https://golang.org/cl/335172.
Fixesgolang/go#47131
Change-Id: Ic1fa7feddc3ff19c22c5c112bc06236b8c9d010a
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/335729
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
They cause a warning with the updated GCC -Warray-bounds option.
Replace them with calls to abort, which for our purposes is fine.
For GCC PR bootstrap/101374
Change-Id: Ie3232c44ab5730b548b87e5fc73d78f44ce92c26
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/333409
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
We were generating temporaries for composite literals when a
conversion to interface type was required. However, Cherry's
https://golang.org/cl/176459 changed the compiler to insert explicit
type conversions. And those explicit type conversions insert the
required temporaries in Type_conversion_expression::do_flatten.
So in practice the composite literal do_flatten methods would never
insert temporaries, as the values they see would always be multi_eval_safe.
So just remove the unnecessary do_flatten methods.
Change-Id: I66975b7ddc763f0cf93a6b56efede10bca3d3765
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/331691
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
For a composite literal we only need to introduce a temporary variable
if we may be converting to an interface type, so only do it then.
This saves over 80% of compilation time when using gccgo to compile
cmd/internal/obj/x86, as the GCC middle-end spends a lot of time
pointlessly computing interactions between temporary variables.
For golang/go#46600
Change-Id: I6f01a3c84762b9d06268c5304af6ffce14a0a031
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/331513
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
To implement this, change the backend to use flag bits for variables.
Fixes https://gcc.gnu.org/PR100537
Change-Id: I19d803ec3d13003361ea7331cc04297294ec0b8a
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/322129
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The compiler generally doesn't create a temporary for an expression
that is a variable, because it's normally valid to simply reload the
value from the variable. However, if the variable is in the heap,
then loading the value is a pointer indirection. The process of
creating GCC IR can cause the variable load and the pointer
indirection to be split, such that the second evaluation only does the
pointer indirection. If there are conditionals in between the two
uses, this can cause the second use to load the pointer from an
uninitialized register.
Avoid this by introducing a new Expression method that returns whether
it is safe to evaluate an expression multiple times, and use it
everywhere.
The test case is https://golang.org/cl/300789.
Fixesgolang/go#44383
Change-Id: Ice2a18153457daa024ddbf0a9935f7863fe6818e
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/300809
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Ian Lance Taylor
Than McIntosh
Cherry Mui
Avelino