Age | Commit message (Collapse) | Author | Files | Lines |
|
In the Go 1.21 release the package internal/profile imports
internal/lazyregexp. That works when bootstrapping with Go 1.17,
because that compiler has internal/lazyregep and permits importing it.
We also have internal/lazyregexp in libgo, but since it is not installed
it is not available for importing. This CL adds internal/lazyregexp
to the list of internal packages that are installed for bootstrapping.
The Go 1.21, and earlier, releases have a couple of functions in
the internal/abi package that are always fully intrinsified.
The gofrontend recognizes and intrinsifies those functions as well.
However, the gofrontend was also building function descriptors
for references to the functions without calling them, which
failed because there was nothing to refer to. That is OK for the
gc compiler, which guarantees that the functions are only called,
not referenced. This CL arranges to not generate function descriptors
for these functions.
For golang/go#60913
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/504798
|
|
This fixes an accidental omission in the determine types pass.
Test case is https://go.dev/cl/505015.
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/504797
|
|
In https://go.dev/cl/343873 we stopped padding zero-sized trailing
fields in functions that return multiple results where the last result
is zero-sized. This CL makes the corresponding change on the caller side.
The test case is https://go.dev/cl/479898.
Fixes golang/go#55242
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/479955
|
|
This avoids clang warnings:
gcc/go/gofrontend/escape.cc:1290:17: warning: private field 'fn_' is not used [-Wunused-private-field]
gcc/go/gofrontend/escape.cc:3478:19: warning: private field 'context_' is not used [-Wunused-private-field]
gcc/go/gofrontend/lex.h:564:15: warning: private field 'input_file_name_' is not used [-Wunused-private-field]
gcc/go/gofrontend/types.cc:5788:20: warning: private field 'call_' is not used [-Wunused-private-field]
gcc/go/gofrontend/wb.cc:206:9: warning: private field 'gogo_' is not used [-Wunused-private-field]
Path by Martin Liška.
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/458975
|
|
The compiler neglected to notice that a conversion from a string
constant to a string type was a valid string constant.
No test case because this only caused a compiler failure when compiling
without optimization, which is not the normal case, and is not a case
that we test.
Fixes golang/go#56113
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/441555
|
|
Tighten up the argument type checking for Builtin_call_expression to
catch erroneous cases such as
panic(panic("bad")))
where an argument void type is being passed to panic/alignof/sizeof.
Fixes golang/go#56071.
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/439815
|
|
Fixes golang/go#53639
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/415936
|
|
Test case is const8.go in https://go.dev/cl/414795.
Fixes golang/go#53585
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/414914
|
|
Test case is https://go.dev/cl/414755.
Fixes golang/go#51475
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/414735
|
|
Also fix a couple of cases where the error led to a later compiler crash.
Test case is https://go.dev/cl/414336.
Fixes golang/go#52871
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/414354
|
|
Test case is https://go.dev/cl/413980.
Fixes golang/go#52862
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/413981
|
|
As of CL 77510 it is never true.
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/394695
|
|
For golang/go#35945
Fixes golang/go#28104
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/403954
|
|
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.
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/384355
|
|
We used to pointlessly set the pointer of a zero length string
constant to point to a zero byte constant. Instead, just use nil.
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/384354
|
|
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.
* go-gcc.cc (Gcc_backend::Gcc_backend): Define builtins
__atomic_load_1 and __atomic_store_1.
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/383654
|
|
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.
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/383514
|
|
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.
Fixes https://golang.org/issue/49512
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/363274
|
|
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.
Fixes golang/go#47771
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/344189
|
|
This is the gofrontend version of https://golang.org/cl/264480.
For golang/go#42076
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/340609
|
|
Fixes PR go/101851
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/341330
|
|
For golang/go#19367
For golang/go#40481
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/340549
|
|
This is the gofrontend version of https://golang.org/cl/289152.
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/339690
|
|
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.
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/339671
|
|
When checking a slice to pointer-to-array conversion, I forgot to
verify that the elements types are identical.
For golang/go#395
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/339329
|
|
Panic if the slice is too short.
For golang/go#395
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/338630
|
|
For golang/go#19367
For golang/go#40481
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/338949
|
|
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.
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/331691
|
|
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 PR debug/101064
For golang/go#46600
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/331513
|
|
To implement this, change the backend to use flag bits for variables.
Fixes https://gcc.gnu.org/PR100537
PR go/100537
* go-gcc.cc (class Gcc_backend): Update methods that create
variables to take a flags parameter.
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/322129
|
|
Test case is https://golang.org/cl/302371.
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/302270
|
|
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.
Fixes golang/go#44383
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/300809
|
|
The compiler was treating indirections through pointers that had been
explicitly checked against nil and slice and string index expressions
as non-trapping memory references. That is true for ordinary Go
programs, but it isn't true if the programs construct their own memory
addresses. In particular it isn't true for the kinds of programs that
want to use runtime.SetPanicOnFault.
The effect of this will be slightly larger binaries, due to additional
exception information, and perhaps slightly less optimization.
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/279960
|
|
The test case for this is issue11614.go.
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/278192
|
|
Also check for valid array length when reducing len/cap to a constant.
For golang/go#8183
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/275654
|
|
To make this work from the do_type method, add "byte" and "rune" to
the list of known integer types, and look them up that way rather than
via gogo->lookup_global.
For golang/go#8745
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/275653
|
|
Otherwise cases like
type mybool bool
var b mybool = [10]string{} == [10]string{}
get an incorrect type checking error.
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/274446
|
|
Go used to use slightly different semantics than C99 for complex division,
so we used runtime routines to handle the different. The gc compiler
has changes its behavior to match C99, so changes ours as well.
For golang/go#14644
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/274213
|
|
The overflow checks done in growslice always reported an error for the
capacity argument, even if it was the length argument that overflowed.
This change lets the code pass the current issue4085b.go test.
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/273806
|
|
For golang/go#14844
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/273889
|
|
Mark bad types as erroneous, to avoid generating further errors.
This required some code using array types to check for errors.
For https://golang.org/issue/19880
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/273626
|
|
In the conversion of a constant integer to a string type, the value of
the constant integer was being silently truncated from unsigned long
to unsigned int, producing the wrong string value. Add an explicit
overflow check to avoid this problem.
For golang/go#42790
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/272611
|
|
Overhaul the mangling scheme to avoid ambiguities if the package path
contains a dot. Instead of using dot both to separate components and
to mangle characters, use dot only to separate components and use
underscore to mangle characters.
For golang/go#41862
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/271726
|
|
Also consolidate the identical code for constant type export into a
pair of static methods.
Fixes golang/go#35739
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/262437
|
|
Previously we would finalize the methods of the alias type itself, but
since its a type alias we really need to finalize the methods of the
aliased type.
Also, handle method expressions of unnamed struct types.
Test case is https://golang.org/cl/251168.
Fixes golang/go#38125
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/251279
|
|
The test case is https://golang.org/cl/248637.
Fixes golang/go#40252
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/248638
|
|
AIX linker is not able to merge identical type descriptors in a single
symbol if there are coming from different object or shared object files.
This results into several pointers referencing the same type
descriptors.
Thus, eqtype is needed to ensure that these different symbols will be
considered as the same type descriptor.
Fixes golang/go#39276
gcc/go/ChangeLog:
* go-c.h (struct go_create_gogo_args): Add need_eqtype field.
* go-lang.c (go_langhook_init): Set need_eqtype.
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/235697
|
|
If we lower a constant string operation in a Binary_expression,
delete the strings. This is safe because constant strings are always
newly allocated.
This is a hack to use much less memory when compiling the new
time/tzdata package, which has a file that contains the sum of over
13,000 constant strings. We don't do this for numeric expressions
because that could cause us to delete an Iota_expression.
We should have a cleaner approach to memory usage some day.
Fixes PR go/96450
|
|
This ports https://golang.org/cl/227163 to the Go frontend.
This is a step toward moving up to the go1.15rc1 release.
Original CL description:
cmd/compile,runtime: pass only ptr and len to some runtime calls
Some runtime calls accept a slice, but only use ptr and len.
This change modifies most such routines to accept only ptr and len.
After this change, the only runtime calls that accept an unnecessary
cap arg are concatstrings and slicerunetostring.
Neither is particularly common, and both are complicated to modify.
Negligible compiler performance impact. Shrinks binaries a little.
There are only a few regressions; the one I investigated was
due to register allocation fluctuation.
Passes 'go test -race std cmd', modulo golang/go#38265 and golang/go#38266.
Wow, does that take a long time to run.
file before after Δ %
compile 19655024 19655152 +128 +0.001%
cover 5244840 5236648 -8192 -0.156%
dist 3662376 3658280 -4096 -0.112%
link 6680056 6675960 -4096 -0.061%
pprof 14789844 14777556 -12288 -0.083%
test2json 2824744 2820648 -4096 -0.145%
trace 11647876 11639684 -8192 -0.070%
vet 8260472 8256376 -4096 -0.050%
total 115163736 115118808 -44928 -0.039%
For golang/go#36890
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/245099
|
|
We were generating it in cases where a boolean expression was
converted directly to an empty interface type.
Fixes golang/go#40152
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/242002
|