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.
aarch64: Fix segfault in aarch64_expand_epilogue [PR95361]
The stack frame for the function in the testcase consisted of two
SVE save slots. Both saves had been shrink-wrapped, but for different
blocks, meaning that the stack allocation and deallocation were
separate from the saves themselves. Before emitting the deallocation,
we tried to attach a REG_CFA_DEF_CFA note to the preceding instruction,
to redefine the CFA in terms of the stack pointer. But in this case
there was no preceding instruction.
This in practice only happens for SVE because:
(a) We don't try to shrink-wrap wb_candidate* registers even when
we've decided to treat them as normal saves and restores.
I have a fix for that.
(b) Even with (a) fixed, we're (almost?) guaranteed to emit
a stack tie for frames that are 64k or larger, so we end
up hanging the REG_CFA_DEF_CFA note on that instead.
We should only need to redefine the CFA if it was previously
defined in terms of the frame pointer. In other cases the CFA
should already be defined in terms of the stack pointer,
so redefining it is unnecessary but usually harmless.
2020-05-28 Richard Sandiford <richard.sandiford@arm.com>
gcc/
PR testsuite/95361
* config/aarch64/aarch64.c (aarch64_expand_epilogue): Only
redefine the CFA if we have CFI operations.
gcc/testsuite/
PR testsuite/95361
* gcc.target/aarch64/sve/pr95361.c: New test.
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.
Uros Bizjak [Thu, 28 May 2020 11:59:49 +0000 (13:59 +0200)]
i386: Fix V2SF horizontal addsub insn
PFPNACC insn is incorrectly modelled to perform addition and subtraction
of two operands, but in reality it performs horizontal addition and
subtraction:
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.
This patch fixes the definition of common_iterator::operator-> when the
underlying iterator's operator* returns a non-reference.
The first problem is that the class __detail::_Common_iter_proxy is used
unqualified. Fixing that revealed another problem: the class's template
friend declaration of common_iterator doesn't match up with the
definition of common_iterator, because the friend declaration isn't
constrained.
If we try to make the friend declaration match up by adding constraints,
we run into frontend bug PR93467. So we currently can't correctly
express this friend relation between __detail::_Common_iter_proxy and
common_iterator.
As a workaround to this frontend bug, this patch moves the definition of
_Common_iter_proxy into the class template of common_iterator so that we
could instead express the friend relation via the injected-class-name.
(This bug was found when attempting to use views::common to work around
the compile failure with the testcase in PR95322.)
libstdc++-v3/ChangeLog:
PR libstdc++/95322
* include/bits/stl_iterator.h (__detail::_Common_iter_proxy):
Remove and instead define it ...
(common_iterator::_Proxy): ... here.
(common_iterator::operator->): Use it.
* testsuite/24_iterators/common_iterator/2.cc: New test.
* testsuite/std/ranges/adaptors/95322.cc: New test.
Here, when considering the two 'insert' overloads, we look for aggregate
conversions from the same initializer-list to B<3> or
initializer_list<B<3>>. But since my fix for reshape_init overhead on the
PR14179 testcase we reshaped the initializer-list directly, leading to an
error when we then tried to reshape it differently for the second overload.
gcc/cp/ChangeLog:
PR c++/95319
* decl.c (reshape_init_array_1): Don't reuse in overload context.
gcc/testsuite/ChangeLog:
PR c++/95319
* g++.dg/cpp0x/initlist-array12.C: New test.
Jason Merrill [Tue, 26 May 2020 21:27:55 +0000 (17:27 -0400)]
c++: operator<=> and -Wzero-as-null-pointer-constant [PR95242]
In C++20, if there is no viable operator< available, lhs < rhs gets
rewritten to (lhs <=> rhs) < 0, where operator< for the comparison
categories is intended to accept literal 0 on the RHS but not other
integers. We don't want this to produce a warning from
-Wzero-as-null-pointer-constant.
gcc/cp/ChangeLog:
* call.c (build_new_op_1): Suppress
warn_zero_as_null_pointer_constant across comparison of <=> result
to 0.
Jason Merrill [Mon, 25 May 2020 23:04:05 +0000 (19:04 -0400)]
c++: Fix stdcall attribute in template. [PR95222]
Another case that breaks with my fix for PR90750: we shouldn't move type
attributes in TYPENAME context either, as there's no decl for them to move
to.
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 [Wed, 13 May 2020 08:21:42 +0000 (05:21 -0300)]
x86-vxworks malloc aligns to 8 bytes like solaris
Vxworks 7's malloc, like Solaris', only ensures 8-byte alignment of
returned pointers on 32-bit x86, though GCC's stddef.h defines
max_align_t with 16-byte alignment for __float128. This patch enables
on x86-vxworks the same memory_resource workaround used for x86-solaris.
The testsuite also had a workaround, defining BAD_MAX_ALIGN_T and
xfailing the test; extend those to x86-vxworks as well, and remove the
check for char-aligned requested allocation to be aligned like
max_align_t. With that change, the test passes on x86-vxworks; I'm
guessing that's the same reason for the test not to pass on
x86-solaris (and on x86_64-solaris -m32), so with the fix, I'm
tentatively removing the xfail.
for libstdc++-v3/ChangeLog
PR libstdc++/77691
* include/experimental/memory_resource
(__resource_adaptor_imp::do_allocate): Handle max_align_t on
x86-vxworks as on x86-solaris.
(__resource_adaptor_imp::do_deallocate): Likewise.
* testsuite/experimental/memory_resource/new_delete_resource.cc:
Drop xfail.
(BAD_MAX_ALIGN_T): Define on x86-vxworks as on x86-solaris.
(test03): Drop max-align test for char-aligned alloc.
Jason Merrill [Mon, 25 May 2020 22:04:39 +0000 (18:04 -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:04:39 +0000 (18:04 -0400)]
c++: Local class DMI using local static [PR90749]
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:04:39 +0000 (18:04 -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:04:39 +0000 (18:04 -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.
gcc/ChangeLog:
PR target/95255
* config/i386/i386.md (<rounding_insn><mode>2): Do not try to
expand non-sse4 ROUND_ROUNDEVEN rounding via SSE support routines.
gcc/testsuite/ChangeLog:
PR target/95255
* gcc.target/i386/pr95255.c: New test.
projects / thirdparty / gcc.git / log
