Harald Anlauf [Thu, 11 Jun 2020 18:29:45 +0000 (20:29 +0200)]
PR fortran/95544 - Fix ICE in NULL() argument to intrinsics
Fortran 2018: An argument to an intrinsic procedure other than ASSOCIATED,
NULL, or PRESENT shall be a data object. An EXPR_NULL is not a data
object. Add checks for intrinsics.
2020-06-11 Steven G. Kargl <kargl@gcc.gnu.org>
Harald Anlauf <anlauf@gmx.de>
Harald Anlauf [Tue, 5 May 2020 20:16:50 +0000 (22:16 +0200)]
PR fortran/93366 - ICE on invalid, reject invalid use of NULL() as argument
gcc/fortran/ChangeLog:
2020-05-05 Steve Kargl <kargl@gcc.gnu.org>
Harald Anlauf <anlauf@gmx.de>
PR fortran/93366
* check.c (gfc_check_associated, invalid_null_arg): Factorize
check for presence of invalid NULL() argument.
(gfc_check_kind, gfc_check_merge, gfc_check_shape)
(gfc_check_sizeof, gfc_check_spread, gfc_check_transfer): Use this
check for presence of invalid NULL() arguments.
gcc/testsuite/ChangeLog:
2020-05-05 Harald Anlauf <anlauf@gmx.de>
PR fortran/93366
* gfortran.dg/pr93366.f90: New test.
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:39:43 +0000 (13:39 +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.
Jakub Jelinek [Tue, 9 Jun 2020 06:39:36 +0000 (08:39 +0200)]
c-family: Fix up MEM_REF printing [PR95580]
The C FE in the MEM_REF printing ICEs if the type of the first argument
(which due to useless pointer conversions can be an arbitrary type) is a
pointer to an incomplete type. The code just wants to avoid printing a cast
if it is a pointer to single byte elements.
2020-06-09 Jakub Jelinek <jakub@redhat.com>
PR c/95580
* c-pretty-print.c (c_pretty_printer::unary_expression): Handle the
case when MEM_REF's first argument has type pointer to incomplete type.
Jakub Jelinek [Mon, 8 Jun 2020 09:05:10 +0000 (11:05 +0200)]
forwprop: Ignore scalar mode vectors in simplify_vector_constructor [PR95528]
As mentioned in the PR, the problem is that at least the x86 backend asumes
that the vec_unpack* and vec_pack* optabs with integral modes are for the
AVX512-ish vector masks rather than for very small vectors done in GPRs.
The only other target that seems to have a scalar mode vec_{,un}pack* optab
is aarch64 as discussed in the PR, so there is also a condition for that.
All other targets have just vector mode optabs.
2020-06-08 Jakub Jelinek <jakub@redhat.com>
PR target/95528
* tree-ssa-forwprop.c (simplify_vector_constructor): Don't use
VEC_UNPACK*_EXPR or VEC_PACK_TRUNC_EXPR with scalar modes unless the
type is vector boolean.
Jakub Jelinek [Thu, 28 May 2020 21:40:54 +0000 (23:40 +0200)]
c++: Try to complete decomp types [PR95328]
Two years ago Paolo has added the
else if (processing_template_decl && !COMPLETE_TYPE_P (type))
pedwarn (...);
lines into cp_finish_decomp. For type dependent decl we punt much earlier,
but even for types which aren't type dependent COMPLETE_TYPE_P might be
false as this testcase shows, so this patch tries to complete_type first
(the reason for writing it that way is that it is then followed by another
else if and if complete_type returns error_mark_node, we shouldn't report
anything, as a bug should have been reported already.
2020-05-28 Jakub Jelinek <jakub@redhat.com>
PR c++/95328
* decl.c (cp_finish_decomp): Call complete_type before checking
COMPLETE_TYPE_P.
Jakub Jelinek [Tue, 26 May 2020 07:35:21 +0000 (09:35 +0200)]
openmp: Ensure copy ctor for composite distribute parallel for class iterators is instantiated [PR95197]
During gimplification omp_finish_clause langhook is called in several places
to add the language specific info to the clause like what default/copy ctors,
dtors and assignment operators should be used.
Unfortunately, if it refers to some not yet instantiated method, during
gimplification it is too late and the methods will not be instantiated
anymore. For other cases, the genericizer has code to detect those and
instantiate whatever is needed, this change adds the same for
distribute parallel for class iterators where we under the hood need
a copy constructor for the iterator to implement it.
2020-05-26 Jakub Jelinek <jakub@redhat.com>
PR c++/95197
* gimplify.c (find_combined_omp_for): Move to omp-general.c.
* omp-general.h (find_combined_omp_for): Declare.
* omp-general.c: Include tree-iterator.h.
(find_combined_omp_for): New function, moved from gimplify.c.
* cp-gimplify.c: Include omp-general.h.
(cp_genericize_r) <case OMP_DISTRIBUTE>: For class iteration
variables in composite distribute parallel for, instantiate copy
ctor of their types.
Jakub Jelinek [Thu, 14 May 2020 07:51:05 +0000 (09:51 +0200)]
openmp: Fix placement of 2nd+ preparation statement for PHIs in simd clone lowering [PR95108]
For normal stmts, preparation statements are inserted before the stmt, so if we need multiple,
they are in the correct order, but for PHIs we emit them after labels in the entry successor
bb, and we used to emit them in the reverse order that way.
2020-05-14 Jakub Jelinek <jakub@redhat.com>
PR middle-end/95108
* omp-simd-clone.c (struct modify_stmt_info): Add after_stmt member.
(ipa_simd_modify_stmt_ops): For PHIs, only add before first stmt in
entry block if info->after_stmt is NULL, otherwise add after that stmt
and update it after adding each stmt.
(ipa_simd_modify_function_body): Initialize info.after_stmt.
Jakub Jelinek [Wed, 13 May 2020 09:22:37 +0000 (11:22 +0200)]
Fix -fcompare-debug issue in purge_dead_edges [PR95080]
The following testcase fails with -fcompare-debug, the bug used to be latent
since introduction of -fcompare-debug.
The loop at the start of purge_dead_edges behaves differently between -g0
and -g - if the last insn is a DEBUG_INSN, then it skips not just
DEBUG_INSNs but also NOTEs until it finds some other real insn (or bb head),
while with -g0 it will not skip any NOTEs, so if we have
real_insn
note
debug_insn // not present with -g0
then with -g it might remove useless REG_EH_REGION from real_insn, while
with -g0 it will not.
Yet another option would be not skipping NOTE_P in the loop; I couldn't find
in history rationale for why it is done.
2020-05-13 Jakub Jelinek <jakub@redhat.com>
PR debug/95080
* cfgrtl.c (purge_dead_edges): Skip over debug and note insns even
if the last insn is a note.
Iain Sandoe [Sat, 13 Jun 2020 09:36:29 +0000 (10:36 +0100)]
coroutines: Make call argument handling more robust [PR95440]
build_new_method_call is supposed to be able to handle a null
arguments list pointer (when the method has no parms). There
were a couple of places where uses of the argument list pointer
were not defended against NULL.
gcc/cp/ChangeLog:
PR c++/95440
* call.c (add_candidates): Use vec_safe_length() for
testing the arguments list.
(build_new_method_call_1): Use vec_safe_is_empty() when
checking for an empty args list.
gcc/testsuite/ChangeLog:
PR c++/95440
* g++.dg/coroutines/pr95440.C: New test.
Patrick Palka [Thu, 11 Jun 2020 20:33:41 +0000 (16:33 -0400)]
c++: constrained class template friend [PR93467]
This fixes two issues in our handling of constrained class template
friend declarations.
The first issue is that we fail to set the constraints on the injected
class template declaration during tsubst_friend_class.
The second issue is that the template parameter levels within the parsed
constraints of a class template friend declaration are shifted if the
enclosing class is a template, and this shift leads to spurious
constraint mismatch errors in associate_classtype_constraints if the
friend declaration refers to an already declared class template.
gcc/cp/ChangeLog:
PR c++/93467
* constraint.cc (associate_classtype_constraints): If there is a
discrepancy between the current template depth and the template
depth of the original declaration, then adjust the template
parameter depth within the current constraints appropriately.
* pt.c (tsubst_friend_class): Substitute into and set the
constraints on the injected declaration.
gcc/testsuite/ChangeLog:
PR c++/93467
* g++.dg/cpp2a/concepts-friend6.C: New test.
* g++.dg/cpp2a/concepts-friend7.C: New test.
Iain Sandoe [Fri, 12 Jun 2020 07:28:35 +0000 (08:28 +0100)]
coroutines: Correct handling of references in parm copies [PR95350].
Adjust to handle rvalue refs the same way as clang, and to correct
the handling of moves when a copy CTOR is present. This is one area
where we could make things easier for the end-user (as was implemented
before this change), however there needs to be agreement about when the
full statement containing a coroutine call ends (i.e. when the ramp
terminates or when the coroutine terminates).
PR c++/95350
* g++.dg/coroutines/torture/func-params-08.C: Adjust test to
reflect that all rvalue refs are dangling.
* g++.dg/coroutines/torture/func-params-09-awaitable-parms.C:
Likewise.
* g++.dg/coroutines/pr95350.C: New test.
Marek Polacek [Thu, 11 Jun 2020 20:35:33 +0000 (16:35 -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.
Marek Polacek [Thu, 11 Jun 2020 20:33:13 +0000 (16:33 -0400)]
c++: explicit(bool) malfunction with dependent expression [PR95066]
I forgot to set DECL_HAS_DEPENDENT_EXPLICIT_SPEC_P when merging two
function declarations and as a sad consequence, we never tsubsted
the dependent explicit-specifier in tsubst_function_decl, leading to
disregarding the explicit-specifier altogether, and wrongly accepting
this test.
PR c++/95066
* decl.c (duplicate_decls): Set DECL_HAS_DEPENDENT_EXPLICIT_SPEC_P.
Marek Polacek [Thu, 11 Jun 2020 20:29:57 +0000 (16:29 -0400)]
c++: ICE with -Wall and constexpr if [PR94937]
An ICE arises here because we call cp_get_callee_fndecl_nofold in a
template, and we've got a CALL_EXPR whose CALL_EXPR_FN is a BASELINK.
This tickles the INDIRECT_TYPE_P assert in cp_get_fndecl_from_callee.
Fixed by turning the assert into a condition and returning NULL_TREE
in that case.
PR c++/94937
* cvt.c (cp_get_fndecl_from_callee): Return NULL_TREE if the function
type is not INDIRECT_TYPE_P.
* decl.c (omp_declare_variant_finalize_one): Call
cp_get_callee_fndecl_nofold instead of looking for the function decl
manually.
* g++.dg/cpp1z/constexpr-if34.C: New test.
* g++.dg/cpp2a/is-constant-evaluated10.C: New test.
Marek Polacek [Thu, 11 Jun 2020 20:27:59 +0000 (16:27 -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 20:26:41 +0000 (16:26 -0400)]
c++: ICE when shortening right shift [PR94955]
Since r10-6527 fold_for_warn calls maybe_constant_value, which means it
can fold more than it previously could. In this testcase it means that
cp_build_binary_op/RSHIFT_EXPR set short_shift because now we were able
to fold op1 to an INTEGER_CST. But then when actually performing the
shortening we crashed because cp_fold_rvalue wasn't able to fold as much
as f_f_w and so tree_int_cst_sgn crashed on a NOP_EXPR. Therefore the
calls should probably match.
PR c++/94955
* typeck.c (cp_build_binary_op): Use fold_for_warn instead of
cp_fold_rvalue.
Iain Sandoe [Thu, 11 Jun 2020 13:11:14 +0000 (14:11 +0100)]
coroutines: Ensure distinct DTOR trees [PR95137].
Part of the PR notes that there are UBSAN fails for the coroutines
test suite. These are primarily related to the use of the same DTOR
tree in the two edges from the await block. Fixed by building a new
tree for each.
gcc/cp/ChangeLog:
PR c++/95137
* coroutines.cc (expand_one_await_expression): Build separate
DTOR trees for the awaitable object on the destroy and resume
paths.
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.
Patrick Palka [Wed, 10 Jun 2020 21:37:53 +0000 (17:37 -0400)]
libstdc++: Fix some ranges algos optimizations [PR95578]
ranges::copy and a number of other ranges algorithms have unwrapping
optimizations for iterators of type __normal_iterator, move_iterator and
reverse_iterator. But in the checks that guard these optimizations we
currently only test that the iterator of the iterator/sentinel pair has
the appropriate type before proceeding with the corresponding
optimization, and do not also test the sentinel type.
This breaks the testcase in this PR because this testcase constructs via
range adaptors a range whose begin() is a __normal_iterator and whose
end() is a custom sentinel type, and then performs ranges::copy on it.
From there we bogusly perform the __normal_iterator unwrapping
optimization on this iterator/sentinel pair, which immediately leads to
a constraint failure since the custom sentinel type does not model
sentinel_for<int*>.
This patch fixes this issue by refining each of the problematic checks
to also test that the iterator and sentinel types are the same before
applying the corresponding unwrapping optimization. Along the way, some
code simplifications are made.
libstdc++-v3/ChangeLog:
PR libstdc++/95578
* include/bits/ranges_algo.h (__lexicographical_compare_fn):
Also check that the iterator and sentinel have the same type before
applying the unwrapping optimization for __normal_iterator.
Split the check into two, one for the first iterator/sentinel
pair and another for second iterator/sentinel pair. Remove uses
of __niter_base, and remove uses of std::move on a
__normal_iterator.
* include/bits/ranges_algobase.h (__equal_fn): Likewise.
(__copy_or_move): Likewise. Perform similar adjustments for
the reverse_iterator and move_iterator optimizations. Inline
the checks into the if-constexprs, and use using-declarations to
make them less visually noisy. Remove uses of __niter_wrap.
(__copy_or_move_backward): Likewise.
* testsuite/25_algorithms/copy/95578.cc: New test.
* testsuite/25_algorithms/copy_backward/95578.cc: New test.
* testsuite/25_algorithms/equal/95578.cc: New test.
* testsuite/25_algorithms/lexicographical_compare/95578.cc: New test.
* testsuite/25_algorithms/move/95578.cc: New test.
* testsuite/25_algorithms/move_backward/95578.cc: New test.
Iain Sandoe [Wed, 10 Jun 2020 07:12:32 +0000 (08:12 +0100)]
coroutines: Fix missed ramp function return copy elision [PR95346].
Confusingly, "get_return_object ()" can do two things:
- Firstly it can provide the return object for the ramp function (as
the name suggests).
- Secondly if the type of the ramp function is different from that
of the get_return_object call, this is used as a single parameter
to a CTOR for the ramp's return type.
In the first case we can rely on finish_return_stmt () to do the
necessary processing for copy elision.
In the second case, we should have passed a prvalue to the CTOR as
per the standard comment, but I had omitted the rvalue () call. Fixed
thus.
gcc/cp/ChangeLog:
PR c++/95346
* coroutines.cc (morph_fn_to_coro): Ensure that the get-
return-object is constructed correctly; When it is not the
final return value, pass it to the CTOR of the return type
as an rvalue, per the standard comment.
gcc/testsuite/ChangeLog:
PR c++/95346
* g++.dg/coroutines/pr95346.C: New test.
Marek Polacek [Wed, 10 Jun 2020 14:49:08 +0000 (10:49 -0400)]
c++: Fix ICE with delayed parsing of noexcept-specifier [PR95562]
Here we ICE because a DEFERRED_PARSE expression leaked to tsubst_copy.
We create these expressions for deferred noexcept-specifiers in
cp_parser_save_noexcept; they are supposed to be re-parsed in
cp_parser_late_noexcept_specifier. In this case we never got around
to re-parsing it because the noexcept-specifier was attached to a
pointer to a function, not to a function declaration. But we should
not have delayed the parsing here in the first place; we already
avoid delaying the parsing for alias-decls, typedefs, and friend
function declarations. (Clang++ also doesn't delay the parsing
for pointers to function.)
gcc/cp/ChangeLog:
PR c++/95562
* parser.c (cp_parser_direct_declarator): Clear
CP_PARSER_FLAGS_DELAY_NOEXCEPT if the declarator kind is not
cdk_id.
gcc/testsuite/ChangeLog:
PR c++/95562
* g++.dg/cpp0x/noexcept60.C: New test.
Martin Jambor [Mon, 8 Jun 2020 18:15:22 +0000 (20:15 +0200)]
ipa-sra: Do not remove statements necessary because of non-call EH (PR 95113)
PR 95113 revealed that when reasoning about which parameters are dead,
IPA-SRA does not perform the same check related to non-call exceptions
as tree DCE. It most certainly should and so this patch moves the
condition used in tree-ssa-dce.c into a separate predicate (in
tree-eh.c) and uses it from both places.
gcc/ChangeLog:
2020-05-27 Martin Jambor <mjambor@suse.cz>
PR ipa/95113
* tree-ssa-dce.c (mark_stmt_if_obviously_necessary): Move non-call
exceptions check to...
* tree-eh.c (stmt_unremovable_because_of_non_call_eh_p): ...this
new function.
* tree-eh.h (stmt_unremovable_because_of_non_call_eh_p): Declare it.
* ipa-sra.c (isra_track_scalar_value_uses): Use it. New parameter
fun.
Iain Sandoe [Sun, 7 Jun 2020 12:47:54 +0000 (13:47 +0100)]
coroutines: Wrap co_await in a target expr where needed [PR95050]
Since the co_await expression is mostly opaque to the existing
machinery, we were hiding the details of the await_resume return
value. If that needs to be wrapped in a target expression, then
emulate this with the whole co_await. Similarly, if the await
expression we build in response to co_await p.yield_value (e)
is wrapped in a target expression, then we need to transfer that
wrapper to the resultant CO_YIELD_EXPR (which is, itself, just
a proxy for the underlying co_await).
gcc/cp/ChangeLog:
PR c++/95050
* coroutines.cc (build_co_await): Wrap the co_await expression
in a TARGET_EXPR, where needed.
(finish_co_yield_expr): Likewise.
gcc/testsuite/ChangeLog:
PR c++/95050
* g++.dg/coroutines/pr95050.C: New test.
When we have completely missing key information (e.g. the
coroutine_traits) or a partially transformed function body, we
need to try and balance returning useful information about
failures with the possibility that some part of the diagnostics
machinery or following code will not be able to handle the
state.
The PRs (and revised testcase) point to cases where that processing
has failed.
This revises the process to avoid special handling for the
ramp, and falls back on the same code used for regular function
fails.
There are test-cases (in addition to the ones for the PRs) that now
cover all early exit points [where the transforms are considered
to have failed in a manner that does not allow compilation to
continue].
Diagnosing bad uses of 'return' in coroutines is somewhat
tricky, since the user can use the keyword before we know
that the function is a coroutine (where such returns are not
permitted). At present, we are just doing a check for any
use of 'return' and erroring on that. However, we can't then
pass the function body on, since it will contain unlowered
coroutine trees.
This avoids the issue by dropping the entire function body
under that circumstance.
PR c++/94817
PR c++/94829
PR c++/95087
* coroutines.cc (morph_fn_to_coro): Set unformed outline
functions to error_mark_node. For early error returns suppress
warnings about missing ramp return values. Fix reinstatement
of the function body on pre-existing initial error. If we see
an early fatal error, drop the erroneous function body.
* decl.c (finish_function): Use the normal error path for fails
in the ramp function, do not try to compile the helpers if the
transform fails.
gcc/testsuite/ChangeLog:
PR c++/94817
PR c++/94829
PR c++/95087
* g++.dg/coroutines/coro-missing-final-suspend.C: New test.
* g++.dg/coroutines/coro-missing-initial-suspend.C: New test.
* g++.dg/coroutines/coro-missing-promise-yield.C: Check for
continuation of compilation.
* g++.dg/coroutines/coro-missing-promise.C: Likewise.
* g++.dg/coroutines/coro-missing-ret-value.C: Likewise
* g++.dg/coroutines/coro-missing-ret-void.C: Likewise
* g++.dg/coroutines/coro-missing-ueh-3.C: Likewise
* g++.dg/coroutines/pr94817.C: New test.
* g++.dg/coroutines/pr94829.C: New test.
* g++.dg/coroutines/co-return-syntax-08-bad-return.C:
Adjust the testcase to do the compile (rather than an
-fsyntax-only parse).
* g++.dg/coroutines/coro1-ret-int-yield-int.h
(MISSING_INITIAL_SUSPEND, MISSING_FINAL_SUSPEND): New.
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.
Harald Anlauf [Fri, 29 May 2020 19:19:31 +0000 (21:19 +0200)]
PR fortran/95090 - ICE: identifier overflow
The initial fix for this PR uncovered several latent issues with further
too small string buffers which showed up only when testing on i686.
Provide sufficiently large temporaries.
2020-05-29 Harald Anlauf <anlauf@gmx.de>
gcc/fortran/
PR fortran/95090
* class.c (get_unique_type_string): Enlarge temporary for
name-mangling. Use strncpy to prevent buffer overrun.
(get_unique_hashed_string): Enlarge temporary.
(gfc_hash_value): Enlarge temporary for name-mangling.
Harald Anlauf [Wed, 27 May 2020 19:20:24 +0000 (21:20 +0200)]
PR fortran/95090 - ICE: identifier overflow
For long module name, derive type and component name, the generated
name-mangled symbol did not fit into a buffer when coarrays were
enabled. Provide sufficiently large temporary.
2020-05-27 Harald Anlauf <anlauf@gmx.de>
gcc/fortran/
PR fortran/95090
* iresolve.c (gfc_get_string): Enlarge temporary for
name-mangling.
gcc/testsuite/
PR fortran/95090
* gfortran.dg/pr95090.f90: New test.
These are not itself necessary for OpenACC 'exit data' directives, and are
skipped over (now) in libgomp. We might as well not emit them to start with,
in line with the equivalent OpenMP directive. We keep the no-op handling in
libgomp for the reason of backward compatibility.
gcc/
* gimplify.c (gimplify_adjust_omp_clauses): Remove
'GOMP_MAP_STRUCT' mapping from OpenACC 'exit data' directives.
gcc/testsuite/
* c-c++-common/goacc/struct-enter-exit-data-1.c: New file.
libgomp/
* oacc-mem.c (goacc_exit_data_internal) <GOMP_MAP_STRUCT>: Explain
special handling.
The code in constexpr for looking up the actual type of the object and then
getting the virtual function from there broke for both of these tests: for
16, it assumed incorrectly that the DECL_VINDEX would apply to the most
derived type's vtable; for 17, it failed to consider that during
construction the base subobject is treated as being of the base type.
Fixed by just doing constant evaluation of the expression that looks up the
function in the vtable. This means that a virtual call will involve loading
the vptr, so we will reject some calls through non-constexpr variables that
we previously accepted, but this seems appropriate to me. None of our
testcases were affected.
Jason Merrill [Thu, 4 Jun 2020 03:50:06 +0000 (23:50 -0400)]
c++: Fix FE devirt with diamond inheritance [PR95158]
This started breaking in GCC 8 because of the fix for PR15272; after that
change, we (correctly) remember the lookup from template parsing time that
found Base::foo through the non-dependent MiddleB base, and so we overlook
the overrider in MiddleA. But given that, the devirtualization condition
from the fix for PR59031 is insufficient; we know that d has to be a
Derived, and we found Base::foo in Base, but forcing a non-virtual call
gets the wrong function.
Fixed by removing the PR59031 code that the PR67184 patch moved to
build_over_call, and instead looking up the overrider in BINFO_VIRTUALS.
gcc/cp/ChangeLog:
PR c++/95158
* class.c (lookup_vfn_in_binfo): New.
* call.c (build_over_call): Use it.
* cp-tree.h (resolves_to_fixed_type_p): Add default argument.
(lookup_vfn_in_binfo): Declare.
gcc/testsuite/ChangeLog:
PR c++/95158
* g++.dg/template/virtual5.C: New test.
Thomas Schwinge [Thu, 4 Jun 2020 14:13:35 +0000 (16:13 +0200)]
[OpenACC 'exit data'] Evaluate 'copyfrom' individually for 'GOMP_MAP_STRUCT' entries
Currently, we don't at all evaluate 'copyfrom' for 'GOMP_MAP_STRUCT' entries.
Fix this by copying/adapting the corresponding non-'GOMP_MAP_STRUCT' code.
libgomp/
* oacc-mem.c (goacc_exit_data_internal) <GOMP_MAP_STRUCT>:
Evaluate 'copyfrom' individually for each entry.
* testsuite/libgomp.oacc-c-c++-common/struct-1.c: Update.
Thomas Schwinge [Thu, 4 Jun 2020 14:01:07 +0000 (16:01 +0200)]
[OpenACC 'exit data'] Evaluate 'finalize' individually for 'GOMP_MAP_STRUCT' entries
Currently, we don't at all evaluate 'finalize' for 'GOMP_MAP_STRUCT' entries.
Fix this by copying/adapting the corresponding non-'GOMP_MAP_STRUCT' code.
libgomp/
* oacc-mem.c (goacc_exit_data_internal) <GOMP_MAP_STRUCT>:
Evaluate 'finalize' individually for each entry.
* testsuite/libgomp.oacc-c-c++-common/struct-1.c: New file.
* testsuite/libgomp.oacc-c-c++-common/struct-refcount-1.c: Remove
file.
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'.
Patrick Palka [Thu, 4 Jun 2020 17:04:01 +0000 (13:04 -0400)]
c++: more constrained nested partial specialization
When checking that a constrained partial specialization is more
constrained than the primary template, we pass only the innermost level
of generic template arguments to strictly_subsumes. This leads to us
doing a nonsensical substitution from normalize_concept_check if the
full set of template arguments has multiple levels, and it ultimately
causes strictly_subsumes to sometimes erroneously return false as in the
testcase below.
gcc/cp/ChangeLog:
* pt.c (process_partial_specialization): Pass the full set of
generic template arguments to strictly_subsumes.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-partial-spec8.C: New test.
When determining the most specialized partial specialization of a
primary template that is nested inside a class template, we first
tsubst the outer template arguments into the TEMPLATE_DECL of each
partial specialization, and then check for satisfaction of each of the
new TEMPLATE_DECL's constraints.
But tsubst_template_decl does not currently guarantee that constraints
from the original DECL_TEMPLATE_RESULT get reattached to the new
DECL_TEMPLATE_RESULT. In the testcase below, this leads to the
constraints_satisfied_p check in most_specialized_partial_spec to
trivially return true for each of the partial specializations.
I'm not sure if such a guarantee would be desirable, but in this case we
can just check constraints_satisfied_p on the original TEMPLATE_DECL
instead of on the tsubsted TEMPLATE_DECL here, which is what this patch
does (alongside some reorganizing).
gcc/cp/ChangeLog:
PR c++/92103
* pt.c (most_specialized_partial_spec): Reorganize the loop over
DECL_TEMPLATE_SPECIALIZATIONS. Check constraints_satisfied_p on
the original template declaration, not on the tsubsted one.
gcc/testsuite/ChangeLog:
PR c++/92103
* g++.dg/cpp2a/concepts-partial-spec7.C: New test.
Patrick Palka [Tue, 2 Jun 2020 01:37:04 +0000 (21:37 -0400)]
c++: constrained lambda inside template [PR92633]
When regenerating a constrained lambda during instantiation of an
enclosing template, we are forgetting to substitute into the lambda's
constraints. Fix this by substituting through the constraints during
tsubst_lambda_expr.
gcc/cp/ChangeLog:
PR c++/92633
PR c++/92838
* pt.c (tsubst_function_decl): Don't do set_constraints when
regenerating a lambda.
(tsubst_lambda_expr): Substitute into the lambda's constraints
and do set_constraints here.
gcc/testsuite/ChangeLog:
PR c++/92633
PR c++/92838
* g++.dg/cpp2a/concepts-lambda11.C: New test.
* g++.dg/cpp2a/concepts-lambda12.C: New test.
In the testcase below we're prematurely folding away the
requires-expression to 'true' after substituting in the function's
template arguments, but before substituting in the lambda's deduced
template arguments.
This patch removes the uses_template_parms check when deciding in
tsubst_requires_expr whether to keep around a new requires-expression.
Regardless of whether the template arguments are dependent, there still
might be more template parameters to later substitute in (as in the
below testcase) and even if not, tsubst_expr doesn't perform full
semantic processing unless !processing_template_decl, so we should still
wait until then to fold away the requires-expression.
gcc/cp/ChangeLog:
PR c++/95020
* constraint.cc (tsubst_requires_expr): Produce a new
requires-expression when processing_template_decl, even if
template arguments are not dependent.
gcc/testsuite/ChangeLog:
PR c++/95020
* g++.dg/cpp2a/concepts-lambda7.C: New test.
Iain Buclaw [Sun, 31 May 2020 22:18:44 +0000 (00:18 +0200)]
Fix unrecognised -mcpu target 'armv7-a' on arm-wrs-vxworks7
In the removal of arm-wrs-vxworks, the default cpu was updated from arm8
to armv7-a, but this is not recognized as a valid -mcpu target. There
is however generic-armv7-a, which was likely the intended cpu that
should have been used instead.
gcc/ChangeLog:
PR target/95420
* config.gcc (arm-wrs-vxworks7*): Set default cpu to generic-armv7-a.
Iain Buclaw [Mon, 1 Jun 2020 11:27:06 +0000 (13:27 +0200)]
d: Fix segfault in build_frontend_type on alpha-*-*
The va_list type for Alpha includes a nameless dummy field for alignment
purposes. To transpose this into D, a field named "__pad%d" is inserted
into the struct definition.
It was also noticed that in the D front-end AST copy of the backend
type, all offsets for fields generated by build_frontend_type were set
to zero due to a wrong assumption that DECL_FIELD_OFFSET would have a
non-zero value. This has been fixed to use byte_position instead.
gcc/d/ChangeLog:
* d-builtins.cc (build_frontend_type): Handle struct fields with NULL
DECL_NAME. Use byte_position to get the real field offset.
Patrick Palka [Fri, 29 May 2020 17:09:20 +0000 (13:09 -0400)]
c++: satisfaction value of type typedef to bool [PR95386]
In the testcase below, the satisfaction value of fn1<int>'s constraint
is INTEGER_CST '1' of type BOOLEAN_TYPE value_type, which is a typedef
to the standard boolean_type_node. But satisfaction_value expects to
see exactly boolean_true_node or integer_one_node, which this value is
neither, causing us to trip over the assert therein.
This patch relaxes satisfaction_value to accept any INTEGER_CST which
satisfies integer_zerop or integer_onep.
gcc/cp/ChangeLog:
PR c++/95386
* constraint.cc (satisfaction_value): Relax to accept any
INTEGER_CST that satisfies integer_zerop or integer_onep.
gcc/testsuite/ChangeLog:
PR c++/95386
* g++.dg/concepts/pr95386.C: New test.
Patrick Palka [Fri, 29 May 2020 18:17:02 +0000 (14:17 -0400)]
c++: lambdas inside constraints [PR92652]
When parsing a constraint-expression, a requires-clause or a
requires-expression, we temporarily increment processing_template_decl
so that we always obtain template trees which we could later reduce via
substitution even when not inside a template.
But incrementing processing_template_decl when we're already inside a
template has the unintended side effect of shifting up the template
parameter levels of a lambda defined inside one of these constructs,
which leads to confusion later during substitution into the lambda.
This patch fixes this issue by incrementing processing_template_decl
during parsing of these constructs only if it is 0.
gcc/cp/ChangeLog:
PR c++/92652
PR c++/93698
PR c++/94128
* parser.c (cp_parser_requires_clause_expression): Temporarily
increment processing_template_decl only if it is 0.
(cp_parser_constraint_expression): Likewise.
(cp_parser_requires_expression): Likewise.
gcc/testsuite/ChangeLog:
PR c++/92652
PR c++/93698
PR c++/94128
* g++.dg/cpp2a/concepts-lambda8.C: New test.
* g++.dg/cpp2a/concepts-lambda9.C: New test.
* g++.dg/cpp2a/concepts-lambda10.C: New test.
Patrick Palka [Fri, 29 May 2020 13:44:09 +0000 (09:44 -0400)]
c++: constexpr ctor with RANGE_EXPR index [PR95241]
In the testcase below, the CONSTRUCTOR for 'field' contains a RANGE_EXPR
index:
{{aggr_init_expr<...>, [1...2]={.off=1}}}
but get_or_insert_ctor_field isn't prepared to handle looking up a
RANGE_EXPR index.
This patch adds limited support to get_or_insert_ctor_field for looking
up a RANGE_EXPR index. The limited scope of this patch should make it
more suitable for backporting, and more extensive support would be
needed only to handle self-modifying CONSTRUCTORs that contain a
RANGE_EXPR index, but I haven't yet been able to come up with a testcase
that actually creates such a CONSTRUCTOR.
gcc/cp/ChangeLog:
PR c++/95241
* constexpr.c (get_or_insert_ctor_field): Add limited support
for RANGE_EXPR index lookups.
gcc/testsuite/ChangeLog:
PR c++/95241
* g++.dg/cpp0x/constexpr-array25.C: New test.
Patrick Palka [Fri, 22 May 2020 14:28:19 +0000 (10:28 -0400)]
c++: P0848R3 and member function templates [PR95181]
When comparing two special member function templates to see if one hides
the other (as per P0848R3), we need to check satisfaction which we can't
do on templates. So this patch makes add_method skip the eligibility
test on member function templates and just lets them coexist.
gcc/cp/ChangeLog:
PR c++/95181
* class.c (add_method): Let special member function templates
coexist if they are not equivalently constrained, or in a class
template.
gcc/testsuite/ChangeLog:
PR c++/95181
* g++.dg/concepts/pr95181.C: New test.
* g++.dg/concepts/pr95181-2.C: New test.
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.
Andrew Stubbs [Wed, 13 May 2020 15:05:54 +0000 (16:05 +0100)]
amdgcn: fix vcc clobber in vector load/store
This switches the code that expands scalar addresses to vectors of addresses
from using VCC to using CC_SAVE_REG, for the lo-part to hi-part carry values.
These were fine in code expanded in earlier passes, but addresses expanded
late, such as for stack spills or reloads, could clobber live VCC values,
causing execution failures.
This is the first target-specific testcase for GCN, so the new .exp file is
included.
Backport from master:
gcc/
* config/gcn/gcn-valu.md (add<mode>3_zext_dup): Change to a
define_expand, and rename the original to ...
(add<mode>3_vcc_zext_dup): ... this, and add a custom VCC operand.
(add<mode>3_zext_dup_exec): Likewise, with ...
(add<mode>3_vcc_zext_dup_exec): ... this.
(add<mode>3_zext_dup2): Likewise, with ...
(add<mode>3_zext_dup_exec): ... this.
(add<mode>3_zext_dup2_exec): Likewise, with ...
(add<mode>3_zext_dup2): ... this.
* config/gcn/gcn.c (gcn_expand_scalar_to_vector_address): Switch
addv64di3_zext* calls to use addv64di3_vcc_zext*.
gcc/testsuite/
* gcc.target/gcn/gcn.exp: New file.
* gcc.target/gcn/vcc-clobber.c: New file.
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.
projects / thirdparty / gcc.git / log
