| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
In this PR, we're ICEing on a use of an 'int... a' template parameter pack as
part of the variadic lambda init-capture [...z=a].
The unexpected thing about this variadic init-capture is that it is not
type-dependent, and so the call to do_auto_deduction from
lambda_capture_field_type actually resolves its type to 'int' instead of exiting
early like it does for a type-dependent variadic initializer. This later
confuses add_capture which, according to one of its comments, assumes that
'type' is always 'auto' for a variadic init-capture.
The simplest fix (and the approach that this patch takes) seems to be to avoid
doing auto deduction in lambda_capture_field_type when the initializer uses
parameter packs, so that we always return 'auto' even in the non-type-dependent
case.
gcc/cp/ChangeLog:
PR c++/94483
* lambda.c (lambda_capture_field_type): Avoid doing auto deduction if
the explicit initializer has parameter packs.
gcc/testsuite/ChangeLog:
PR c++/94483
* g++.dg/cpp2a/lambda-pack-init5.C: New test.
|
|
In the testcase for this PR, we try to parse the statement
A(value<0>());
first tentatively as a declaration (with a parenthesized declarator), and during
this tentative parse we end up issuing a hard error from
cp_parser_check_template_parameters about its invalidness as a declaration.
Rather than issuing a hard error, it seems we should instead simulate an error
since we're parsing tentatively. This would then allow cp_parser_statement to
recover and successfully parse the statement as an expression-statement instead.
gcc/cp/ChangeLog:
PR c++/88754
* parser.c (cp_parser_check_template_parameters): Before issuing a hard
error, first try simulating an error instead.
gcc/testsuite/ChangeLog:
PR c++/88754
* g++.dg/parse/ambig10.C: New test.
|
|
This change fixes two obvious redundant assignments reported by cppcheck:
trunk.git/gcc/c/c-parser.c:16969:2: style: Variable 'data.clauses' is reassigned a value before the old one has been used. [redundantAssignment]
trunk.git/gcc/cp/call.c:5116:9: style: Variable 'arg2' is reassigned a value before the old one has been used. [redundantAssignment]
2020-04-17 Jakub Jelinek <jakub@redhat.com>
PR other/94629
* c-parser.c (c_parser_oacc_routine): Remove redundant assignment
to data.clauses.
* call.c (build_conditional_expr_1): Remove redundant assignment to
arg2.
|
|
For symmetric transfers to work with C++20 coroutines, it is
currently necessary to tail call the callee coroutine from resume
method of the caller coroutine. However there are several targets
which don't support an indirect tail call to an arbitrary callee.
Unfortunately, the target 'function_ok_for_sibcall' is not usable
from the front end in all cases. While it is possible to add a new
hook to cover this circumstance, it is too late in the release
cycle to be sure of getting the setting correct for all targets.
So, this patch backs out the use of function_ok_for_sibcall () and
the mandate of CALL_EXPR_MUST_TAIL_CALL from the symmetric
transfer.
Targets that can make indirect tail calls to arbitrary callees will
still be able to make use of the symmetric transfer (without risking
overrunning the stack) for optimization levels >= 2.
The draft standard does not mandate unlimited symmetric transfers,
so removing this is a QOI issue (albeit an important one) rather
than a correctness one.
The test is moved and adjusted so that it can be opted into by any
target that supports the necessary tailcall.
gcc/cp/ChangeLog:
2020-04-16 Iain Sandoe <iain@sandoe.co.uk>
PR c++/94359
* coroutines.cc (build_actor_fn): Back out use of
targetm.function_ok_for_sibcall. Do not mark the resume
call as CALL_EXPR_MUST_TAIL_CALL.
gcc/testsuite/ChangeLog:
2020-04-16 Iain Sandoe <iain@sandoe.co.uk>
PR c++/94359
* g++.dg/coroutines/torture/symmetric-transfer-00-basic.C: Move..
* g++.dg/coroutines/symmetric-transfer-00-basic.C: ..here and
adjust to run at O2 for targets supporting the necessary tail
call.
|
|
Here we're ICE'ing in do_narrow during error-recovery, because ocp_convert
returns error_mark_node after it attempts to reduce a const decl to its
erroneous DECL_INITIAL via scalar_constant_value, and we later pass this
error_mark_node to fold_build2 which isn't prepared to handle error_mark_nodes.
We could fix this ICE in do_narrow by checking if ocp_convert returns
error_mark_node, but for the sake of consistency and for better error recovery
it seems it'd be preferable if ocp_convert didn't care that a const decl's
initializer is erroneous and would instead proceed as if the decl was not const,
which is the approach that this patch takes.
gcc/cp/ChangeLog:
PR c++/94475
* cvt.c (ocp_convert): If the result of scalar_constant_value is
erroneous, ignore it and use the original expression.
gcc/testsuite/ChangeLog:
PR c++/94475
* g++.dg/conversion/err-recover2.C: New test.
* g++.dg/diagnostic/pr84138.C: Remove now-bogus warning.
* g++.dg/warn/Wsign-compare-8.C: Remove now-bogus warning.
|
|
This snippet has been copied from the non-structured binding declaration
parsing later in the function, and while for non-structured bindings
it can be followed by comma or semicolon, structured bindings may be
only followed by semicolon.
Or, do we want to have a different message for the case when there is
a comma (and keep this corrected one only if there is something else)
that would explain better what is the bug (or add a fix-it hint)?
Marek said in the PR that clang++ reports
error: decomposition declaration must be the only declaration in its group
There is another thing Marek noted (though, something for different spot),
that diagnostic for auto x(1), [e,f] = test2; could also use a clearer
wording like the above (or a fix-it hint), but the question is if we should
assume [ after , as a structured binding or if we should do some tentative
parsing first to figure out if it looks like a structured binding.
2020-04-16 Jakub Jelinek <jakub@redhat.com>
PR c++/94571
* parser.c (cp_parser_simple_declaration): Fix up a pasto in
diagnostics.
* g++.dg/cpp1z/decomp51.C: New test.
|
|
This change started with a bugreport about a typo in one requires testcase
(diagnosed with -Wunknown-pragmas only), but following discussion lead to
noting that we do not diagnose restriction that requires directives in
C/C++ may only appear at file or namespace scope; and several our tests
violated that.
2020-04-15 Jakub Jelinek <jakub@redhat.com>
PR c/94593
* c-parser.c (c_parser_pragma) <case PRAGMA_OMP_REQUIRES>: Reject
requires directive when not at file scope.
* parser.c (cp_parser_pragma) <case PRAGMA_OMP_REQUIRES>: Reject
requires directive when not at file or namespace scope.
* c-c++-common/gomp/requires-1.c: Fix a typo, requries -> requires.
Move directives to file scope.
(i): Remove.
* c-c++-common/gomp/requires-2.c: Move directives to file scope.
(i, foo): Remove.
* c-c++-common/gomp/requires-4.c: Move directives to file scope.
* c-c++-common/gomp/atomic-19.c: Move requires directive to file scope.
* c-c++-common/gomp/atomic-20.c: Likewise.
* c-c++-common/gomp/atomic-21.c: Likewise.
* c-c++-common/gomp/atomic-22.c: Likewise.
* gcc.dg/gomp/requires-1.c: New test.
* g++.dg/gomp/requires-1.C: New test.
* g++.dg/gomp/requires-2.C: New test.
* g++.dg/gomp/atomic-18.C: Move requires directive to file scope.
|
|
For symmetric transfers to work with C++20 coroutines, it is
currently necessary to tail call the callee coroutine from resume
method of the caller coroutine. The current codegen marks these
resume calls as "MUST_TAIL_CALL" to indicate that the tail call is
required for correctness.
Unfortunately, several targets have ABI constraints that prevent
an indirect tail-call, which results in the PRs compile error.
The change here tests the target sibcall hook for the resume
expression and only marks it as requiring a tail call if that's
supported.
This doesn't fix the underlying problem; that really a solution is
needed to allow the tail-calls (or equivalent) to take place - but
that will be deferred until next stage 1.
gcc/cp/ChangeLog:
2020-04-14 Iain Sandoe <iain@sandoe.co.uk>
PR c++/94359
* coroutines.cc (build_actor_fn): Check that the target can
support the resume tailcall before mandating it.
gcc/testsuite/ChangeLog:
2020-04-14 Iain Sandoe <iain@sandoe.co.uk>
PR c++/94359
* g++.dg/coroutines/torture/symmetric-transfer-00-basic.C:
Expect a run fail for targets without arbitrary indirect
tail-calls.
|
|
This fixes a garbled concepts diagnostic by moving the handling of DECLTYPE_TYPE
from pp_cxx_type_specifier_seq to cxx_pretty_printer::simple_type_specifier, a
move which also seems to be more consistent with the language grammar.
This patch also fixes pretty printing of rvalue reference types via
cxx_pretty_printer::type_id, which eventually calls pp_c_pointer which currently
doesn't distinguish between lvalue and rvalue references.
gcc/c-family/ChangeLog:
PR c++/85278
* c-pretty-print.c (pp_c_pointer) <case REFERENCE_TYPE>: Print a double
ampersand if it's an rvalue reference type.
gcc/cp/ChangeLog:
PR c++/85278
* cxx-pretty-print.c (cxx_pretty_printer:simple_type_specifier)
<case DECLTYPE_TYPE>: Handle DECLTYPE_TYPE here instead of ...
(pp_cxx_type_specifier_seq) <case DECLTYPE_TYPE>: ... here.
(cxx_pretty_printer::direct_abstract_declarator) <case DECLTYPE_TYPE>:
New no-op case.
gcc/testsuite/ChangeLog:
PR c++/85278
* g++.dg/concepts/diagnostic9.C: New test.
|
|
When evaluating the initializer of 'a' in the following example
struct A {
A() = default; A(const A&);
A *p = this;
};
constexpr A foo() { return {}; }
constexpr A a = foo();
the PLACEHOLDER_EXPR for 'this' in the aggregate initializer returned by foo
gets resolved to the RESULT_DECL of foo. But due to guaranteed RVO, the 'this'
should really be resolved to '&a'.
Fixing this properly by immediately resolving 'this' and PLACEHOLDER_EXPRs to
the ultimate object under construction would in general mean that we would no
longer be able to cache constexpr calls for which RVO possibly applies, because
the result of the call may now depend on the ultimate object under construction.
So as a mostly correct stopgap solution that retains cachability of RVO'd
constexpr calls, this patch fixes this issue by rewriting all occurrences of the
RESULT_DECL in the result of a constexpr function call with the current object
under construction, after the call returns. This means the 'this' pointer
during construction of the temporary will still point to the temporary object
instead of the ultimate object, but besides that this approach seems
functionally equivalent to the proper approach.
gcc/cp/ChangeLog:
PR c++/94034
* constexpr.c (replace_result_decl_data): New struct.
(replace_result_decl_data_r): New function.
(replace_result_decl): New function.
(cxx_eval_call_expression): Use it.
* tree.c (build_aggr_init_expr): Set the location of the AGGR_INIT_EXPR
to that of its initializer.
gcc/testsuite/ChangeLog:
PR c++/94034
* g++.dg/cpp0x/constexpr-empty15.C: New test.
* g++.dg/cpp1y/constexpr-nsdmi6a.C: New test.
* g++.dg/cpp1y/constexpr-nsdmi6b.C: New test.
* g++.dg/cpp1y/constexpr-nsdmi7a.C: New test.
* g++.dg/cpp1y/constexpr-nsdmi7b.C: New test.
|
|
While reviewing [basic.scope.param] I noticed we don't show the location
of the previous declaration when giving an error about "A parameter name
shall not be redeclared in the outermost block of the function definition".
PR c++/94588
* name-lookup.c (check_local_shadow): Add an inform call.
* g++.dg/diagnostic/redeclaration-1.C: Add dg-message.
|
|
We are hitting a recursive loop when printing the signature of a function
containing a decltype([]{}) type. The loop is
dump_function_decl -> dump_substitution
-> dump_template_bindings
-> dump_type
-> dump_aggr_type
-> dump_scope -> dump_function_decl
and we loop because dump_template_bindings wants to print the resolved type of
decltype([]{}) (i.e. just a lambda type), so it calls dump_aggr_type, which
wants to print the function scope of the lambda type. But the function scope of
the lambda type is the function which we're in the middle of printing.
This patch breaks the loop by passing TFF_NO_FUNCTION_ARGUMENTS to
dump_function_decl from dump_scope, so that we avoid recursing into
dump_substitution and ultimately looping.
This also means we no longer emit the "[with ...]" clause when printing a
function template scope, and we instead just emit its template argument list in
a more natural way, e.g. instead of
foo(int, char) [with T=bool]::x
we would now print
foo<bool>::x
which seems like an improvement on its own.
The full signature of the function 'spam' in the below testcase is now
void spam(decltype (<lambda>)*) [with T = int; decltype (<lambda>) = spam<int>::<lambda()>]
gcc/cp/ChangeLog:
PR c++/94521
* error.c (dump_scope): Pass TFF_NO_FUNCTION_ARGUMENTS to
dump_function_decl when printing a function template instantiation as a
scope.
gcc/testsuite/ChangeLog:
PR c++/94521
* g++.dg/cpp2a/lambda-uneval12.C: New test.
|
|
In this PR we're incorrectly rejecting a self-modifying constexpr initializer as
a consequence of the fix for PR78572.
It looks like however that the fix for PR78572 is obsoleted by the fix for
PR89336: the testcase from the former PR successfully compiles even with its fix
reverted.
But then further testing showed that the analogous testcase of PR78572 where the
array has an aggregate element type is still problematic (i.e. we ICE) even with
the fix for PR78572 applied. The reason is that in cxx_eval_bare_aggregate we
attach a constructor_elt of aggregate type always to the end of the new
CONSTRUCTOR, but that's not necessarily correct if the CONSTRUCTOR is
self-modifying. We should instead be using get_or_insert_ctor_field to insert
the constructor_elt in the right place.
So this patch reverts the PR78572 fix and makes the appropriate changes to
cxx_eval_bare_aggregate. This fixes PR94470, and we now are also able to fully
reduce the initializers of 'arr' and 'arr2' in the new test array57.C to
constant initializers.
gcc/cp/ChangeLog:
PR c++/94470
* constexpr.c (get_or_insert_ctor_field): Set default value of parameter
'pos_hint' to -1.
(cxx_eval_bare_aggregate): Use get_or_insert_ctor_field instead of
assuming the the next index belongs at the end of the new CONSTRUCTOR.
(cxx_eval_store_expression): Revert PR c++/78572 fix.
gcc/testsuite/ChangeLog:
PR c++/94470
* g++.dg/cpp1y/constexpr-nsdmi8.C: New test.
* g++.dg/cpp1y/constexpr-nsdmi9.C: New test.
* g++.dg/init/array57.C: New test.
|
|
My fix for 94147 was confusing no-linkage with internal linkage, at
the language level. That's wrong. (the std is confusing here, because
it describes linkage of names (which is wrong), and lambdas have no
names)
Lambdas with extra-scope, have linkage. However, at the
implementation-level that linkage is at least as restricted as the
linkage of the extra-scope decl.
Further, when instantiating a variable initialized by a lambda, we
must determine the visibility of the variable itself, before
instantiating its initializer. If the template arguments are internal
(or no-linkage), the variable will have internal linkage, regardless
of the linkage of the template it is instantiated from. We need to
know that before instantiating the lambda, so we can restrict its
linkage correctly.
* decl2.c (determine_visibility): A lambda's visibility is
affected by its extra scope.
* pt.c (instantiate_decl): Determine var's visibility before
instantiating its initializer.
* tree.c (no_linkage_check): Revert code looking at visibility of
lambda's extra scope.
` gcc/cp/
* g++.dg/cpp0x/lambda/pr94426-[12].C: New.
* g++.dg/abi/lambda-vis.C: Drop a warning.
* g++.dg/cpp0x/lambda/lambda-mangle.C: Lambda visibility on
variable changes.
* g++.dg/opt/dump1.C: Drop warnings of no import.
|
|
I mistyped the PR number in the actual fix commit
r10-7682-g0666767eb4cc864f00ba34d97b9d58f8dc650bba.
|
|
The expansions for await expressions were specific to particular
cases, this revises it to be more generic.
a: Revise co_await statement walkers.
We want to process the co_awaits one statement at a time.
We also want to be able to determine the insertion points for
new bind scopes needed to cater for temporaries that are
captured by reference and have lifetimes that need extension
to the end of the full expression. Likewise, the handling of
captured references in the evaluation of conditions might
result in the need to make a frame copy.
This reorganises the statement walking code to make it easier to
extend for these purposes.
b: Factor reference-captured temp code.
We want to be able to use the code that writes a new bind expr
with vars (and their initializers) from several places, so split
that out of the maybe_promote_captured_temps() function into a
new replace_statement_captures (). Update some comments.
c: Generalize await statement expansion.
This revises the expansion to avoid the need to expand conditionally
on the tree type. It resolves PR 94528.
gcc/cp/ChangeLog:
2020-04-10 Iain Sandoe <iain@sandoe.co.uk>
PR c++/94538
* coroutines.cc (co_await_expander): Remove.
(expand_one_await_expression): New.
(process_one_statement): New.
(await_statement_expander): New.
(build_actor_fn): Revise to use per-statement expander.
(struct susp_frame_data): Reorder and comment.
(register_awaits): Factor code.
(replace_statement_captures): New, factored from...
(maybe_promote_captured_temps):.. here.
(await_statement_walker): Revise to process per statement.
(morph_fn_to_coro): Use revised susp_frame_data layout.
gcc/testsuite/ChangeLog:
2020-04-10 Iain Sandoe <iain@sandoe.co.uk>
PR c++/94538
* g++.dg/coroutines/pr94528.C: New test.
|
|
In C++20 this is well-formed:
using T = int[2];
T t(1, 2);
which means that std::is_constructible_v<int[2], int, int> should be true.
But constructible_expr immediately returned the error_mark_node when it
saw a list with more than one element. To give accurate results in
C++20, we have to try initializing the aggregate from a parenthesized list of
values.
To not repeat the same mistake as in c++/93790, if there's only one
element, I'm trying {} only when () didn't succeed. is_constructible5.C
verifies this.
In paren-init24.C std::is_nothrow_constructible_v doesn't work due to
error: invalid 'static_cast' from type 'int' to type 'int [1]'
and
error: functional cast to array type 'int [2]'
This needs to be fixed in libstdc++.
PR c++/94149
* method.c (constructible_expr): In C++20, try using parenthesized
initialization of aggregates to determine the result of
__is_constructible.
* g++.dg/cpp2a/paren-init24.C: New test.
* g++.dg/cpp2a/paren-init25.C: New test.
* g++.dg/ext/is_constructible5.C: New test.
|
|
gcc/cp
2020-04-10 Bin Cheng <bin.cheng@linux.alibaba.com>
* coroutines.cc (co_await_expander): Simplify.
gcc/testsuite
2020-04-10 Bin Cheng <bin.cheng@linux.alibaba.com>
* g++.dg/coroutines/co-await-syntax-10.C: New test.
* g++.dg/coroutines/co-await-syntax-11.C: New test.
|
|
Here due to my recent change to store_init_value we were expanding the
initializer of aw knowing that we were initializing aw. When
cxx_eval_call_expression finished the constructor, it wanted to look up the
value of aw to set TREE_READONLY on it, but we haven't set DECL_INITIAL yet,
so decl_constant_value tried to instantiate the initializer again. And
infinite recursion. Stopped by optimizing the case of asking for the value
of ctx->object, which is ctx->value. It also would have worked to look in
the values hash table, so let's move that up before decl_constant_value as
well.
gcc/cp/ChangeLog
2020-04-09 Jason Merrill <jason@redhat.com>
PR c++/94523
* constexpr.c (cxx_eval_constant_expression) [VAR_DECL]: Look at
ctx->object and ctx->global->values first.
|
|
This PR points out that we are rejecting valid code in C++20. The
problem is that we were surreptitiously transforming
T& t(e)
into
T& t{e}
which is wrong, because the type of e had a conversion function to T,
while aggregate initialization of t from e doesn't work. Therefore, I
was violating a design principle of P0960, which says that any existing
meaning of A(b) should not change. So I think we should only attempt to
aggregate-initialize if the original expression was ill-formed.
Another design principle is that () should work where {} works, so this:
struct S { int i; };
const S& s(1);
has to keep working. Thus the special handling for paren-lists with one
element. (A paren-list with more than one element would give you "error:
expression list treated as compound expression in initializer" C++17.)
PR c++/93790
* call.c (initialize_reference): If the reference binding failed, maybe
try initializing from { }.
* decl.c (grok_reference_init): For T& t(e), set
LOOKUP_AGGREGATE_PAREN_INIT but don't build up a constructor yet.
* g++.dg/cpp2a/paren-init23.C: New test.
* g++.dg/init/aggr14.C: New test.
|
|
references.
When we promote captured temporaries to local variables, we also
remove their initializers from the relevant call expression. This
means that we should recompute the need for a cleanup expression
once the set of temporaries that remains becomes known.
gcc/cp/ChangeLog:
2020-04-08 Iain Sandoe <iain@sandoe.co.uk>
Jun Ma <JunMa@linux.alibaba.com>
* coroutines.cc (maybe_promote_captured_temps): Add a
cleanup expression, if needed, to any call from which
we promoted temporaries captured by reference.
|
|
While reducing something else I noticed that we ICE on the following
invalid code. In tsubst_lambda_expr, tsubst_template_decl has already
reported an error and returned the error_mark_node, so make sure we
don't ICE on that. I'm using a goto here because we still have to
do finish_struct because it does popclass ().
PR c++/94507 - ICE-on-invalid with lambda template.
* pt.c (tsubst_lambda_expr): Cope when tsubst_template_decl or
tsubst_function_decl returns error_mark_node.
* g++.dg/cpp2a/lambda-generic7.C: New test.
|
|
PR c++/94314
* gimple.c (gimple_call_operator_delete_p): Rename to...
(gimple_call_replaceable_operator_delete_p): ... this.
Use DECL_IS_REPLACEABLE_OPERATOR_DELETE_P.
* gimple.h (gimple_call_operator_delete_p): Rename to ...
(gimple_call_replaceable_operator_delete_p): ... this.
* tree-core.h (tree_function_decl): Add replaceable_operator
flag.
* tree-ssa-dce.c (mark_all_reaching_defs_necessary_1):
Use DECL_IS_REPLACEABLE_OPERATOR_DELETE_P.
(propagate_necessity): Use gimple_call_replaceable_operator_delete_p.
(eliminate_unnecessary_stmts): Likewise.
* tree-streamer-in.c (unpack_ts_function_decl_value_fields):
Pack DECL_IS_REPLACEABLE_OPERATOR.
* tree-streamer-out.c (pack_ts_function_decl_value_fields):
Unpack the field here.
* tree.h (DECL_IS_REPLACEABLE_OPERATOR): New.
(DECL_IS_REPLACEABLE_OPERATOR_NEW_P): New.
(DECL_IS_REPLACEABLE_OPERATOR_DELETE_P): New.
* cgraph.c (cgraph_node::dump): Dump if an operator is replaceable.
* ipa-icf.c (sem_item::compare_referenced_symbol_properties): Compare
replaceable operator flags.
PR c++/94314
* decl.c (duplicate_decls): Duplicate also DECL_IS_REPLACEABLE_OPERATOR.
(cxx_init_decl_processing): Mark replaceable all implicitly defined
operators.
PR c++/94314
* lto-common.c (compare_tree_sccs_1): Compare also
DECL_IS_REPLACEABLE_OPERATOR.
PR c++/94314
* g++.dg/pr94314-2.C: New test.
* g++.dg/pr94314-3.C: New test.
* g++.dg/pr94314.C: New test.
|
|
This resolves parts of Core issues 1001/1322 by rebuilding the function type
of an instantiated function template in terms of its formal parameter types
whenever the original function type and formal parameter types disagree about
the type of a parameter after substitution.
gcc/cp/ChangeLog:
Core issues 1001 and 1322
PR c++/92010
* pt.c (rebuild_function_or_method_type): Split function out from ...
(tsubst_function_type): ... here.
(maybe_rebuild_function_decl_type): New function.
(tsubst_function_decl): Use it.
gcc/testsuite/ChangeLog:
Core issues 1001 and 1322
PR c++/92010
* g++.dg/cpp2a/lambda-uneval11.c: New test.
* g++.dg/template/array33.C: New test.
* g++.dg/template/array34.C: New test.
* g++.dg/template/defarg22.C: New test.
|
|
For -fsanitize=vptr, we insert a NULL store into the vptr instead of just
adding a CLOBBER of this. build_clobber_this makes the CLOBBER conditional
on in_charge (implicit) parameter whenever CLASSTYPE_VBASECLASSES, but when
adding this conditionalization to the -fsanitize=vptr code in PR87095,
I wanted it to catch some more cases when the class has CLASSTYPE_VBASECLASSES,
but the vptr is still not shared with something else, otherwise the
sanitization would be less effective.
The following testcase shows that the chosen test that CLASSTYPE_PRIMARY_BINFO
is non-NULL and has BINFO_VIRTUAL_P set wasn't sufficient,
the D class has still sizeof(D) == sizeof(void*) and thus contains just
a single vptr, but while in B::~B() this results in the vptr not being
cleared, in C::~C() this condition isn't true, as CLASSTYPE_PRIMARY_BINFO
in that case is B and is not BINFO_VIRTUAL_P, so it clears the vptr, but the
D::~D() dtor after invoking C::~C() invokes A::~A() with an already cleared
vptr, which is then reported.
The following patch is just a shot in the dark, keep looking through
CLASSTYPE_PRIMARY_BINFO until we find BINFO_VIRTUAL_P, but it works on the
existing testcase as well as this new one.
2020-04-08 Jakub Jelinek <jakub@redhat.com>
PR c++/94325
* decl.c (begin_destructor_body): For CLASSTYPE_VBASECLASSES class
dtors, if CLASSTYPE_PRIMARY_BINFO is non-NULL, but not BINFO_VIRTUAL_P,
look at CLASSTYPE_PRIMARY_BINFO of its BINFO_TYPE if it is not
BINFO_VIRTUAL_P, and so on.
* g++.dg/ubsan/vptr-15.C: New test.
|
|
Here we ICE because early_check_defaulted_comparison passed a null
ctx to same_type_p. The attached test is ill-formed according to
[class.compare.default]/1, so fixed by detecting this case early.
PR c++/94478 - ICE with defaulted comparison operator
* method.c (early_check_defaulted_comparison): Give an error when the
context is null.
* g++.dg/cpp2a/spaceship-err4.C: New test.
|
|
gcc/c/
PR middle-end/94120
* c-decl.c (c_check_in_current_scope): New function.
* c-tree.h (c_check_in_current_scope): Declare it.
* c-parser.c (c_parser_oacc_declare): Add check that variables
are declared in the same scope as the directive. Fix handling
of namespace vars.
gcc/cp/
PR middle-end/94120
* paser.c (cp_parser_oacc_declare): Add check that variables
are declared in the same scope as the directive.
gcc/testsuite/
PR middle-end/94120
* c-c++-common/goacc/declare-pr94120.c: New.
* g++.dg/declare-pr94120.C: New.
libgomp/testsuite/
PR middle-end/94120
* libgomp.oacc-c++/declare-pr94120.C: New.
|
|
The problem here was that cp_parser_requires_expression committing to a
tentative parse confused cp_parser_decltype_expr, which needs to still be
tentative. The only reason to commit here is to get syntax errors within
the requires-expression, which we can still do when the commit is firewalled
from the enclosing context.
gcc/cp/ChangeLog
2020-04-07 Jason Merrill <jason@redhat.com>
PR c++/94480
* parser.c (cp_parser_requires_expression): Use tentative_firewall.
|
|
Here the 'decltype' is missing '(auto)', so open_paren was NULL, and trying
to get its location is a SEGV. Using matching_parens avoids that problem.
gcc/cp/ChangeLog
2020-04-07 Jason Merrill <jason@redhat.com>
PR c++/94481
* parser.c (cp_parser_placeholder_type_specifier): Use
matching_parens.
|
|
In cases that we need to extended the lifetime of a temporary captured
by reference, we make a replacement var for the temporary. This will
be then used to define a coroutine frame entry (so that the var created
is elided by a later phase). However, we should ensure that the var
is correctly declared anyway.
gcc/cp/ChangeLog:
2020-04-07 Iain Sandoe <iain@sandoe.co.uk>
* coroutines.cc (maybe_promote_captured_temps): Ensure that
reference capture placeholder vars are properly declared.
|
|
[PR90996]
This PR reports that ever since the introduction of the
CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag, we are sometimes failing to resolve
PLACEHOLDER_EXPRs inside array initializers that refer to some inner
constructor. In the testcase in the PR, we have as the initializer for "S c[];"
the following
{{.a=(int &) &_ZGR1c_, .b={*(&<PLACEHOLDER_EXPR struct S>)->a}}}
where CONSTRUCTOR_PLACEHOLDER_BOUNDARY is set on the middle constructor. When
calling replace_placeholders from store_init_value, we pass the entire
initializer to it, and as a result we fail to resolve the PLACEHOLDER_EXPR
within due to the CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag on the middle
constructor blocking replace_placeholders_r from reaching it.
To fix this, we could perhaps either call replace_placeholders in more places,
or we could change where we set CONSTRUCTOR_PLACEHOLDER_BOUNDARY. This patch
takes this latter approach -- when building up an array initializer, we now
bubble any CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag from the element initializers
up to the array initializer so that the boundary doesn't later impede us when we
call replace_placeholders from store_init_value.
Besides fixing the kind of code like in the testcase, this shouldn't cause any
other differences in PLACEHOLDER_EXPR resolution because we don't create or use
PLACEHOLDER_EXPRs of array type in the frontend, as far as I can tell.
gcc/cp/ChangeLog:
PR c++/90996
* tree.c (replace_placeholders): Look through all handled components,
not just COMPONENT_REFs.
* typeck2.c (process_init_constructor_array): Propagate
CONSTRUCTOR_PLACEHOLDER_BOUNDARY up from each element initializer to
the array initializer.
gcc/testsuite/ChangeLog:
PR c++/90996
* g++.dg/cpp1y/pr90996.C: New test.
|
|
We need to set OMP_PARALLEL_COMBINED only if the parsing of omp_master
succeeded, because otherwise there is no nested master construct in the
parallel.
2020-04-07 Jakub Jelinek <jakub@redhat.com>
PR c++/94512
* c-parser.c (c_parser_omp_parallel): Set OMP_PARALLEL_COMBINED
if c_parser_omp_master succeeded.
* parser.c (cp_parser_omp_parallel): Set OMP_PARALLEL_COMBINED
if cp_parser_omp_master succeeded.
* g++.dg/gomp/pr94512.C: New test.
|
|
duplicate_decls assumed that any TREE_ARTIFICIAL function at namespace scope
was a built-in function, but now in C++20 it's possible to have an
implicitly declared hidden friend operator==. We just need to move the
assert into the if condition.
gcc/cp/ChangeLog
2020-04-06 Jason Merrill <jason@redhat.com>
PR c++/94462
* decl.c (duplicate_decls): Fix handling of DECL_HIDDEN_FRIEND_P.
|
|
Here we crash in the gimplifier because gimplify_init_ctor_eval doesn't
expect null indexes for a constructor:
/* ??? Here's to hoping the front end fills in all of the indices,
so we don't have to figure out what's missing ourselves. */
gcc_assert (purpose);
The indexes weren't filled because we never called reshape_init: for
a constructor that represents parenthesized initialization of an
aggregate we don't allow brace elision or designated initializers.
PR c++/94155 - crash in gimplifier with paren init of aggregates.
* init.c (build_vec_init): Fill in indexes.
* g++.dg/cpp2a/paren-init22.C: New test.
|
|
We skip over other conversion codes when mangling expressions, we should do
the same with IMPLICIT_CONV_EXPR.
gcc/cp/ChangeLog
2020-04-04 Jason Merrill <jason@redhat.com>
PR c++/91377
* mangle.c (write_expression): Skip IMPLICIT_CONV_EXPR.
|
|
This removes the use of replace_placeholders in cxx_eval_constant_expression
(which is causing the new test lambda-this6.C to ICE due to replace_placeholders
mutating the shared TARGET_EXPR_INITIAL tree which then trips up the
gimplifier).
In its place, this patch adds a 'parent' field to constexpr_ctx which is used to
store a pointer to an outer constexpr_ctx that refers to another object under
construction. With this new field, we can beef up lookup_placeholder to resolve
PLACEHOLDER_EXPRs which refer to former objects under construction, which fixes
PR94205 without needing to do replace_placeholders. Also we can now respect the
CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag when resolving PLACEHOLDER_EXPRs, and
doing so fixes the constexpr analogue of PR79937.
gcc/cp/ChangeLog:
PR c++/94205
PR c++/79937
* constexpr.c (struct constexpr_ctx): New field 'parent'.
(cxx_eval_bare_aggregate): Propagate CONSTRUCTOR_PLACEHOLDER_BOUNDARY
flag from the original constructor to the reduced constructor.
(lookup_placeholder): Prefer to return the outermost matching object
by recursively calling lookup_placeholder on the 'parent' context,
but don't cross CONSTRUCTOR_PLACEHOLDER_BOUNDARY constructors.
(cxx_eval_constant_expression): Link the 'ctx' context to the 'new_ctx'
context via 'new_ctx.parent' when being expanded without an explicit
target. Don't call replace_placeholders.
(cxx_eval_outermost_constant_expr): Initialize 'ctx.parent' to NULL.
gcc/testsuite/ChangeLog:
PR c++/94205
PR c++/79937
* g++.dg/cpp1y/pr79937-5.C: New test.
* g++.dg/cpp1z/lambda-this6.C: New test.
|
|
This PR reveals that cxx_eval_bare_aggregate and cxx_eval_store_expression do
not anticipate that a constructor element's initializer could mutate the
underlying CONSTRUCTOR. Evaluation of the initializer could add new elements to
the underlying CONSTRUCTOR, thereby potentially invalidating any pointers to
or assumptions about the CONSTRUCTOR's elements, and so these routines should be
prepared for that.
To fix this problem, this patch makes cxx_eval_bare_aggregate and
cxx_eval_store_expression recompute the constructor_elt pointers through which
we're assigning, after it evaluates the initializer. Care is taken to to not
slow down the common case where the initializer does not modify the underlying
CONSTRUCTOR.
gcc/cp/ChangeLog:
PR c++/94219
PR c++/94205
* constexpr.c (get_or_insert_ctor_field): Split out (while adding
support for VECTOR_TYPEs, and optimizations for the common case)
from ...
(cxx_eval_store_expression): ... here. Rename local variable
'changed_active_union_member_p' to 'activated_union_member_p'. Record
the sequence of indexes into 'indexes' that yields the subobject we're
assigning to. Record the integer offsets of the constructor indexes
we're assigning through into 'index_pos_hints'. After evaluating the
initializer of the store expression, recompute 'valp' using 'indexes'
and using 'index_pos_hints' as hints.
(cxx_eval_bare_aggregate): Tweak comments. Use get_or_insert_ctor_field
to recompute the constructor_elt pointer we're assigning through after
evaluating each initializer.
gcc/testsuite/ChangeLog:
PR c++/94219
PR c++/94205
* g++.dg/cpp1y/constexpr-nsdmi3.C: New test.
* g++.dg/cpp1y/constexpr-nsdmi4.C: New test.
* g++.dg/cpp1y/constexpr-nsdmi5.C: New test.
* g++.dg/cpp1z/lambda-this5.C: New test.
|
|
A recent change to cmcstl2 led to two tests failing due to this bug: our
valid expression checking in the context of a requires-expression wasn't
catching that an expression of member function type can only appear as the
function operand of a call expression. Fixed by using convert_to_void to do
the same checking as a discarded-value expression.
This patch also fixes 67825, which already had a testcase, but the testcase
was testing for the wrong behavior.
gcc/cp/ChangeLog
2020-04-04 Jason Merrill <jason@redhat.com>
PR c++/67825
* constraint.cc (tsubst_valid_expression_requirement): Call
convert_to_void.
|
|
The testcase hit an ICE trying to expand a TARGET_EXPR temporary cached from
the other lambda-expression. This patch fixes this in two ways:
1) Avoid reusing a TARGET_EXPR from another function.
2) Avoid ending up with a TARGET_EXPR at all; the use of 'p' had become
<TARGET_EXPR<NON_LVALUE_EXPR<TARGET_EXPR ...>>>, which doesn't make any
sense.
gcc/cp/ChangeLog
2020-04-04 Jason Merrill <jason@redhat.com>
PR c++/94453
* constexpr.c (maybe_constant_value): Use break_out_target_exprs.
* expr.c (mark_use) [VIEW_CONVERT_EXPR]: Don't wrap a TARGET_EXPR in
NON_LVALUE_EXPR.
|
|
[PR94441]
My recent protected_set_expr_location changes work well when
that function is called unconditionally, but as the testcase shows, the C++
FE has a few spots that do:
if (!EXPR_HAS_LOCATION (stmt))
protected_set_expr_location (stmt, locus);
or similar. Now, if we have for -g0 stmt of some expression that can
have location and has != UNKNOWN_LOCATION, while -g instead has
a STATEMENT_LIST containing some DEBUG_BEGIN_STMTs + that expression with
that location, we don't call protected_set_expr_location in the -g0 case,
but do call it in the -g case, because on the STATEMENT_LIST
!EXPR_HAS_LOCATION.
The following patch introduces a helper function which digs up the single
expression of a STATEMENT_LIST and uses that expression in the
EXPR_HAS_LOCATION check (plus changes protected_set_expr_location to
also use that helper).
Or do we want a further wrapper, perhaps C++ FE only, that would do this
protected_set_expr_location_if_unset (stmt, locus)?
2020-04-04 Jakub Jelinek <jakub@redhat.com>
PR debug/94441
* tree-iterator.h (expr_single): Declare.
* tree-iterator.c (expr_single): New function.
* tree.h (protected_set_expr_location_if_unset): Declare.
* tree.c (protected_set_expr_location): Use expr_single.
(protected_set_expr_location_if_unset): New function.
* parser.c (cp_parser_omp_for_loop): Use
protected_set_expr_location_if_unset.
* cp-gimplify.c (genericize_if_stmt, genericize_cp_loop): Likewise.
* g++.dg/opt/pr94441.C: New test.
|
|
The following testcase ICEs, because for parallel combined with some
other construct we initialize the omp_parallel_combined_clauses pointer
and expect the construct combined with it to clear it after it no longer
needs it, but OMP_MASTER didn't do that.
2020-04-04 Jakub Jelinek <jakub@redhat.com>
PR c++/94477
* pt.c (tsubst_expr) <case OMP_MASTER>: Clear
omp_parallel_combined_clauses.
* g++.dg/gomp/pr94477.C: New test.
|
|
In this testcase, when we do a pack expansion of count_better_mins<nums>,
nums appears both in the definition of count_better_mins and as its template
argument. The intent is that we get a expansion over pairs of elements of
the pack, i.e. less<2,2>, less<2,7>, less<7,2>, .... But if we substitute
into the definition of count_better_mins when parsing the template, we end
up with sum<less<nums,nums>...>, which never gives us less<2,7>. We could
deal with this by somehow marking up the use of 'nums' as an argument for
'num', but it's simpler to mark the alias as complex, so we need to
instantiate it later with all its arguments rather than replace it early
with its expansion.
gcc/cp/ChangeLog
2020-04-03 Jason Merrill <jason@redhat.com>
PR c++/91966
* pt.c (complex_pack_expansion_r): New.
(complex_alias_template_p): Use it.
|
|
We represent 'this' in a default member initializer with a PLACEHOLDER_EXPR.
Normally in constexpr evaluation when we encounter one it refers to
ctx->ctor, but when we're creating a temporary of class type, that replaces
ctx->ctor, so a PLACEHOLDER_EXPR that refers to the type of the member being
initialized needs to be replaced before that happens.
gcc/cp/ChangeLog
2020-03-31 Jason Merrill <jason@redhat.com>
PR c++/94205
* constexpr.c (cxx_eval_constant_expression) [TARGET_EXPR]: Call
replace_placeholders.
* typeck2.c (store_init_value): Fix arguments to
fold_non_dependent_expr.
|
|
This patch has no semantic effect; committing it separately makes the change
for 94205 easier to read.
gcc/cp/ChangeLog
2020-03-31 Jason Merrill <jason@redhat.com>
* constexpr.c (cxx_eval_constant_expression) [TARGET_EXPR]: Use
local variables.
|
|
The resolution of CWG issue 1321 clarified that when deciding whether two
expressions involving template parameters are equivalent, two dependent
function calls where the function is named with an unqualified-id are
considered to be equivalent if the name is the same, even if unqualified
lookup finds different sets of functions. We were wrongly treating
qualified-ids the same way, so that EXISTS and test::EXISTS were considered
to be equivalent even though they are looking up the name in different
scopes. This also causes a mangling bug, but I don't think it's safe to fix
that for GCC 10; this patch just fixes the comparison.
gcc/cp/ChangeLog
2020-03-30 Jason Merrill <jason@redhat.com>
PR c++/90711
* tree.c (cp_tree_equal) [CALL_EXPR]: Compare KOENIG_LOOKUP_P.
(called_fns_equal): Check DECL_CONTEXT.
|
|
The following testcase ICEs, because the FE when processing the statement
expression changes the .VEC_CONVERT internal fn CALL_EXPR into .PHI call.
That is because the internal fn call is recorded in the base.u.ifn
field, which overlaps base.u.bits.lang_flag_1 which is used for
STMT_IS_FULL_EXPR_P, so this essentially does ifn |= 2 on little-endian.
STMT_IS_FULL_EXPR_P bit is used in:
cp-gimplify.c- if (STATEMENT_CODE_P (code))
cp-gimplify.c- {
cp-gimplify.c- saved_stmts_are_full_exprs_p = stmts_are_full_exprs_p ();
cp-gimplify.c- current_stmt_tree ()->stmts_are_full_exprs_p
cp-gimplify.c: = STMT_IS_FULL_EXPR_P (*expr_p);
cp-gimplify.c- }
and
pt.c- if (STATEMENT_CODE_P (TREE_CODE (t)))
pt.c: current_stmt_tree ()->stmts_are_full_exprs_p = STMT_IS_FULL_EXPR_P (t);
so besides being wrong on some other codes, it actually isn't beneficial at
all to set it on anything else, so the following patch restricts it to
trees with STATEMENT_CODE_P TREE_CODE.
2020-03-30 Jakub Jelinek <jakub@redhat.com>
PR c++/94385
* semantics.c (add_stmt): Only set STMT_IS_FULL_EXPR_P on trees with
STATEMENT_CODE_P code.
* c-c++-common/pr94385.c: New test.
|
|
This adds support to detect and recover from the case where an opening brace
immediately follows the start of a requires-clause. So rather than emitting the
error
error: expected primary-expression before '{' token
followed by a slew of irrevelant errors, we now assume the user had intended to
write "requires requires {" and diagnose and recover accordingly.
gcc/cp/ChangeLog:
PR c++/94306
* parser.c (cp_parser_requires_clause_opt): Diagnose and recover from
"requires {" when "requires requires {" was probably intended.
gcc/testsuite/ChangeLog:
PR c++/94306
* g++.dg/concepts/diagnostic8.C: New test.
|
|
This PR shows that a REQUIRES_EXPR outside of a template can sometimes be
misevaluated. This happens because the evaluation routine tsubst_requires_expr
(and diagnose_requires_expr) assumes the REQUIRES_EXPR's subtrees are templated
trees and that therefore it's safe to call tsubst_expr on them. But this
assumption isn't valid when we've parsed a REQUIRES_EXPR outside of a template
context. In order to make this assumption valid here, this patch sets
processing_template_decl to non-zero before parsing the body of a REQUIRES_EXPR
so that its subtrees are indeed always templated trees.
gcc/cp/ChangeLog:
PR c++/94252
* constraint.cc (tsubst_compound_requirement): Always suppress errors
from type_deducible_p and expression_convertible_p, as they're not
substitution errors.
(diagnose_atomic_constraint) <case INTEGER_CST>: Remove this case so
that we diagnose INTEGER_CST expressions of non-bool type via the
default case.
* cp-gimplify.c (cp_genericize_r) <case REQUIRES_EXPR>: New case.
* parser.c (cp_parser_requires_expression): Always parse the requirement
body as if we're processing a template, by temporarily incrementing
processing_template_decl. Afterwards, if we're not actually in a
template context, perform semantic processing to diagnose any invalid
types and expressions.
* pt.c (tsubst_copy_and_build) <case REQUIRES_EXPR>: Remove dead code.
* semantics.c (finish_static_assert): Explain an assertion failure
when the condition is a REQUIRES_EXPR like we do when it is a concept
check.
gcc/testsuite/ChangeLog:
PR c++/94252
* g++.dg/concepts/diagnostic7.C: New test.
* g++.dg/concepts/pr94252.C: New test.
* g++.dg/cpp2a/concepts-requires18.C: Adjust to expect an additional
diagnostic.
|
|
The previous patch tries to avoid changing our current default diagnostics. But
for the sake of consistency we arguably should also respect
current_constraint_diagnosis_depth in diagnose_compound_requirement() like we do
in the other error-replaying diagnostic routines. But doing so would be a
change to our default diagnostics behavior, so the change has been split out
into this separate patch for separate consideration.
gcc/cp/ChangeLog:
* constraint.cc (diagnose_compound_requirement): When diagnosing a
compound requirement, maybe replay the satisfaction failure, subject to
the current diagnosis depth.
gcc/testsuite/ChangeLog:
* g++.dg/concepts/diagnostic1.C: Pass -fconcepts-diagnostics-depth=2.
* g++.dg/concepts/diagnostic5.C: Adjust expected diagnostics.
* g++.dg/cpp2a/concepts-iconv1.C: Pass -fconcepts-diagnostics-depth=2.
* g++.dg/cpp2a/concepts-requires5.C: Likewise.
|
|
This patch adds a new flag -fconcepts-diagnostics-depth to the C++ frontend
which controls how deeply we replay errors when diagnosing a constraint
satisfaction failure. The default is -fconcepts-diagnostics-depth=1 which
diagnoses only the topmost constraint satisfaction failure and is consistent
with our behavior before this patch. By increasing this flag's value, the user
can control how deeply they want the compiler to explain a constraint
satisfaction error.
For example, if the unsatisfied constraint is a disjunction, then the default
behavior is to just say "no branch in the disjunction is satisfied", but with
-fconcepts-diagnostics-depth=2 we will additionally replay and diagnose the
error in each branch of the disjunction. And if the unsatisfied constraint is a
requires expression, then we will replay the error in the requires expression,
etc. This proceeds recursively until there is nothing more to replay or we
exceeded the maximum depth specified by the flag.
Implementation wise, this patch essentially just uncomments the existing
commented-out code that performs the error-replaying, and along the way adds
logic to keep track of and limit the current replay depth. Besides that, there
is a new routine collect_operands_of_disjunction which flattens a disjunction
and collects all of its operands into a vector.
The extra diagnostics enabled by this flag are at times longer than they need to
be (e.g. "the operand is_array_v<...> is unsatisfied because \n the expression
is_array_v<...> [with ...] evaluated to false") and not immediately easy to
follow (especially when there are nested disjunctions), but the transparency
provided by these optional diagnostics seems to be pretty helpful in practice.
gcc/c-family/ChangeLog:
* c.opt: Add -fconcepts-diagnostics-depth.
gcc/cp/ChangeLog:
* constraint.cc (finish_constraint_binary_op): Set the location of EXPR
as well as its range, because build_x_binary_op doesn't always do so.
(current_constraint_diagnosis_depth): New.
(concepts_diagnostics_max_depth_exceeded_p): New.
(collect_operands_of_disjunction): New.
(satisfy_disjunction): When diagnosing a satisfaction failure, maybe
replay each branch of the disjunction, subject to the current diagnosis
depth.
(diagnose_valid_expression): When diagnosing a satisfaction failure,
maybe replay the substitution error, subject to the current diagnosis
recursion.
(diagnose_valid_type): Likewise.
(diagnose_nested_requiremnet): Likewise.
(diagnosing_failed_constraint::diagnosing_failed_constraint): Increment
current_constraint_diagnosis_depth when diagnosing.
(diagnosing_failed_constraint::~diagnosing_failed_constraint): Decrement
current_constraint_diagnosis_depth when diagnosing.
(diagnosing_failed_constraint::replay_errors_p): New static member
function.
(diagnose_constraints): Don't diagnose if concepts_diagnostics_max_depth
is 0. Emit a one-off note to increase -fconcepts-diagnostics-depth if
the limit was exceeded.
* cp-tree.h (diagnosing_failed_constraint::replay_errors_p): Declare.
gcc/testsuite/ChangeLog:
* g++.dg/concepts/diagnostic2.C: Expect "no operand" instead of
"neither operand".
* g++.dg/concepts/diagnostic5.C: New test.
|
