+FAIL: libgomp.c/target-39.c (internal compiler error)
+FAIL: libgomp.c/target-39.c (test for excess errors)
+UNRESOLVED: libgomp.c/target-39.c compilation failed to produce executable
This is in a '--enable-offload-targets=[...],hsa' build, with '-foffload=hsa'
enabled (by default).
during GIMPLE pass: hsagen
source-gcc/libgomp/testsuite/libgomp.c/target-39.c: In function ‘main._omp_fn.0.hsa.0’:
source-gcc/libgomp/testsuite/libgomp.c/target-39.c:23:11: internal compiler error: Segmentation fault
23 | #pragma omp target map(from:err)
| ^~~
[...]
GDB:
Program received signal SIGSEGV, Segmentation fault.
fndecl_built_in_p (node=0x0, name=BUILT_IN_PREFETCH) at [...]/source-gcc/gcc/tree.h:6267
6267 return (fndecl_built_in_p (node, BUILT_IN_NORMAL)
(gdb) bt
#0 fndecl_built_in_p (node=0x0, name=BUILT_IN_PREFETCH) at [...]/source-gcc/gcc/tree.h:6267
#1 0x0000000000b19739 in gen_hsa_insns_for_call (stmt=stmt@entry=0x7ffff693b200, hbb=hbb@entry=0x2b152c0) at [...]/source-gcc/gcc/hsa-gen.c:5304
#2 0x0000000000b1aca7 in gen_hsa_insns_for_gimple_stmt (stmt=0x7ffff693b200, hbb=hbb@entry=0x2b152c0) at [...]/source-gcc/gcc/hsa-gen.c:5770
#3 0x0000000000b1bd21 in gen_body_from_gimple () at [...]/source-gcc/gcc/hsa-gen.c:5999
#4 0x0000000000b1dbd2 in generate_hsa (kernel=<optimized out>) at [...]/source-gcc/gcc/hsa-gen.c:6596
#5 0x0000000000b1de66 in (anonymous namespace)::pass_gen_hsail::execute (this=0x2a2aac0) at [...]/source-gcc/gcc/hsa-gen.c:6680
#6 0x0000000000d06f90 in execute_one_pass (pass=pass@entry=0x2a2aac0) at [...]/source-gcc/gcc/passes.c:2502
[...]
(gdb) up
#1 0x0000000000b19739 in gen_hsa_insns_for_call (stmt=stmt@entry=0x7ffff693b200, hbb=hbb@entry=0x2b152c0) at /home/thomas/tmp/source/gcc/build/track-slim-omp/source-gcc/gcc/hsa-gen.c:5304
5304 if (fndecl_built_in_p (function_decl, BUILT_IN_PREFETCH))
(gdb) print function_decl
$1 = (tree) 0x0
(gdb) list
5299 if (!gimple_call_builtin_p (stmt, BUILT_IN_NORMAL))
5300 {
5301 tree function_decl = gimple_call_fndecl (stmt);
5302 /* Prefetch pass can create type-mismatching prefetch builtin calls which
5303 fail the gimple_call_builtin_p test above. Handle them here. */
5304 if (fndecl_built_in_p (function_decl, BUILT_IN_PREFETCH))
5305 return;
5306
5307 if (function_decl == NULL_TREE)
5308 {
The problem is present already since 2016-11-23 commit 56b1c60e412fcf1245b4780871553cbdebb956a3 (r242761) "Merge from HSA branch to
trunk", and the fix obvious enough.
Harald Anlauf [Thu, 11 Jun 2020 13:48:56 +0000 (15:48 +0200)]
PR fortran/95503 - Fix ICE in gfc_is_simply_contiguous, at fortran/expr.c:5844
The check for assigning a pointer that cannot be determined to be simply
contiguous at compile time to a contiguous pointer does not need to be
invoked if the lhs of the assignment is known to have conflicting attributes.
2020-06-11 Harald Anlauf <anlauf@gmx.de>
gcc/fortran/
PR fortran/95503
* expr.c (gfc_check_pointer_assign): Skip contiguity check of rhs
of pointer assignment if lhs cannot be simply contiguous.
gcc/testsuite/
PR fortran/95503
* gfortran.dg/pr95503.f90: New test.
Thomas Koenig [Sun, 14 Jun 2020 11:50:48 +0000 (13:50 +0200)]
When avoiding double deallocation, look at namespace, expression and component.
Our finalization handling is a mess. Really, we should get to try and get
this fixed for gcc 11.
In the meantime, here is a patch which fixes a regression I introduced
when fixing a regression with a memory leak. The important thing
here is to realize that we do not need to finalize (and deallocate)
multiple times for the same expression and the same component
in the same namespace. It might cause code size regressions, but
better big code than wrong code...
PR fortran/94109
* class.c (finalize_component): Return early if finalization has
already happened for expression and component within namespace.
* gfortran.h (gfc_was_finalized): New type.
(gfc_namespace): Add member was_finalzed.
(gfc_expr): Remove finalized.
* symbol.c (gfc_free_namespace): Free was_finalized.
Marek Polacek [Thu, 11 Jun 2020 22:38:00 +0000 (18:38 -0400)]
c++: Fix bogus -Wparentheses warning [PR95344]
Since r267272, which added location wrappers, cp_fold loses
TREE_NO_WARNING on a MODIFY_EXPR that finish_parenthesized_expr set, and
that results in a bogus -Wparentheses warning.
I.e., previously we had "b = 1" but now we have "VIEW_CONVERT_EXPR<bool>(b) = 1"
and cp_fold_maybe_rvalue folds away the location wrapper and so we do
2718 x = fold_build2_loc (loc, code, TREE_TYPE (x), op0, op1);
in cp_fold and the flag is lost.
PR c++/95344
* cp-gimplify.c (cp_fold) <case MODIFY_EXPR>: Don't set
TREE_THIS_VOLATILE here.
(cp_fold): Set it here along with TREE_NO_WARNING.
Marek Polacek [Thu, 11 Jun 2020 21:58:21 +0000 (17:58 -0400)]
c++: Fix ICE in check_local_shadow with enum [PR95560]
Another indication that perhaps this warning is emitted too early. We
crash because same_type_p gets a null type: we have an enumerator
without a fixed underlying type and finish_enum_value_list hasn't yet
run. So check if the type is null before calling same_type_p.
PR c++/95560
* name-lookup.c (check_local_shadow): Check if types are
non-null before calling same_type_p.
* g++.dg/warn/Wshadow-compatible-local-3.C: New test.
Harald Anlauf [Sun, 7 Jun 2020 12:47:24 +0000 (14:47 +0200)]
PR fortran/95091 - Buffer overflows with submodules and long symbols
With submodules, name mangling results in long internal symbols. This
requires adjustment of the sizes of temporaries to avoid buffer overflows.
2020-06-07 Harald Anlauf <anlauf@gmx.de>
gcc/fortran/
PR fortran/95091
* class.c (get_unique_type_string, gfc_hash_value): Enlarge
buffers, and check whether the strings returned by
get_unique_type_string() fit.
Carl Love [Wed, 29 Apr 2020 15:23:11 +0000 (10:23 -0500)]
pr94833, fix vec_first_match_index for nulls
Backported patch from mainline. Updated ChangeLog format
commit 24f68831d25bad739a6fe167a58b5b4c0c3cbf9a
Author: Carl Love <cel@us.ibm.com>
Date: Wed Apr 29 10:23:11 2020 -0500
Harald Anlauf [Sat, 30 May 2020 18:59:41 +0000 (20:59 +0200)]
PR fortran/95373 - ICE in build_reference_type, at tree.c:7942
The use of KIND, LEN, RE, and IM inquiry references for applicable intrinsic
types is valid only for suffienctly new Fortran standards. Add appropriate
checks in the appropriate place.
2020-05-30 Harald Anlauf <anlauf@gmx.de>
gcc/fortran/
PR fortran/95373
* primary.c (is_inquiry_ref): Move validity check of inquiry
references against selected Fortran standard from here...
(gfc_match_varspec) ...to here.
Harald Anlauf [Thu, 28 May 2020 20:28:08 +0000 (22:28 +0200)]
PR fortran/95373 - ICE in build_reference_type, at tree.c:7942
The use of KIND, LEN, RE, and IM inquiry references for applicable intrinsic
types is valid only for suffienctly new Fortran standards. Add appropriate
check.
2020-05-28 Harald Anlauf <anlauf@gmx.de>
gcc/fortran/
PR fortran/95373
* primary.c (is_inquiry_ref): Check validity of inquiry
references against selected Fortran standard.
gcc/testsuite/
PR fortran/95373
* gfortran.dg/pr95373_1.f90: New test.
* gfortran.dg/pr95373_2.f90: New test.
Harald Anlauf [Sun, 24 May 2020 19:35:04 +0000 (21:35 +0200)]
PR fortran/95106 - truncation of long symbol names with EQUIVALENCE
For long module names, the generated name-mangled symbol was
truncated, leading to bogus warnings about COMMON block
mismatches. Provide sufficiently large temporaries.
gcc/fortran/
2020-05-24 Harald Anlauf <anlauf@gmx.de>
PR fortran/95106
* trans-common.c (gfc_sym_mangled_common_id): Enlarge temporaries
for name-mangling.
gcc/testsuite/
2020-05-24 Harald Anlauf <anlauf@gmx.de>
PR fortran/95106
* gfortran.dg/equiv_11.f90: New test.
Harald Anlauf [Fri, 5 Jun 2020 18:30:34 +0000 (20:30 +0200)]
PR fortran/95530, PR fortran/95537 - Buffer overflows with long symbols
The testcases for PR95090 and PR95106 trigger buffer overflows with long
symbols that were found with an instrumented compiler. Enlarge the
affected buffers, and add checks that the buffers will suffice.
Thomas Schwinge [Wed, 6 May 2020 08:05:49 +0000 (10:05 +0200)]
'libgomp.oacc-fortran/{error_,}stop-{1,2,3}.f': initialize before the checkpoint
If, for example, GCC is configured such that 'libgomp-plugin-nvptx.so.1'
dynamically links against 'libcuda.so.1', but testing is run on a system where
there is no 'libcuda.so.1', this produces output such as:
PASS: libgomp.oacc-fortran/error_stop-1.f -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -O0 (test for excess errors)
PASS: libgomp.oacc-fortran/error_stop-1.f -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -O0 execution test
FAIL: libgomp.oacc-fortran/error_stop-1.f -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -O0 output pattern test, is CheCKpOInT
libgomp: while loading libgomp-plugin-nvptx.so.1: libcuda.so.1: cannot open shared object file: No such file or directory
ERROR STOP
Error termination. Backtrace: [...]
, should match CheCKpOInT(
|
|^M)+ERROR STOP (
|
|^M)+Error termination.*
..., where after 'CheCKpOInT' we got 'libgomp: while loading [...]' injected
before the expected 'ERROR STOP'.
This fixes PR94591. The problem was the function
aarch64_evpc_rev_local() matching vector permutations that were not
reversals. In particular, prior to this patch, this function matched the
identity permutation which led to generating bogus REV64 insns which
were rejected by the assembler.
gcc/
PR target/94591
* config/aarch64/aarch64.c (aarch64_evpc_rev_local): Don't match
identity permutation.
gcc/testsuite/
PR target/94591
* gcc.c-torture/execute/pr94591.c: New test.
Kyrylo Tkachov [Wed, 6 May 2020 15:20:38 +0000 (16:20 +0100)]
[AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc
This version of the fix uses __getauxval instead of getauxval.
The whole thing is guarded simply on __gnu_linux__.
__getauxval was introduced in 2.16 but the aarch64 port was added in 2.17 so in practice I expect all aarch64 glibcs to support __getauxval.
Bootstrapped and tested on aarch64-none-linux-gnu.
Also tested on aarch64-none-elf.
Martin Liska [Fri, 29 May 2020 09:29:25 +0000 (11:29 +0200)]
Fix various limitations of git-backport.py.
I've just tested the script and I'm going to install the patch
to all active branches.
contrib/ChangeLog:
* git-backport.py: The script did 'git co HEAD~' when
there was no modified ChangeLog file in a successful
git cherry pick.
Run cherry-pick --continue without editor.
Based on a patch in the comments of the PR. That patch fixed this
problem but caused the test cases for PR93484 to fail. It has been
changed to reduce initialisation expressions if the expression is
not EXPR_VARIABLE and not EXPR_CONSTANT.
2020-05-28 Steven G. Kargl <kargl@gcc.gnu.org>
Mark Eggleston <markeggleston@gcc.gnu.org>
gcc/fortran/
PR fortran/94397
* match.c (gfc_match_type_spec): New variable ok initialised
to true. Set ok with the return value of gfc_reduce_init_expr
called only if the expression is not EXPR_CONSTANT and is not
EXPR_VARIABLE. Add !ok to the check for type not being integer
or the rank being greater than zero.
2020-05-28 Mark Eggleston <markeggleston@gcc.gnu.org>
gcc/testsuite/
PR fortran/94397
* gfortran.dg/pr94397.F90: New test.
Mark Eggleston [Thu, 7 May 2020 07:15:26 +0000 (08:15 +0100)]
Fortran : ICE in gfc_trans_label_assign PR50392
A function may contain an assigned goto. If the the return variable
is an integer a statement can be assigned to it. Prior to this fix
this resulted in an ICE.
PR fortran/50392
* trans-decl.c (gfc_get_symbol_decl): Remove unnecessary block
delimiters. Add auxiliary variables if a label is assigned to
a return variable. (gfc_gat_fake_result): If the symbol has an
assign attribute set declaration from the symbol's backend
declaration.
2020-05-28 Mark Eggleston <markeggleston@gnu.gcc.org>
gcc/testsuite/
PR fortran/50392
* gfortran.dg/pr50392.f: New test.
PR libfortran/95191
* io/async.c (async_wait_id): Generate error if ID is higher
than the highest current ID.
* runtime/error.c (translate_error): Handle LIBERROR_BAD_WAIT_ID.
libgomp/ChangeLog:
2020-05-23 Thomas Koenig <tkoenig@gcc.gnu.org>
PR libfortran/95191
* testsuite/libgomp.fortran/async_io_9.f90: New test.
Alexandre Oliva [Tue, 26 May 2020 14:28:42 +0000 (11:28 -0300)]
[rs6000] fix mffsl emulation
The emulation of mffsl with mffs, used when !TARGET_P9_MISC, is going
through the motions, but not storing the result in the given
operands[0]; it rather modifies operands[0] without effect. It also
creates a DImode pseudo that it doesn't use, overwriting subregs
instead.
The patch below fixes all of these, the indentation and a typo.
I'm concerned about several issues in the mffsl testcase. First, I
don't see that comparing the values as doubles rather than as long
longs is desirable. These are FPSCR bitfields, not FP numbers. I
understand mffs et al use double because they output to FP registers,
and the bit patterns are subnormal FP numbers, so it works, but given
the need for bit masking of at least one side, I'm changing the
compare to long longs.
Another issue with the test is that, if the compare fails, it calls
mffsl again to print the value, as if it would yield the same result.
But part of the FPSCR that mffsl (emulated with mffs or not) copies to
the output FP register is the FPCC, so the fcmpu used to compare the
result of the first mffsl will modify FPSCR and thus the result of the
second mffsl call. After changing the compare, this is no longer the
case, but I still think it's better to make absolutely sure what we
print is what we compared.
Yet another issue is that the test assumed the mffs bits that are not
to be extracted by mffsl to be already zero, instead of masking them
out explicitly. This is not about the mffs emulation in the mffsl
implementation, but about the mffs use in the test proper. The bits
appear to be zero indeed, as the bits left out are for sticky
exceptions, but there are reserved parts of FPSCR that might turn out
to be set in the future, so we're better off masking them out
explicitly, otherwise those bits could cause the compare to fail.
If some future mffsl is changed so that it copies additional nonzero
bits, the test will fail, and then we'll have a chance to adjust it
and the emulation.
gcc/ChangeLog:
PR target/94812
* config/rs6000/rs6000.md (rs6000_mffsl): Copy result to
output operand in emulation. Don't overwrite pseudos.
gcc/testsuite/ChangeLog:
PR target/94812
* gcc.target/powerpc/test_mffsl.c: Call mffsl only once.
Reinterpret the doubles as long longs for compares. Mask out
mffs bits that are not expected from mffsl.
Jason Merrill [Mon, 25 May 2020 22:38:09 +0000 (18:38 -0400)]
c++: constexpr and lambda capture [PR90212]
This is the same issue as PR86429, just in potential_constant_expression_1
rather than cxx_eval_constant_expression. As in that case, when we're
trying to evaluate a constant expression within a lambda, we don't have a
constant closure object to refer to, but we can try to refer directly to the
captured variable.
gcc/cp/ChangeLog
2020-05-05 Jason Merrill <jason@redhat.com>
PR c++/90212
* constexpr.c (potential_constant_expression_1): In a lambda
function, consider a captured variable directly.
Jason Merrill [Mon, 25 May 2020 22:38:09 +0000 (18:38 -0400)]
c++: Local class DMI using local static [PR90479]
For default member initializers in templates it's important to push into the
right context during get_nsdmi. But for a local class that's not possible,
and trying leaves the function context we need to be in, so don't try.
gcc/cp/ChangeLog
2020-05-01 Jason Merrill <jason@redhat.com>
PR c++/90479
* init.c (get_nsdmi): Don't push_to_top_level for a local class.
Jason Merrill [Mon, 25 May 2020 22:38:09 +0000 (18:38 -0400)]
c++: -fmerge-all-constants vs. destructors [PR91529]
cp_finish_decl avoids setting TREE_READONLY on TREE_STATIC variables that
have non-constant construction or destruction, but -fmerge-all-constants was
converting an automatic variable to static while leaving TREE_READONLY set.
Fixed by clearing the flag in cp_finish_decl in the presence of
-fmerge-all-constants.
gcc/cp/ChangeLog
2020-05-01 Jason Merrill <jason@redhat.com>
PR c++/91529
* decl.c (cp_finish_decl): Also clear TREE_READONLY if
-fmerge-all-constants.
Jason Merrill [Mon, 25 May 2020 22:38:09 +0000 (18:38 -0400)]
c++: generic lambda and -fsanitize=vla-bound [PR93822]
Within the generic lambda the VLA capture proxy VAR_DECL has DECL_VALUE_EXPR
which is a NOP_EXPR to the VLA type of the proxy. The problem here was that
when instantiating we were tsubsting that type twice, once for the type of
the DECL and once for the type of the NOP_EXPR, and getting two
different (though equivalent) types. Then gimplify_type_sizes fixed up the
type of the DECL, but that didn't affect the type of the NOP_EXPR, leading
to sadness.
Fixed by directly reusing the type from the DECL.
gcc/cp/ChangeLog
2020-05-01 Jason Merrill <jason@redhat.com>
PR c++/93822
* pt.c (tsubst_decl): Make sure DECL_VALUE_EXPR continues to have
the same type as the variable.
Bin Cheng [Fri, 22 May 2020 03:42:11 +0000 (11:42 +0800)]
Add missing unit dependence vector in data dependence analysis
Current data dependence analysis misses unit distant vector if DRs in
DDR have the same invariant access functions. This adds the vector as
the constant access function case.
Also fix typo in testcase.
Backport from master.
2020-05-13 Bin Cheng <bin.cheng@linux.alibaba.com>
gcc/
PR tree-optimization/94969
* tree-data-ref.c (constant_access_functions): Rename to...
(invariant_access_functions): ...this. Add parameter. Check for
invariant access function, rather than constant.
(build_classic_dist_vector): Call above function.
* tree-loop-distribution.c (pg_add_dependence_edges): Add comment.
gcc/testsuite/
PR tree-optimization/94969
* gcc.dg/tree-ssa/pr94969.c: New test.
Mark Eggleston [Thu, 7 May 2020 07:02:02 +0000 (08:02 +0100)]
Fortran : ProcPtr function results: 'ppr@' in error message PR39695
The value 'ppr@' is set in the name of result symbol, the actual
name of the symbol is in the procedure name symbol pointed
to by the result symbol's namespace (ns). When reporting errors for
symbols that have the proc_pointer attribute check whether the
result attribute is set and set the name accordingly.
Backported from master.
2020-05-20 Mark Eggleston <markeggleston@gcc.gnu.org>
gcc/fortran/
PR fortran/39695
* resolve.c (resolve_fl_procedure): Set name depending on
whether the result attribute is set. For PROCEDURE/RESULT
conflict use the name in sym->ns->proc_name->name.
* symbol.c (gfc_add_type): Add check for function and result
attributes use sym->ns->proc_name->name if both are set.
Where the symbol cannot have a type use the name in
sym->ns->proc_name->name.
2020-05-20 Mark Eggleston <markeggleston@gcc.gnu.org>
gcc/testsuite/
PR fortran/39695
* gfortran.dg/pr39695_1.f90: New test.
* gfortran.dg/pr39695_2.f90: New test.
* gfortran.dg/pr39695_3.f90: New test.
* gfortran.dg/pr39695_4.f90: New test.
Douglas Rupp [Mon, 18 May 2020 18:43:48 +0000 (11:43 -0700)]
Require powerpc_vsx_ok in gcc.target/powerpc/pr71763.c
We're getting an error when running this test on PowerPC VxWorks 7,
due to an unexpected warning:
| Excess errors:
| cc1: warning: '-mvsx' and '-mno-altivec' are incompatible
The warning comes from a combination of factors:
- The test itself uses -mvsx explicitly via the following directive:
// { dg-options "-O1 -mvsx" }
- Our toolchain was configured so as to make -mno-altivec
the default;
- These two options are mutually exclusive.
This commit adds a powerpc_vsx_ok dg-require-effective-target directive
to that test, and thus making it UNSUPPORTED instead.
Tested on PowerPC VxWorks 7. Also tested on PowerPC ELF as well,
a platform where we do not make -mno-altivec the default, to verify
that the test continues to run as usual in that case.
Iain Buclaw [Sun, 17 May 2020 14:28:24 +0000 (16:28 +0200)]
d: Fix ICE in verify_gimple_stmt, at tree-cfg.c:4959
Both array concat and array new expressions wrapped any temporaries
created into a BIND_EXPR. This does not work if an expression used to
construct the result requires scope destruction, which is represented by
a TARGET_EXPR with a clean-up, and a CLEANUP_POINT_EXPR at the
location where the temporaries logically go out of scope. The reason
for this not working is because the lowering of cleanup point
expressions does not traverse inside BIND_EXPRs to expand any gimple
cleanup expressions within.
The use of creating BIND_EXPR has been removed at both locations, and
replaced with a normal temporary variable that has initialization
delayed until its address is taken.
gcc/d/ChangeLog:
PR d/94970
* d-codegen.cc (force_target_expr): Move create_temporary_var
implementation inline here.
(create_temporary_var): Remove.
(maybe_temporary_var): Remove.
(bind_expr): Remove.
* d-convert.cc (d_array_convert): Use build_local_temp to generate
temporaries, and generate its assignment.
* d-tree.h (create_temporary_var): Remove.
(maybe_temporary_var): Remove.
(d_array_convert): Remove vars argument.
* expr.cc (ExprVisitor::visit (CatExp *)): Use build_local_temp to
generate temporaries, don't wrap them in a BIND_EXPR.
(ExprVisitor::visit (NewExp *)): Likewise.
Iain Buclaw [Sat, 16 May 2020 21:33:15 +0000 (23:33 +0200)]
d: Fix wrong vtable offset in virtual function call
The Semantic (pass 1) analysis for classes is handled by
ClassDeclaration::semantic. For a given class, this method may be ran
multiple times in order to resolve forward references. The method
incrementally tries to resolve the types referred to by the members of
the class.
The subsequent calls to this method are short-circuited if the class
members have been fully analyzed. For this the code tests that it is
not the first/main call to the method (semanticRun == PASS.init else
branch), scx is not set, and that the this->symtab is already set. If
all these conditions are met, the method returns. But before returning,
the method was setting this->semanticRun to PASSsemanticdone. It should
not set semanticRun since the class has not been fully analyzed yet.
The base class analysis for this class could be pending and as a result
vtable may not have been fully created.
This fake setting of semanticRun results in the semantic analyzer to
believe that the class has been fully analyzed. As exposed by the
issues in upstream, it may result in compile time errors when a derived
type class is getting analyzed and because of this fake semanticdone on
the base class, the semantic analysis construes that an overriden method
is not defined in the base class. PR95155 exposes anoter scenario where
a buggy vtable may be created and a call to a class method may result in
execution of some adhoc code.
gcc/d/ChangeLog:
PR d/95155
* dmd/dclass.c (ClassDeclaration::semantic): Don't prematurely
set done on semantic analysis.
gcc/testsuite/ChangeLog:
PR d/95155
* gdc.test/compilable/imports/pr9471a.d: New test.
* gdc.test/compilable/imports/pr9471b.d: New test.
* gdc.test/compilable/imports/pr9471c.d: New test.
* gdc.test/compilable/imports/pr9471d.d: New test.
* gdc.test/compilable/pr9471.d: New test.
Szabolcs Nagy [Fri, 24 Apr 2020 16:36:02 +0000 (17:36 +0100)]
aarch64: don't emit bti j after NOTE_INSN_DELETED_LABEL [PR94748]
It was previously discussed that indirect branches cannot go to
NOTE_INSN_DELETED_LABEL so inserting a landing pad is unnecessary.
See https://gcc.gnu.org/pipermail/gcc-patches/2019-May/522625.html
Before the patch a bti j was inserted after the label in
__attribute__((target("branch-protection=bti")))
int foo (void)
{
label:
return 0;
}
This is not necessary and weakens the security protection.
gcc/ChangeLog:
Backport from mainline.
2020-04-30 Szabolcs Nagy <szabolcs.nagy@arm.com>
PR target/94748
* config/aarch64/aarch64-bti-insert.c (rest_of_insert_bti): Remove
the check for NOTE_INSN_DELETED_LABEL.
gcc/testsuite/ChangeLog:
Backport from mainline.
2020-04-30 Szabolcs Nagy <szabolcs.nagy@arm.com>
PR target/94748
* gcc.target/aarch64/pr94748.c: New test.
Szabolcs Nagy [Fri, 17 Apr 2020 15:54:12 +0000 (16:54 +0100)]
aarch64: ensure bti c is emitted at function start [PR94697]
The bti pass currently first emits bti c at function start
if there is no paciasp (which also acts as indirect call
landing pad), then bti j is emitted at jump labels, however
if there is a label right before paciasp then the function
start can end up like
foo:
label:
bti j
paciasp
...
This patch is a minimal fix that just moves the bti c handling
after the bti j handling so we end up with
foo:
bti c
label:
bti j
paciasp
...
This could be improved by emitting bti jc in this case, or by
detecting that the label is not in fact an indirect jump target
and then this situation would be much less common.
Needs to be backported to gcc-9 branch.
Backported without the testcase because of missing infrastructure
for check-function-bodies.
gcc/ChangeLog:
Backport from mainline.
2020-04-23 Szabolcs Nagy <szabolcs.nagy@arm.com>
PR target/94697
* config/aarch64/aarch64-bti-insert.c (rest_of_insert_bti): Swap
bti c and bti j handling.
Szabolcs Nagy [Mon, 27 Apr 2020 08:07:15 +0000 (09:07 +0100)]
aarch64: Fix .cfi_window_save with pac-ret [PR94515]
On aarch64 -mbranch-protection=pac-ret reuses the dwarf
opcode for window_save to mean "toggle the return address
mangle state", but in the dwarf2cfi internal logic the
state was not updated when an opcode was emitted, the
currently present update logic is only valid for the
original sparc use of window_save so a separate bool is
used on aarch64 to track the state.
This bug can cause the unwinder not to authenticate return
addresses that were signed (or vice versa) which means a
runtime crash on a pauth enabled system.
Currently only aarch64 pac-ret uses REG_CFA_TOGGLE_RA_MANGLE.
This should be backported to gcc-9 and gcc-8 branches.
gcc/ChangeLog:
Backport from mainline.
2020-04-27 Szabolcs Nagy <szabolcs.nagy@arm.com>
PR target/94515
* dwarf2cfi.c (struct GTY): Add ra_mangled.
(cfi_row_equal_p): Check ra_mangled.
(dwarf2out_frame_debug_cfa_window_save): Remove the argument,
this only handles the sparc logic now.
(dwarf2out_frame_debug_cfa_toggle_ra_mangle): New function for
the aarch64 specific logic.
(dwarf2out_frame_debug): Update to use the new subroutines.
(change_cfi_row): Check ra_mangled.
gcc/testsuite/ChangeLog:
Backport from mainline.
2020-04-27 Szabolcs Nagy <szabolcs.nagy@arm.com>
PR target/94515
* g++.target/aarch64/pr94515-1.C: New test.
* g++.target/aarch64/pr94515-2.C: New test.
Szabolcs Nagy [Fri, 3 Apr 2020 09:35:41 +0000 (09:35 +0000)]
aarch64, libgcc: Fix unwinding from pac-ret to normal frames [PR94514]
With -mbranch-protection=pac-ret the debug info toggles the
signedness state of the return address so the unwinder knows when
the return address needs pointer authentication.
The unwind context flags were not updated according to the dwarf
frame info.
This causes unwinding across frames that were built without pac-ret
to incorrectly authenticate the return address wich corrupts the
return address on a system where PAuth is enabled.
Note: This even affects systems where all code use pac-ret because
unwinding across a signal frame the return address is not signed.
gcc/testsuite/ChangeLog:
Backport from mainline.
2020-04-23 Szabolcs Nagy <szabolcs.nagy@arm.com>
Mark Eggleston [Thu, 7 May 2020 07:29:14 +0000 (08:29 +0100)]
Fortran : ICE in gfc_conv_array_constructor_expr PR93497
Invalid expressions, such as those involving array constructors,
used for the length of character types will cause an ICE.
2020-05-11 Mark Eggleston <markeggleston@gcc.gnu.org>
Backported from master
2020-05-13 Steven G. Kargl <kargl@gcc.gnu.org>
gcc/fortran/
PR fortran/93497
* decl.c (char_len_param_value): Check whether character
length expression is of type EXPR_OP and if so simplify it.
* resolve.c (resolve_charlen): Reject length if it has a
rank.
2020-05-11 Mark Eggleston <markeggleston@gcc.gnu.org>
Backported from master
2020-05-13 Mark Eggleston <markeggleston@gcc.gnu.org>
gcc/testsuite/
PR fortran/93497
* gfortran.dg/pr88025.f90: Change in wording of error.
* gfortran.dg/pr93497.f90: New test.
* gfortran.dg/pr93714_1.f90: Change in wording of errors.
* gfortran.dg/pr93714_2.f90: Change in wording of errors.
David Edelsohn [Tue, 12 May 2020 15:46:47 +0000 (11:46 -0400)]
rs6000: AIX long double builtins for 64 bit long double.
When long doubles are 64 bit, the AIX C library overrides the definitions
but GCC builtins point to 128 bit names. This patch overrides the
builtins for fmodl, frexpl, ldexpl and modfl to refer to the 64 bit symbols.
Backport from mainline
2020-05-04 Clement Chigot <clement.chigot@atos.net>
David Edelsohn <dje.gcc@gmail.com>
* config/rs6000/rs6000-call.c (rs6000_init_builtins): Override explicit
for fmodl, frexpl, ldexpl and modfl builtins.
projects / thirdparty / gcc.git / log
