Harald Anlauf [Wed, 24 Jun 2020 20:44:11 +0000 (22:44 +0200)]
Revert "PR fortran/95689 - ICE in check_sym_interfaces, at fortran/interface.c:2015"
With submodules, name mangling of interfaces may result in long internal
symbols overflowing an internal buffer. We now check that we do not
exceed the enlarged buffer size.
gcc/fortran/
PR fortran/95689
* interface.c (check_sym_interfaces): Enlarge temporary buffer,
and add check on length on mangled name to prevent overflow.
gcc/testsuite/
PR fortran/95689
* gfortran.dg/pr95689.f90: New test.
Jonathan Wakely [Wed, 24 Jun 2020 10:45:01 +0000 (11:45 +0100)]
libstdc++: Fix std::from_chars to ignore leading zeros in base 2
The parser for binary numbers returned an error if the entire string
contains more digits than the result type. Leading zeros should be
ignored.
libstdc++-v3/ChangeLog:
* include/std/charconv (__from_chars_binary): Ignore leading zeros.
* testsuite/20_util/from_chars/1.cc: Check "0x1" for all bases,
not just 10 and 16.
* testsuite/20_util/from_chars/3.cc: New test.
Harald Anlauf [Sat, 20 Jun 2020 14:09:45 +0000 (16:09 +0200)]
PR fortran/95689 - ICE in check_sym_interfaces, at fortran/interface.c:2015
With submodules, name mangling of interfaces may result in long internal
symbols overflowing an internal buffer. We now check that we do not
exceed the enlarged buffer size.
gcc/fortran/
PR fortran/95689
* interface.c (check_sym_interfaces): Enlarge temporary buffer,
and add check on length on mangled name to prevent overflow.
Harald Anlauf [Sat, 20 Jun 2020 14:05:13 +0000 (16:05 +0200)]
PR fortran/95587 - ICE in gfc_target_encode_expr, at fortran/target-memory.c:362
EQUIVALENCE objects are subject to constraints listed in the Fortran 2018
standard, section 8.10.1.1. These constraints are to be checked
also for CLASS variables.
gcc/fortran/
PR fortran/95587
* match.c (gfc_match_equivalence): Check constraints on
EQUIVALENCE objects also for CLASS variables.
Eric Botcazou [Tue, 23 Jun 2020 16:33:28 +0000 (18:33 +0200)]
Fix memory corruption with vector and variant record
The problem is that Has_Constrained_Partial_View must be tested on the
base type of the designated type of an allocator.
gcc/ada/ChangeLog:
* gcc-interface/trans.c (gnat_to_gnu) <N_Allocator>: Minor tweaks.
Call Has_Constrained_Partial_View on base type of designated type.
Mark Eggleston [Mon, 22 Jun 2020 12:35:01 +0000 (13:35 +0100)]
Fortran : ICE in resolve_fl_procedure PR95708
Now issues an error "Intrinsic procedure 'num_images' not
allowed in PROCEDURE" instead of an ICE.
2020-06-22 Steven G. Kargl <kargl@gcc.gnu.org>
gcc/fortran/
PR fortran/95708
* intrinsic.c (add_functions): Replace CLASS_INQUIRY with
CLASS_TRANSFORMATIONAL for intrinsic num_images.
(make_generic): Replace ACTUAL_NO with ACTUAL_YES for
intrinsic team_number.
* resolve.c (resolve_fl_procedure): Check pointer ts.u.derived
exists before using it.
2020-06-22 Mark Eggleston <markeggleston@gcc.gnu.org>
gcc/testsuite/
PR fortran/95708
* gfortran.dg/pr95708.f90: New test.
+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.
git://gcc.gnu.org / gcc.git / log