| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
This fixes up the zero-initialization of the coro frame pointer
to avoid an unused assigned value, spotted by Martin Liska with
static analysis.
gcc/cp/ChangeLog:
* coroutines.cc (morph_fn_to_coro): Revise initialization
of the frame pointer to avoid an unused value.
|
|
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 changes satisfaction_value to accept INTEGER_CST of any
boolean type.
gcc/cp/ChangeLog:
PR c++/95386
* constraint.cc (satisfaction_value): Accept INTEGER_CST of any
boolean type.
gcc/testsuite/ChangeLog:
PR c++/95386
* g++.dg/concepts/pr95386.C: New test.
|
|
|
|
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.
Co-authored-by: Jason Merrill <jason@redhat.com>
|
|
any_template_parm_r was assuming that the DECL_TEMPLATE_RESULT of a template
will have a suitable TEMPLATE_INFO from which we can look at the generic
arguments for that template. But that wasn't true for a template template
parameter; this patch makes it so.
gcc/cp/ChangeLog:
PR c++/95371
* pt.c (process_template_parm): Set DECL_TEMPLATE_INFO
on the DECL_TEMPLATE_RESULT.
gcc/testsuite/ChangeLog:
PR c++/95371
* g++.dg/cpp2a/concepts-ttp1.C: New test.
|
|
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.
* c-c++-common/Wparentheses-2.c: New test.
|
|
We weren't able to find OBJ_TYPE_REF_OBJECT walking through
OBJ_TYPE_REF_EXPR because we had folded away the ADDR_EXPR.
gcc/cp/ChangeLog:
PR c++/95311
PR c++/95221
* class.c (build_vfn_ref): Don't fold the INDIRECT_REF.
gcc/testsuite/ChangeLog:
PR c++/95311
* g++.dg/ubsan/vptr-16.C: New test.
|
|
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.
Passes 'make check-c++', and also tested by building cmcstl2, does this
look OK to commit after a full bootstrap/regtest?
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.
|
|
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.
|
|
|
|
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.
* g++.dg/cpp1z/decomp53.C: New test.
|
|
In r9-297 I was trying to be more flexible and treat static data members of
class templates more like variable templates, where the type need not be
determined until the variable is instantiated, but I suppose that in a class
the types of all the non-template members need to be determined at the time
of class instantiation.
gcc/cp/ChangeLog:
PR c++/94926
* decl.c (cp_finish_decl): Revert r9-297 change.
(check_static_variable_definition): Likewise.
* constexpr.c (ensure_literal_type_for_constexpr_object): Likewise.
* pt.c (instantiate_decl): Return early on type error.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1z/pr86648.C: Expect error.
* g++.dg/cpp1z/static2.C: Expect error.
* g++.dg/cpp0x/nsdmi16.C: 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.
|
|
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.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/spaceship-synth2.C: Add
-Wzero-as-null-pointer-constant.
|
|
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.
gcc/cp/ChangeLog:
PR c++/95222
* decl.c (grokdeclarator): Don't shift attributes in TYPENAME
context.
gcc/testsuite/ChangeLog:
PR c++/95222
* g++.dg/ext/tmplattr10.C: New test.
|
|
Turns out templates are more complicated than you think, even when you
know they are more complicated than you think. Reverting this change.
PR c++/95263
* pt.c (lookup_template_class_1): Restore alias template mutation.
|
|
|
|
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.
|
|
Concept evaluation may entail DECL_UID generation and/or template
instantiation, so in general we can't perform it during uid-sensitive
constexpr evaluation.
gcc/cp/ChangeLog:
PR c++/94038
* constexpr.c (cxx_eval_constant_expression)
<case TEMPLATE_ID_EXPR>: Don't evaluate the concept when
constexpr evaluation is uid-sensitive.
gcc/testsuite/ChangeLog:
PR c++/94038
* g++.dg/warn/pr94038-3.C: New test.
|
|
In a function call expression in C++17 evaluation of the function pointer is
sequenced before evaluation of the function arguments, but that doesn't
apply to function calls that were written using operator syntax. In
particular, for operators with right-to-left ordering like assignment, we
must not evaluate the LHS to find a virtual function before we evaluate the
RHS.
gcc/cp/ChangeLog:
* cp-gimplify.c (cp_gimplify_expr) [CALL_EXPR]: Don't preevaluate
the function address if the call used operator syntax.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1z/eval-order9.C: New test.
|
|
With -fstrong-eval-order=all we evaluate the function address before the
arguments. But this caused trouble with virtual functions and
-fsanitize=vptr; we would do vptr sanitization as part of calculating the
'this' argument, and separately look at the vptr in order to find the
function address. Without -fstrong-eval-order=all 'this' is evaluated
first, but with that flag the function address is evaluated first, so we
would access the null vptr before sanitizing it.
Fixed by instrumenting the OBJ_TYPE_REF of a virtual function call instead
of the 'this' argument.
This issue suggests that we should be running the ubsan tests in multiple
standard modes like the rest of the G++ testsuite, so I've made that change
as well.
gcc/cp/ChangeLog:
* cp-ubsan.c (cp_ubsan_maybe_instrument_member_call): For a virtual
call, instrument the OBJ_TYPE_REF.
gcc/testsuite/ChangeLog:
* g++.dg/ubsan/ubsan.exp: Use g++-dg-runtest.
* c-c++-common/ubsan/bounds-13.c: Adjust.
* c-c++-common/ubsan/bounds-2.c: Adjust.
* c-c++-common/ubsan/div-by-zero-1.c: Adjust.
* c-c++-common/ubsan/div-by-zero-6.c: Adjust.
* c-c++-common/ubsan/div-by-zero-7.c: Adjust.
* c-c++-common/ubsan/overflow-add-1.c: Adjust.
* c-c++-common/ubsan/overflow-add-2.c: Adjust.
* c-c++-common/ubsan/overflow-int128.c: Adjust.
* c-c++-common/ubsan/overflow-sub-1.c: Adjust.
* c-c++-common/ubsan/overflow-sub-2.c: Adjust.
* g++.dg/ubsan/pr85029.C: Adjust.
* g++.dg/ubsan/vptr-14.C: Adjust.
|
|
We give a better diagnostic for non-constant array bounds in
compute_array_index_type_loc, we don't need to diagnose it in the parser.
But to avoid a regression on parse/varmod1.C we need to actually check
non-dependent expressions in a template.
gcc/cp/ChangeLog:
* decl.c (compute_array_index_type_loc): Diagnose expressions
in a template that can't be constant.
* parser.c (cp_parser_direct_declarator): Don't check
non-constant array bounds here.
gcc/testsuite/ChangeLog:
* c-c++-common/gomp/depend-iterator-2.c: Adjust.
* g++.dg/ext/vla1.C: Adjust.
* g++.dg/template/array9.C: Adjust.
* g++.dg/template/error41.C: Adjust.
|
|
The difference between a "potential" constant-expression and a regular
constant-expression is the treatment of parameters; in a constexpr function,
a parameter is potentially constant when evaluating a call to that function,
but it is not constant during parsing of the function.
cp_parser_constant_expression should check the latter rather than the
former.
gcc/cp/ChangeLog:
* cp-tree.h (is_rvalue_constant_expression): Declare.
* constexpr.c (is_rvalue_constant_expression): New.
* parser.c (cp_parser_constant_expression): Use it.
* decl.c (cp_finish_decl): Try to treat a constexpr initializer in a
template as constant.
|
|
In a template we were happily embedding error_mark_node in a MODOP_EXPR,
leading to confusion later.
gcc/cp/ChangeLog:
* typeck.c (build_x_modify_expr): Handle error_mark_node arguments.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/lambda/lambda-ice30.C: Adjust.
* g++.dg/cpp0x/lambda/lambda-ice31.C: Adjust.
* g++.dg/ext/fixed1.C: Adjust.
* g++.dg/template/crash107.C: Adjust.
* g++.dg/template/error35.C: Adjust.
* g++.dg/template/sizeof-template-argument.C: Adjust.
|
|
If a parameter is erroneous, we currently drop it, leading to "too many
arguments" errors later. Treating the function as (...) avoids those
errors.
gcc/cp/ChangeLog:
* decl.c (grokparms): Return NULL_TREE if any parms were erroneous.
gcc/testsuite/ChangeLog:
* g++.dg/parse/error33.C: Adjust.
|
|
co_returns are statements, not expressions; they do not need
to be wrapped in an EXPR_STMT.
gcc/cp/ChangeLog:
* coroutines.cc (finish_co_return_stmt): Revert change to use
finish_expr_stmt.
|
|
Unfortunately, the previous fix to PR94038 is fragile. When the
argument to fold_for_warn is a bare CALL_EXPR, then all is well: the
result of maybe_constant_value from fold_for_warn (with
uid_sensitive=true) is reused via the cv_cache in the subsequent call to
maybe_constant_value from cp_fold (with uid_sensitive=false), so we
avoid instantiating bar<int>.
But when the argument to fold_for_warn is more complex, e.g. an
INDIRECT_REF of a CALL_EXPR, as in the testcase below (due to bar<int>()
returning const int& which we need to decay to int) then from
fold_for_warn we call maybe_constant_value on the INDIRECT_REF, and from
cp_fold we call it on the CALL_EXPR, so there is no reuse via the
cv_cache and we therefore end up instantiating bar<int>.
So for a more robust solution to this general issue of warning flags
affecting code generation, it seems that we need a way to globally avoid
template instantiation during constexpr evaluation whenever we're
performing warning-dependent folding.
To that end, this patch replaces the flag constexpr_ctx::uid_sensitive
with a global flag uid_sensitive_constexpr_evaluation_p, and enables it
during fold_for_warn using an RAII helper.
The patch also adds a counter that keeps track of the number of times
uid_sensitive_constexpr_evaluation_p is called and returned true, and we
use this to determine whether the result of constexpr evaluation
was restricted by the flag. This lets us safely update the cv_cache and
fold_cache from fold_for_warn in the most common case where the flag
did not restrict constexpr evaluation.
gcc/cp/ChangeLog:
PR c++/94038
* constexpr.c (constexpr_ctx::uid_sensitive): Remove field.
(uid_sensitive_constexpr_evaluation_value): Define.
(uid_sensitive_constexpr_evaluation_true_counter): Define.
(uid_sensitive_constexpr_evaluation_p): Define.
(uid_sensitive_constexpr_evaluation_sentinel): Define its
constructor.
(uid_sensitive_constexpr_evaluation_checker): Define its
constructor and its evaluation_restricted_p method.
(get_fundef_copy): Remove 'ctx' parameter. Use u_s_c_e_p
instead of constexpr_ctx::uid_sensitive.
(cxx_eval_call_expression): Use u_s_c_e_p instead, and test it
last. Adjust call to get_fundef_copy.
(instantiate_cx_fn_r): Test u_s_c_e_p so that we increment the
counter if necessary.
(cxx_eval_outermost_constant_expr): Remove 'uid_sensitive'
parameter. Adjust function body accordingly.
(maybe_constant_value): Remove 'uid_sensitive' parameter and
adjust function body accordingly. Set up a
uid_sensitive_constexpr_evaluation_checker, and use it to
conditionally update the cv_cache.
* cp-gimplify.c (cp_fold): Set up a
uid_sensitive_constexpr_evaluation_checker, and use it to
conditionally update the fold_cache.
* cp-tree.h (maybe_constant_value): Update declaration.
(struct uid_sensitive_constexpr_evaluation_sentinel): Define.
(struct sensitive_constexpr_evaluation_checker): Define.
* expr.c (fold_for_warn): Set up a
uid_sensitive_constexpr_evaluation_sentinel before calling
the folding subroutines. Drop all but the first argument to
maybe_constant_value.
gcc/testsuite/ChangeLog:
PR c++/94038
* g++.dg/warn/pr94038-2.C: New test.
|
|
This patch implements DR 2237 which says that a simple-template-id is
no longer valid as the declarator-id of a constructor or destructor;
see [diff.cpp17.class]#2. It is not explicitly stated but out-of-line
destructors with a simple-template-id are also meant to be ill-formed
now. (Out-of-line constructors like that are invalid since DR1435 I
think.) This change only applies to C++20; it is not a DR against C++17.
I'm not crazy about the diagnostic in constructors but ISTM that
cp_parser_constructor_declarator_p shouldn't print errors.
DR 2237
* parser.c (cp_parser_unqualified_id): Reject simple-template-id as
the declarator-id of a destructor.
(cp_parser_constructor_declarator_p): Reject simple-template-id as
the declarator-id of a constructor.
* g++.dg/DRs/dr2237.C: New test.
* g++.dg/parse/constructor2.C: Add dg-error for C++20.
* g++.dg/parse/dtor12.C: Likewise.
* g++.dg/parse/dtor4.C: Likewise.
* g++.dg/template/dtor4.C: Adjust dg-error.
* g++.dg/template/error34.C: Likewise.
* g++.old-deja/g++.other/inline15.C: Only run for C++17 and lesses.
* g++.old-deja/g++.pt/ctor2.C: Add dg-error for C++20.
|
|
DR 2289 clarified that since structured bindings have no C compatibility
implications, they should be unique in their declarative region, see
[basic.scope.declarative]/4.2.
The duplicate_decls hunk is the gist of the patch, but that alone would
not be enough to detect the 'A' case: cp_parser_decomposition_declaration
uses
13968 tree decl2 = start_decl (declarator, &decl_specs, SD_INITIALIZED,
13969 NULL_TREE, NULL_TREE, &elt_pushed_scope);
to create the 'A' VAR_DECL but in this start_decl's grokdeclarator we
don't do fit_decomposition_lang_decl because the declarator kind is not
cdk_decomp, so then when start_decl calls maybe_push_decl, the decl 'A'
isn't DECL_DECOMPOSITION_P and we don't detect this case. So I needed a
way to signal to start_decl that it should fit_decomposition_lang_decl.
In this patch, I'm adding SD_DECOMPOSITION flag to say that the variable
is initialized and it should also be marked as DECL_DECOMPOSITION_P.
DR 2289
PR c++/94553
* cp-tree.h (SD_DECOMPOSITION): New flag.
* decl.c (duplicate_decls): Make sure a structured binding is unique
in its declarative region.
(start_decl): If INITIALIZED is SD_DECOMPOSITION, call
fit_decomposition_lang_decl.
(grokdeclarator): Compare INITIALIZED directly to SD_* flags.
* parser.c (cp_parser_decomposition_declaration): Pass SD_DECOMPOSITION
to start_decl.
* g++.dg/cpp1z/decomp52.C: New test.
|
|
After enabling sanitization of the specialization tables, we are
triggering one of the hash table sanity checks in the below testcase.
The reason is that when looking up the specialization j<int> in the
type_specializations table, the sanity check finds that the existing
entry j<n<t>::m> compares equal to j<int> but hashes differently.
The discrepancy is due to structural_comptypes looking through
TYPENAME_TYPEs (via resolve_typename_type), something which
iterative_hash_template_arg doesn't do. So the TYPENAME_TYPE n<t>::m is
considered equal to int, but the hashes of these two template arguments
are different.
It seems wrong for the result of a specialization table lookup to depend
on the current scope, so this patch makes structural_comptypes avoid
calling resolve_typename_type when comparing_specializations.
In order for the below testcase to deterministically trigger the
sanitization error without this patch, we also need to fix the location
of the call to hash_table::verify within hash_table::find_with_hash.
gcc/ChangeLog:
PR c++/95223
* hash-table.h (hash_table::find_with_hash): Move up the call to
hash_table::verify.
gcc/cp/ChangeLog:
PR c++/95223
* typeck.c (structural_comptypes): Don't perform
context-dependent resolution of TYPENAME_TYPEs when
comparing_specializations.
gcc/testsuite/ChangeLog:
PR c++/95223
* g++.dg/template/typename23.C: New test.
|
|
I discovered that the alias instantiation machinery would setup
template_info, and then sometime later overwrite that with equivalent
info. This broke modules, because the template info, once set, is
logically immutable. Let's just not do that.
* pt.c (lookup_template_class_1): Do not reinit template_info of an
alias here.
|
|
std::optional
gcc/cp/ChangeLog:
PR c++/94923
* call.c ((maybe_warn_class_memaccess): Use is_byte_access_type.
* cp-tree.h (is_dummy_object): Return bool.
(is_byte_access_type): Declare new function.
* tree.c (is_dummy_object): Return bool.
(is_byte_access_type): Define new function.
gcc/testsuite/ChangeLog:
PR c++/94923
* g++.dg/Wclass-memaccess.C: Add tests for std::byte.
|
|
It looks like hash table sanitization is now safe to enable for the
decl_specializations and type_specializations tables, probably ever
since PR94454 was fixed.
gcc/cp/ChangeLog:
PR c++/87847
* pt.c (init_template_processing): Enable sanitization for
decl_specializations and type_specializations.
|
|
In fn_type_unifcation, we are passing NULL_TREE as the 'in_decl'
parameter to coerce_template_parms, and this is causing template
type/value mismatch error messages to get suppressed regardless of the
value of 'complain'.
This means that when substitution into a function template fails due to
a type/value mismatch between a template parameter and the provided
template argument, we just say "template argument deduction/substitution
failed:" without a followup explanation of the failure.
Fix this by passing 'fn' instead of NULL_TREE to coerce_template_parms.
gcc/cp/ChangeLog:
PR c++/66439
* pt.c (fn_type_unification): Pass 'fn' instead of NULL_TREE as
the 'in_decl' parameter to coerce_template_parms.
gcc/testsuite/ChangeLog:
PR c++/66439
* g++.dg/cpp2a/concepts-ts4.C: Expect a "type/value mismatch"
diagnostic.
* g++.dg/cpp2a/concepts-ts6.C: Likewise.
* g++.dg/template/error56.C: Likewise.
* g++.dg/template/error59.C: New test.
libstdc++-v3/ChangeLog:
PR c++/66439
* testsuite/20_util/pair/astuple/get_neg.cc: Prune "type/value
mismatch" messages.
* testsuite/20_util/tuple/element_access/get_neg.cc: Likewise.
|
|
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.
* g++.dg/cpp0x/constexpr-shift2.C: New test.
|
|
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.
|
|
Until 92104 is fixed, let's sorry rather than crash.
PR c++/90915
* parser.c (cp_parser_has_attribute_expression): Sorry on a
type-dependent argument.
* g++.dg/ext/builtin-has-attribute.C: New test.
|
|
This patch resolves DR 1512 (and, by turn, DR 583). This entails:
1) Relational pointer comparisons against null pointer constants have
been made ill-formed:
void f(char *p) {
if (p > 0)
// ...
}
was always invalid in C but was -- accidentally -- allowed in C++.
2) This was ill-formed:
bool foo(int** x, const int** y) {
return x < y;
}
because 'int**' couldn't be converted to 'const int**'. This was
fixed by re-defining a generic composite pointer type. The composite
type of these two pointers will be 'const int *const *', to which
both pointers can be converted.
3) The overload descriptions for built-in operators were adjusted,
because objects of type std::nullptr_t cannot be used with relational
operators any more.
I fixed 1) by adjusting cp_build_binary_op; we already had a warning
for it so made it a hard error now.
Then 2) required tweaking composite_pointer_type_r. [expr.type] defines
the composite pointer type by using the "cv-combined type." We didn't
implement the [conv.qual]/3.3 part; previously the composite type of
'int**' and 'const int**' was 'const int**', so this didn't compile:
void f(const int **p, int **q) {
true ? p : q;
}
I wrote a more extensive test for this which uses decltype and some
template magic to check the composite type, see composite-ptr-type.C.
We still don't handle everything that [expr.type] requires us to,
but it's pretty close.
And finally 3) was handled in add_builtin_candidate. Turned out we
weren't creating built-in operator candidates when the type was
std::nullptr_t at all. We should, for == and !=. Tested in builtin4.C.
In passing, I'm fixing some of the comments too.
DR 1512
PR c++/87699
* call.c (add_builtin_candidate) <case EQ_EXPR>: Create candidate
operator functions when type is std::nullptr_t for ==/!=.
* typeck.c (composite_pointer_type_r): Add bool a * parameter. Use it
to maybe add "const" to the pointer type.
(composite_pointer_type): Update the call to composite_pointer_type_r.
(cp_build_binary_op): Turn two warning_at into error_at. Print the
types.
* g++.dg/cpp0x/constexpr-array-ptr10.C: Change dg-warning to dg-error
and adjust the expected messages in dg-error.
* g++.dg/expr/composite-ptr-type.C: New test.
* g++.dg/expr/ptr-comp1.C: New test.
* g++.dg/expr/ptr-comp2.C: New test.
* g++.dg/expr/ptr-comp3.C: New test.
* g++.dg/overload/builtin4.C: New test.
* g++.dg/warn/Wextra-3.C: Change dg-warning to dg-error.
|
|
In a couple of places in build_over_call we were calling
cp_stabilize_reference but only using the result once, so it isn't needed.
gcc/cp/ChangeLog
2020-05-18 Jason Merrill <jason@redhat.com>
* call.c (build_over_call): Remove unnecessary
cp_stabilize_reference.
|
|
This feels extremely obscure but at least it's an opportunity to fix the
comments. P0002R1 removed deprecated operator++(bool) in C++17 so let's
avoid adding a builtin overload candidate for ++ when the type is bool.
* call.c (add_builtin_candidate): Don't create a builtin overload
candidate for ++ when type is bool in C++17.
* g++.dg/overload/builtin5.C: New test.
|
|
Current cfns.h includes register-qualified variables and that wouldn't
play well when bootstrapping with GCC that uses the C++17 dialect,
because 'register' was removed in C++17. Regenerating it using the
command specified in cfns.h luckily cleaned this up.
* cfns.h: Regenerated.
|
|
This avoids a (bogus) warning that occurs with some bootstrap
compilers.
gcc/cp/ChangeLog:
2020-05-17 Iain Sandoe <iain@sandoe.co.uk>
* coroutines.cc (morph_fn_to_coro): Initialize the
gro variable.
|
|
This is a case where the standard contains conflicting information.
after discussion between implementators, the accepted intent is of
[class.copy.elision]. This amends the handling of co_return statements
to follow that.
gcc/cp/ChangeLog:
2020-05-16 Iain Sandoe <iain@sandoe.co.uk>
* coroutines.cc (finish_co_return_stmt): Implement rules
from [class.copy.elision] /3.
gcc/testsuite/ChangeLog:
2020-05-16 Iain Sandoe <iain@sandoe.co.uk>
* g++.dg/coroutines/co-return-syntax-10-movable.C: New test.
|
|
We sometimes fail to reject an invalid non-dependent operand to decltype
when inside a template, because finish_decltype_type resolves the
decltype to the TREE_TYPE of the operand before we ever instantiate and
fully process the operand. Fix this by adding a call to
instantiate_non_dependent_expr_sfinae in finish_decltype_type.
gcc/cp/ChangeLog:
PR c++/57943
* semantics.c (finish_decltype_type): Call
instantiate_non_dependent_expr_sfinae on the expression.
gcc/testsuite/ChangeLog:
PR c++/57943
* g++.dg/cpp0x/decltype76.C: New test.
|
|
The process_init_constructor_array part of my PR90996 patch turns out to
be neither necessary nor sufficient to make the pr90996.C testcase work,
and I wasn't able to come up with a testcase that demonstrates this part
is ever necessary.
gcc/cp/ChangeLog:
Revert:
2020-04-07 Patrick Palka <ppalka@redhat.com>
PR c++/90996
* 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: Turn into execution test to verify
that each PLACEHOLDER_EXPR gets correctly resolved.
|
|
My GCC 10 patch for 93286 fixed the missing piece in tsubst's handling of
lists vs. that in tsubst_copy_and_build, but it would be better to share the
code between them.
gcc/cp/ChangeLog
2020-05-15 Jason Merrill <jason@redhat.com>
PR c++/93286 - ICE with __is_constructible and variadic template.
* pt.c (tsubst_tree_list): New.
(tsubst, tsubst_copy_and_build): Use it.
* decl2.c (is_late_template_attribute): Handle error_mark_node args.
|
|
Arseny Solokha noticed I'd flubbed this patch, and it was not saying
what I thought it was saying. Unfortunately that didn't break
anything (otherwise I'd've noticed). Fixed thusly.
* pt.c (template_args_equal): Fix thinkos in previous 'cleanup'.
|
|
My change in r10-4394 to only update clones when we actually instantiate a
deferred noexcept-spec broke this because deferred parsing updates the
primary function but not the clones. For GCC 10 I just reverted that
change; this patch adjusts maybe_instantiate_noexcept to update only the
clone passed as the argument.
gcc/cp/ChangeLog
2020-05-14 Jason Merrill <jason@redhat.com>
PR c++/93901
* pt.c (maybe_instantiate_noexcept): Change clone handling.
|
