aboutsummaryrefslogtreecommitdiff
path: root/gcc/cp/decl.cc
AgeCommit message (Collapse)AuthorFilesLines
2022-10-13c++: trivial formatting cleanupsJason Merrill1-2/+0
Split out from the C++ contracts patch. gcc/cp/ChangeLog: * cp-tree.h: Fix whitespace. * parser.h: Fix whitespace. * decl.cc: Fix whitespace. * parser.cc: Fix whitespace. * pt.cc: Fix whitespace.
2022-10-07c++: track whether we expect a TARGET_EXPR to be elidedJason Merrill1-1/+1
A discussion at Cauldron made me think that with the formalization of copy elision in C++17, we should be able to determine before optimization which TARGET_EXPRs will become temporaries and which are initializers. This patch implements that: we set TARGET_EXPR_ELIDING_P if it's used as an initializer, and later check that we were right. There's an exception in the cp_gimplify_expr check to allow extra temporaries of non-addressable type: this is used by gimplify_init_ctor_preeval to materialize subobjects of a CONSTRUCTOR on the rhs of a MODIFY_EXPR rather than materializing the whole object. If the type isn't addressable, there's no way for a program to tell the difference, so this is a valid optimization. I considered changing replace_placeholders_for_class_temp_r to check TARGET_EXPR_ELIDING_P instead of potential_prvalue_result_of, but decided that would be wrong: if we have an eliding TARGET_EXPR inside a non-eliding one, we would miss replacing its placeholders. gcc/cp/ChangeLog: * cp-tree.h (TARGET_EXPR_ELIDING_P): New. (unsafe_copy_elision_p, set_target_expr_eliding) (cp_build_init_expr): Declare. * call.cc (unsafe_copy_elision_p): No longer static. (build_over_call, build_special_member_call) (build_new_method_call): Use cp_build_init_expr. * coroutines.cc (expand_one_await_expression) (build_actor_fn, flatten_await_stmt, handle_nested_conditionals) (await_statement_walker, morph_fn_to_coro): Use cp_build_init_expr. * cp-gimplify.cc (cp_gimplify_init_expr) (cp_gimplify_expr): Check TARGET_EXPR_ELIDING_P. (cp_fold_r): Propagate it. (cp_fold): Use cp_build_init_expr. * decl.cc (check_initializer): Use cp_build_init_expr. * except.cc (build_throw): Use cp_build_init_expr. * init.cc (get_nsdmi): Call set_target_expr_eliding. (perform_member_init, expand_default_init, expand_aggr_init_1) (build_new_1, build_vec_init): Use cp_build_init_expr. * method.cc (do_build_copy_constructor): Use cp_build_init_expr. * semantics.cc (simplify_aggr_init_expr, finalize_nrv_r) (finish_omp_reduction_clause): Use cp_build_init_expr. * tree.cc (build_target_expr): Call set_target_expr_eliding. (bot_manip): Copy TARGET_EXPR_ELIDING_P. * typeck.cc (cp_build_modify_expr): Call set_target_expr_eliding. (check_return_expr): Use cp_build_modify_expr. * typeck2.cc (split_nonconstant_init_1) (split_nonconstant_init): Use cp_build_init_expr. (massage_init_elt): Call set_target_expr_eliding. (process_init_constructor_record): Clear TARGET_EXPR_ELIDING_P on unsafe copy elision. (set_target_expr_eliding, cp_build_init_expr): New.
2022-10-03c++: Disallow jumps into statement expressionsJakub Jelinek1-3/+16
On Fri, Sep 30, 2022 at 04:39:25PM -0400, Jason Merrill wrote: > > --- gcc/cp/decl.cc.jj 2022-09-22 00:14:55.478599363 +0200 > > +++ gcc/cp/decl.cc 2022-09-22 00:24:01.121178256 +0200 > > @@ -223,6 +223,7 @@ struct GTY((for_user)) named_label_entry > > bool in_transaction_scope; > > bool in_constexpr_if; > > bool in_consteval_if; > > + bool in_assume; > > I think it would be better to reject jumps into statement-expressions like > the C front-end. Ok, here is a self-contained patch that does that. 2022-10-03 Jakub Jelinek <jakub@redhat.com> * cp-tree.h (BCS_STMT_EXPR): New enumerator. * name-lookup.h (enum scope_kind): Add sk_stmt_expr. * name-lookup.cc (begin_scope): Handle sk_stmt_expr like sk_block. * semantics.cc (begin_compound_stmt): For BCS_STMT_EXPR use sk_stmt_expr. * parser.cc (cp_parser_statement_expr): Use BCS_STMT_EXPR instead of BCS_NORMAL. * decl.cc (struct named_label_entry): Add in_stmt_expr. (poplevel_named_label_1): Handle sk_stmt_expr. (check_previous_goto_1): Diagnose entering of statement expression. (check_goto): Likewise. * g++.dg/ext/stmtexpr24.C: New test.
2022-09-27c++: Implement C++23 P1169R4 - static operator() [PR106651]Jakub Jelinek1-1/+18
The following patch attempts to implement C++23 P1169R4 - static operator() paper's compiler side (there is some small library side too not implemented yet). This allows static members as user operator() declarations and static specifier on lambdas without lambda capture. The synthetized conversion operator changes for static lambdas as it can just return the operator() static method address, doesn't need to create a thunk for it. The change in call.cc (joust) is to avoid ICEs because we assumed that len could be different only if both candidates are direct calls but it can be one direct and one indirect call, and to implement the [over.match.best.general]/1 and [over.best.ics.general] changes from the paper (implemented always as Jason is sure it doesn't make a difference in C++20 and earlier unless static member function operator() or static lambda which we accept with pedwarn in earlier standards too appears and my testing confirmed that). 2022-09-27 Jakub Jelinek <jakub@redhat.com> PR c++/106651 gcc/c-family/ * c-cppbuiltin.cc (c_cpp_builtins): Predefine __cpp_static_call_operator=202207L for C++23. gcc/cp/ * cp-tree.h (LAMBDA_EXPR_STATIC_P): Implement C++23 P1169R4 - static operator(). Define. * parser.cc (CP_PARSER_FLAGS_ONLY_MUTABLE_OR_CONSTEXPR): Document that it also allows static. (cp_parser_lambda_declarator_opt): Handle static lambda specifier. (cp_parser_decl_specifier_seq): Allow RID_STATIC for CP_PARSER_FLAGS_ONLY_MUTABLE_OR_CONSTEXPR. * decl.cc (grok_op_properties): If operator() isn't a method, use a different error wording, if it is static member function, allow it (for C++20 and older with a pedwarn unless it is a lambda function or template instantiation). * call.cc (joust): Don't ICE if one candidate is static member function and the other is an indirect call. If the parameter conversion on the other candidate is user defined conversion, ellipsis or bad conversion, make static member function candidate a winner for that parameter. * lambda.cc (maybe_add_lambda_conv_op): Handle static lambdas. * error.cc (dump_lambda_function): Print static for static lambdas. gcc/testsuite/ * g++.dg/template/error30.C: Adjust expected diagnostics. * g++.dg/cpp1z/constexpr-lambda13.C: Likewise. * g++.dg/cpp23/feat-cxx2b.C: Test __cpp_static_call_operator. * g++.dg/cpp23/static-operator-call1.C: New test. * g++.dg/cpp23/static-operator-call2.C: New test. * g++.old-deja/g++.jason/operator.C: Adjust expected diagnostics.
2022-09-27c++: Improve diagnostics about conflicting specifiersJakub Jelinek1-6/+1
On Sat, Sep 17, 2022 at 01:23:59AM +0200, Jason Merrill wrote: > I wonder why we don't give an error when setting the > conflicting_specifiers_p flag in cp_parser_set_storage_class? We should be > able to give a better diagnostic at that point. I didn't have time to update the whole patch last night, but this part seems to be independent and I've managed to test it. The diagnostics then looks like: a.C:1:9: error: ‘static’ specifier conflicts with ‘typedef’ 1 | typedef static int a; | ~~~~~~~ ^~~~~~ a.C:2:8: error: ‘typedef’ specifier conflicts with ‘static’ 2 | static typedef int b; | ~~~~~~ ^~~~~~~ a.C:3:8: error: duplicate ‘static’ specifier 3 | static static int c; | ~~~~~~ ^~~~~~ a.C:4:8: error: ‘extern’ specifier conflicts with ‘static’ 4 | static extern int d; | ~~~~~~ ^~~~~~ 2022-09-27 Jakub Jelinek <jakub@redhat.com> gcc/cp/ * parser.cc (cp_parser_lambda_declarator_opt): Don't diagnose conflicting specifiers here. (cp_storage_class_name): New variable. (cp_parser_decl_specifier_seq): When setting conflicting_specifiers_p for the first time, diagnose which exact specifiers conflict. (cp_parser_set_storage_class): Likewise. Move storage_class computation earlier. * decl.cc (grokdeclarator): Don't diagnose conflicting specifiers here, just return error_mark_node. gcc/testsuite/ * g++.dg/diagnostic/conflicting-specifiers-1.C: Adjust expected diagnostics. * g++.dg/parse/typedef8.C: Likewise. * g++.dg/parse/crash39.C: Likewise. * g++.dg/other/mult-stor1.C: Likewise. * g++.dg/cpp2a/constinit3.C: Likewise.
2022-09-20c++: modules and non-dependent auto deductionPatrick Palka1-0/+6
The modules streaming code seems to rely on the invariant that a TEMPLATE_DECL and its DECL_TEMPLATE_RESULT have the same TREE_TYPE. But for a non-dependent VAR_DECL with deduced type, the two TREE_TYPEs end up diverging: cp_finish_decl deduces the type of the initializer ahead of time and updates the TREE_TYPE of the VAR_DECL, but neglects to update the corresponding TEMPLATE_DECL as well, which leads to a "conflicting global module declaration" error for each of the __phase_alignment decls in the below testcase (and for the xtreme-header tests if we try including <barrier>). This patch makes cp_finish_decl update the TREE_TYPE of the corresponding TEMPLATE_DECL so that the invariant is maintained. gcc/cp/ChangeLog: * decl.cc (cp_finish_decl): After updating the deduced type of a VAR_DECL, also update the corresponding TEMPLATE_DECL if there is one. gcc/testsuite/ChangeLog: * g++.dg/modules/auto-3.h: New test. * g++.dg/modules/auto-3_a.H: New test. * g++.dg/modules/auto-3_b.C: New test.
2022-09-15Move void_list_node init to common codeRichard Biener1-9/+1
All frontends replicate this, so move it. gcc/ * tree.cc (build_common_tree_nodes): Initialize void_list_node here. gcc/ada/ * gcc-interface/trans.cc (gigi): Do not initialize void_list_node. gcc/c-family/ * c-common.h (build_void_list_node): Remove. * c-common.cc (c_common_nodes_and_builtins): Do not initialize void_list_node. gcc/c/ * c-decl.cc (build_void_list_node): Remove. gcc/cp/ * decl.cc (cxx_init_decl_processing): Inline last build_void_list_node call. (build_void_list_node): Remove. gcc/d/ * d-builtins.cc (d_build_c_type_nodes): Do not initialize void_list_node. gcc/fortran/ * f95-lang.cc (gfc_init_decl_processing): Do not initialize void_list_node. gcc/go/ * go-lang.cc (go_langhook_init): Do not initialize void_list_node. gcc/jit/ * dummy-frontend.cc (jit_langhook_init): Do not initialize void_list_node. gcc/lto/ * lto-lang.cc (lto_build_c_type_nodes): Do not initialize void_list_node.
2022-09-13c++: two-parameter version of cxx_constant_valuePatrick Palka1-1/+1
Since some callers need the complain parameter but not the object parameter, let's introduce and use an overload of cxx_constant_value that omits the latter. gcc/cp/ChangeLog: * cp-tree.h (cxx_constant_value): Define two-parameter version that omits the object parameter. * decl.cc (build_explicit_specifier): Omit NULL_TREE object argument to cxx_constant_value. * except.cc (build_noexcept_spec): Likewise. * pt.cc (expand_integer_pack): Likewise. (fold_targs_r): Likewise. * semantics.cc (finish_if_stmt_cond): Likewise.
2022-09-13c++: some missing-SFINAE fixesPatrick Palka1-1/+1
It looks like we aren't respecting SFINAE for: * an invalid/non-constant conditional explicit-specifier * a non-constant conditional noexcept-specifier * a non-constant argument to __integer_pack This patch fixes these in the usual way, by passing complain and propagating error_mark_node appropriately. gcc/cp/ChangeLog: * decl.cc (build_explicit_specifier): Pass complain to cxx_constant_value. * except.cc (build_noexcept_spec): Likewise. * pt.cc (expand_integer_pack): Likewise. (tsubst_function_decl): Propagate error_mark_node returned from build_explicit_specifier. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/noexcept-type26.C: New test. * g++.dg/cpp2a/explicit19.C: New test. * g++.dg/ext/integer-pack6.C: New test.
2022-09-12c++: remove '_sfinae' suffix from functionsPatrick Palka1-1/+1
The functions abstract_virtuals_error cxx_constant_value get_target_expr instantiate_non_dependent_expr require_complete_type are each just a non-SFINAE-enabled wrapper for the corresponding SFINAE-enabled version that's suffixed by '_sfinae'. But this suffix is at best redundant since a 'complain' parameter already broadly conveys that a function is SFINAE-enabled, and having two such versions of a function is less concise than just using a default argument for 'complain' (and arguably no less mistake prone). So this patch squashes the two versions of each of the above functions by adding a default 'complain' argument to the SFINAE-enabled version whose '_sfinae' suffix we then remove. gcc/cp/ChangeLog: * call.cc (build_conditional_expr): Adjust calls to '_sfinae'-suffixed functions. (build_temp): Likewise. (convert_like_internal): Likewise. (convert_arg_to_ellipsis): Likewise. (build_over_call): Likewise. (build_cxx_call): Likewise. (build_new_method_call): Likewise. * constexpr.cc (cxx_eval_outermost_constant_expr): Likewise. (cxx_constant_value_sfinae): Rename to ... (cxx_constant_value): ... this. Document its default arguments. (fold_non_dependent_expr): Adjust function comment. * cp-tree.h (instantiate_non_dependent_expr_sfinae): Rename to ... (instantiate_non_dependent_expr): ... this. Give its 'complain' parameter a default argument. (get_target_expr_sfinae, get_target_expr): Likewise. (require_complete_type_sfinae, require_complete_type): Likewise. (abstract_virtuals_error_sfinae, abstract_virtuals_error): Likewise. (cxx_constant_value_sfinae, cxx_constant_value): Likewise. * cvt.cc (build_up_reference): Adjust calls to '_sfinae'-suffixed functions. (ocp_convert): Likewise. * decl.cc (build_explicit_specifier): Likewise. * except.cc (build_noexcept_spec): Likewise. * init.cc (build_new_1): Likewise. * pt.cc (expand_integer_pack): Likewise. (instantiate_non_dependent_expr_internal): Adjust function comment. (instantiate_non_dependent_expr): Rename to ... (instantiate_non_dependent_expr_sfinae): ... this. Document its default argument. (tsubst_init): Adjust calls to '_sfinae'-suffixed functions. (fold_targs_r): Likewise. * semantics.cc (finish_compound_literal): Likewise. (finish_decltype_type): Likewise. (cp_build_bit_cast): Likewise. * tree.cc (build_cplus_new): Likewise. (get_target_expr): Rename to ... (get_target_expr_sfinae): ... this. Document its default argument. * typeck.cc (require_complete_type): Rename to ... (require_complete_type_sfinae): ... this. Document its default argument. (cp_build_array_ref): Adjust calls to '_sfinae'-suffixed functions. (convert_arguments): Likewise. (cp_build_binary_op): Likewise. (build_static_cast_1): Likewise. (cp_build_modify_expr): Likewise. (convert_for_initialization): Likewise. * typeck2.cc (abstract_virtuals_error): Rename to ... (abstract_virtuals_error_sfinae): ... this. Document its default argument. (build_functional_cast_1): Adjust calls to '_sfinae'-suffixed functions.
2022-09-12c++: auto member function and auto variable [PR106893]Jason Merrill1-0/+3
As with PR105623, we need to call mark_single_function sooner to resolve the type of a BASELINK. PR c++/106893 PR c++/90451 gcc/cp/ChangeLog: * decl.cc (cp_finish_decl): Call mark_single_function. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/auto-fn65.C: New test.
2022-09-07c++: diagnostic for template placeholder in parm [PR106793]Jason Merrill1-10/+20
Talking about the declarator form doesn't help when fixing that would get you a different error about placeholders not being valid in a parameter. This also adds a <> fixit, which isn't enough for most templates, but is a start. PR c++/106793 gcc/cp/ChangeLog: * decl.cc (grokdeclarator): Improve placeholder diagnostics. * parser.cc (cp_parser_type_id_1): Add fixit. gcc/testsuite/ChangeLog: * g++.dg/cpp23/auto-array2.C: Adjust. * g++.dg/cpp1z/class-deduction113.C: New test.
2022-09-06c++: C++23 operator[] allows default argumentsJason Merrill1-6/+5
This usage was intended to be allowed by P2128, but it didn't make it into the final wording. Fixed by CWG 2507. DR2507 gcc/cp/ChangeLog: * decl.cc (grok_op_properties): Return sooner for C++23 op[]. gcc/testsuite/ChangeLog: * g++.dg/cpp23/subscript8.C: New test.
2022-08-29c++: Fix C++11 attribute propagation [PR106712]Marek Polacek1-1/+1
When we have [[noreturn]] int fn1 [[nodiscard]](), fn2(); "noreturn" should apply to both fn1 and fn2 but "nodiscard" only to fn1: [dcl.pre]/3: "The attribute-specifier-seq appertains to each of the entities declared by the declarators of the init-declarator-list." [dcl.spec.general]: "The attribute-specifier-seq affects the type only for the declaration it appears in, not other declarations involving the same type." As Ed Catmur correctly analyzed, this is because, for the test above, we call start_decl with prefix_attributes=noreturn, but this line: attributes = attr_chainon (attributes, prefix_attributes); results in attributes == prefix_attributes, because chainon sees that attributes is null so it just returns prefix_attributes. Then in grokdeclarator we reach *attrlist = attr_chainon (*attrlist, declarator->std_attributes); which modifies prefix_attributes so now it's "noreturn, nodiscard" and so fn2 is wrongly marked nodiscard as well. Fixed by reversing the order of arguments to attr_chainon. That way, we tack the prefix attributes onto ->std_attributes, avoiding modifying prefix_attributes. PR c++/106712 gcc/cp/ChangeLog: * decl.cc (grokdeclarator): Reverse the order of arguments to attr_chainon. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/gen-attrs-77.C: New test.
2022-08-25c: Implement C23 nullptr (N3042)Marek Polacek1-7/+1
This patch implements the C23 nullptr literal: <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3042.htm> (with wording fixes from N3047), which is intended to replace the problematic definition of NULL which might be either of integer type or void*. Since C++ has had nullptr for over a decade now, it was relatively easy to just move the built-in node definitions from the C++ FE to the C/C++ common code. Also, our DWARF emitter already handles NULLPTR_TYPE by emitting DW_TAG_unspecified_type. However, I had to handle a lot of contexts such as ?:, comparison, conversion, etc. There are some minor differences, e.g. in C you can do bool b = nullptr; but in C++ you have to use direct-initialization: bool b{nullptr}; And I think that nullptr_t n = 0; is only valid in C++. Of course, C doesn't have to handle mangling, RTTI, substitution, overloading, ... This patch also defines nullptr_t in <stddef.h>. However, it does not define __STDC_VERSION_STDDEF_H__ yet, because we don't know yet what value it should be defined to. gcc/c-family/ChangeLog: * c-common.cc (c_common_reswords): Enable nullptr in C2X. (c_common_nodes_and_builtins): Create the built-in node for nullptr. * c-common.h (enum c_tree_index): Add CTI_NULLPTR, CTI_NULLPTR_TYPE. (struct c_common_resword): Resize the disable member. (D_C2X): Add. (nullptr_node): Define. (nullptr_type_node): Define. (NULLPTR_TYPE_P): Define. * c-pretty-print.cc (c_pretty_printer::simple_type_specifier): Handle NULLPTR_TYPE. (c_pretty_printer::direct_abstract_declarator): Likewise. (c_pretty_printer::constant): Likewise. gcc/c/ChangeLog: * c-convert.cc (c_convert) <case POINTER_TYPE>: Handle NULLPTR_TYPE. Give a better diagnostic when converting to nullptr_t. * c-decl.cc (c_init_decl_processing): Perform C-specific nullptr initialization. * c-parser.cc (c_parse_init): Maybe OR D_C2X into mask. (c_parser_postfix_expression): Handle RID_NULLPTR. * c-typeck.cc (null_pointer_constant_p): Return true when expr is nullptr_node. (build_unary_op) <case TRUTH_NOT_EXPR>: Handle NULLPTR_TYPE. (build_conditional_expr): Handle the case when the second/third operand is NULLPTR_TYPE and third/second operand is POINTER_TYPE. (convert_for_assignment): Handle converting an expression of type nullptr_t to pointer/bool. (build_binary_op) <case TRUTH_XOR_EXPR>: Handle NULLPTR_TYPE. <case EQ_EXPR>: Handle comparing operands of type nullptr_t. gcc/cp/ChangeLog: * cp-tree.h (enum cp_tree_index): Remove CTI_NULLPTR, CTI_NULLPTR_TYPE. Move it to c_tree_index. (nullptr_node): No longer define here. (nullptr_type_node): Likewise. (NULLPTR_TYPE_P): Likewise. * decl.cc (cxx_init_decl_processing): Only keep C++-specific nullptr initialization; move the shared code to c_common_nodes_and_builtins. gcc/ChangeLog: * ginclude/stddef.h: Define nullptr_t. gcc/testsuite/ChangeLog: * gcc.dg/c11-nullptr-1.c: New test. * gcc.dg/c17-nullptr-1.c: New test. * gcc.dg/c17-nullptr-2.c: New test. * gcc.dg/c2x-nullptr-1.c: New test. * gcc.dg/c2x-nullptr-2.c: New test. * gcc.dg/c2x-nullptr-3.c: New test. * gcc.dg/c2x-nullptr-4.c: New test. * gcc.dg/c2x-nullptr-5.c: New test.
2022-08-17c++: Extend -Wpessimizing-move to other contextsMarek Polacek1-1/+2
In my recent patch which enhanced -Wpessimizing-move so that it warns about class prvalues too I said that I'd like to extend it so that it warns in more contexts where a std::move can prevent copy elision, such as: T t = std::move(T()); T t(std::move(T())); T t{std::move(T())}; T t = {std::move(T())}; void foo (T); foo (std::move(T())); This patch does that by adding two maybe_warn_pessimizing_move calls. These must happen before we've converted the initializers otherwise the std::move will be buried in a TARGET_EXPR. PR c++/106276 gcc/cp/ChangeLog: * call.cc (build_over_call): Call maybe_warn_pessimizing_move. * cp-tree.h (maybe_warn_pessimizing_move): Declare. * decl.cc (build_aggr_init_full_exprs): Call maybe_warn_pessimizing_move. * typeck.cc (maybe_warn_pessimizing_move): Handle TREE_LIST and CONSTRUCTOR. Add a bool parameter and use it. Adjust a diagnostic message. (check_return_expr): Adjust the call to maybe_warn_pessimizing_move. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/Wpessimizing-move7.C: Add dg-warning. * g++.dg/cpp0x/Wpessimizing-move8.C: New test.
2022-08-17OpenMP/C++: Allow classes with static members to be mappable [PR104493]Tobias Burnus1-2/+4
As this is the last lang-specific user of the omp_mappable_type hook, the hook is removed, keeping only a generic omp_mappable_type for incomplete types (or error_node). PR c++/104493 gcc/c/ChangeLog: * c-decl.cc (c_decl_attributes, finish_decl): Call omp_mappable_type instead of removed langhook. * c-typeck.cc (c_finish_omp_clauses): Likewise. gcc/cp/ChangeLog: * cp-objcp-common.h (LANG_HOOKS_OMP_MAPPABLE_TYPE): Remove. * cp-tree.h (cp_omp_mappable_type, cp_omp_emit_unmappable_type_notes): Remove. * decl2.cc (cp_omp_mappable_type_1, cp_omp_mappable_type, cp_omp_emit_unmappable_type_notes): Remove. (cplus_decl_attributes): Call omp_mappable_type instead of removed langhook. * decl.cc (cp_finish_decl): Likewise; call cxx_incomplete_type_inform in lieu of cp_omp_emit_unmappable_type_notes. * semantics.cc (finish_omp_clauses): Likewise. gcc/ChangeLog: * gimplify.cc (omp_notice_variable): Call omp_mappable_type instead of removed langhook. * omp-general.h (omp_mappable_type): New prototype. * omp-general.cc (omp_mappable_type): New; moved from ... * langhooks.cc (lhd_omp_mappable_type): ... here. * langhooks-def.h (lhd_omp_mappable_type, LANG_HOOKS_OMP_MAPPABLE_TYPE): Remove. (LANG_HOOKS_FOR_TYPES_INITIALIZER): Remote the latter. * langhooks.h (struct lang_hooks_for_types): Remove omp_mappable_type. gcc/testsuite/ChangeLog: * g++.dg/gomp/unmappable-1.C: Remove dg-error; remove dg-note no longer shown as TYPE_MAIN_DECL is NULL. * c-c++-common/gomp/map-incomplete-type.c: New test. Co-authored-by: Chung-Lin Tang <cltang@codesourcery.com>
2022-08-11c-family: Honor -Wno-init-self for cv-qual vars [PR102633]Marek Polacek1-0/+8
Since r11-5188-g32934a4f45a721, we drop qualifiers during l-to-r conversion by creating a NOP_EXPR. For e.g. const int i = i; that means that the DECL_INITIAL is '(int) i' and not 'i' anymore. Consequently, we don't suppress_warning here: 711 case DECL_EXPR: 715 if (VAR_P (DECL_EXPR_DECL (*expr_p)) 716 && !DECL_EXTERNAL (DECL_EXPR_DECL (*expr_p)) 717 && !TREE_STATIC (DECL_EXPR_DECL (*expr_p)) 718 && (DECL_INITIAL (DECL_EXPR_DECL (*expr_p)) == DECL_EXPR_DECL (*expr_p)) 719 && !warn_init_self) 720 suppress_warning (DECL_EXPR_DECL (*expr_p), OPT_Winit_self); because of the check on line 718 -- (int) i is not i. So -Wno-init-self doesn't disable the warning as it's supposed to. The following patch fixes it by moving the suppress_warning call from c_gimplify_expr to the front ends, at points where we haven't created the NOP_EXPR yet. PR middle-end/102633 gcc/c-family/ChangeLog: * c-gimplify.cc (c_gimplify_expr) <case DECL_EXPR>: Don't call suppress_warning here. gcc/c/ChangeLog: * c-parser.cc (c_parser_initializer): Add new tree parameter. Use it. Call suppress_warning. (c_parser_declaration_or_fndef): Pass d down to c_parser_initializer. (c_parser_omp_declare_reduction): Pass omp_priv down to c_parser_initializer. gcc/cp/ChangeLog: * decl.cc (cp_finish_decl): Call suppress_warning. gcc/testsuite/ChangeLog: * c-c++-common/Winit-self1.c: New test. * c-c++-common/Winit-self2.c: New test.
2022-07-21c++: defaulted friend op== [PR106361]Jason Merrill1-2/+0
Now non-member functions can be defaulted, so this assert is wrong. move_signature_fn_p already checks for ctor or op=. PR c++/106361 gcc/cp/ChangeLog: * decl.cc (move_fn_p): Remove assert. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/spaceship-eq14.C: New test.
2022-06-23c++: anon union designated init [PR105925]Jason Merrill1-1/+5
This testcase was failing because CONSTRUCTOR_IS_DESIGNATED_INIT wasn't getting set on the introduced CONSTRUCTOR for the anonymous union, and build_aggr_conv uses that flag to decide whether to pay attention to the indexes of the CONSTRUCTOR. So set the flag when we see a designator rather than relying on copying it from another CONSTRUCTOR. This avoids some redundant errors on desig4.C because we stop setting CONSTRUCTOR_IS_DESIGNATED_INIT on _Complex CONSTRUCTORs where it's nonsense. PR c++/105925 gcc/cp/ChangeLog: * decl.cc (reshape_init_array_1): Set CONSTRUCTOR_IS_DESIGNATED_INIT here. (reshape_init_class): And here. (reshape_init): Not here. gcc/testsuite/ChangeLog: * g++.dg/ext/desig4.C: Remove extra errors. * g++.dg/cpp2a/desig26.C: New test.
2022-06-10c++: improve TYPENAME_TYPE hashing [PR65328]Patrick Palka1-7/+16
For the testcase in this PR, compilation takes very long ultimately due to our poor hashing of TYPENAME_TYPE causing a huge number of collisions in the spec_hasher and typename_hasher tables. In spec_hasher, we don't hash the components of TYPENAME_TYPE, which means most TYPENAME_TYPE arguments end up contributing the same hash. This is the safe thing to do uniformly since structural_comptypes may try resolving a TYPENAME_TYPE via the current instantiation. But this behavior of structural_comptypes is suppressed from spec_hasher::equal via the comparing_specializations flag, which means spec_hasher::hash can assume it's disabled too. To that end, this patch makes spec_hasher::hash set the flag, and teaches iterative_hash_template_arg to hash the relevant components of TYPENAME_TYPE when the flag is set. And in typename_hasher, the hash function considers TYPE_IDENTIFIER instead of the more informative TYPENAME_TYPE_FULLNAME, which this patch fixes accordingly. After this patch, compile time for the testcase in the PR falls to around 30 seconds on my machine (down from dozens of minutes). PR c++/65328 gcc/cp/ChangeLog: * decl.cc (typename_hasher::hash): Add extra overloads. Use iterative_hash_object instead of htab_hash_pointer. Hash TYPENAME_TYPE_FULLNAME instead of TYPE_IDENTIFIER. (build_typename_type): Use typename_hasher::hash. * pt.cc (spec_hasher::hash): Add two-parameter overload. Set comparing_specializations around the call to hash_tmpl_and_args. (iterative_hash_template_arg) <case TYPENAME_TYPE>: When comparing_specializations, hash the TYPE_CONTEXT and TYPENAME_TYPE_FULLNAME. (tsubst_function_decl): Use spec_hasher::hash instead of hash_tmpl_and_args. (tsubst_template_decl): Likewise. (tsubst_decl): Likewise.
2022-06-08c++: non-templated friends [PR105852]Jason Merrill1-4/+5
The previous patch for 105852 avoids copying DECL_TEMPLATE_INFO from a non-templated friend, but it really shouldn't have it in the first place. PR c++/105852 gcc/cp/ChangeLog: * decl.cc (duplicate_decls): Change non-templated friend check to an assert. * pt.cc (tsubst_function_decl): Don't set DECL_TEMPLATE_INFO on non-templated friends. (tsubst_friend_function): Adjust.
2022-06-08c++: redeclared hidden friend take 2 [PR105852]Jason Merrill1-10/+6
My previous patch for 105761 avoided copying DECL_TEMPLATE_INFO from a friend to a later definition, but in this testcase we have first a non-friend declaration and then a definition, and we need to avoid copying in that case as well. But we do still want to set new_template_info to avoid GC trouble. With this change, the modules dump correctly identifies ::foo as a non-template function in tpl-friend-2_a.C. Along the way I noticed that the duplicate_decls handling of DECL_UNIQUE_FRIEND_P was backwards for templates, where we don't clobber DECL_LANG_SPECIFIC (olddecl) with DECL_LANG_SPECIFIC (newdecl) like we do for non-templates. PR c++/105852 PR c++/105761 gcc/cp/ChangeLog: * decl.cc (duplicate_decls): Avoid copying template info from non-templated friend even if newdecl isn't a definition. Correct handling of DECL_UNIQUE_FRIEND_P on templates. * pt.cc (non_templated_friend_p): New. * cp-tree.h (non_templated_friend_p): Declare it. gcc/testsuite/ChangeLog: * g++.dg/modules/tpl-friend-2_a.C: Adjust expected dump. * g++.dg/template/friend74.C: New test.
2022-06-07PR c++/96442: Improved error recovery in enumerations.Roger Sayle1-2/+5
This patch is a revised fix for PR c++/96442 providing a cleaner solution, setting ENUM_UNDERLYING_TYPE to integer_type_node when issuing an error, so that this invariant holds during the parser's error recovery. 2022-06-07 Roger Sayle <roger@nextmovesoftware.com> gcc/cp/ChangeLog PR c++/96442 * decl.cc (start_enum): When emitting a "must be integral" error, set ENUM_UNDERLYING_TYPE to integer_type_node, to avoid an ICE downstream in build_enumeration. gcc/testsuite/ChangeLog PR c++/96442 * g++.dg/parse/pr96442.C: New test case.
2022-06-03c++: redeclared hidden friend [PR105761]Jason Merrill1-2/+10
Here, when we see the second declaration of f we match it with the first one, copy over DECL_TEMPLATE_INFO, and then try to use it when parsing the definition, leading to confusion. PR c++/105761 gcc/cp/ChangeLog: * decl.cc (duplicate_decls): Don't copy DECL_TEMPLATE_INFO from a hidden friend. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/auto-fn64.C: New test.
2022-05-31c++: squash cp_build_qualified_type/_realPatrick Palka1-1/+1
This combines the two differently named versions of the same function into a single function utilizing a default argument. gcc/cp/ChangeLog: * cp-tree.h (cp_build_qualified_type_real): Rename to ... (cp_build_qualified_type): ... this. Give its last parameter a default argument. Remove macro of the same name. * decl.cc (grokdeclarator): Adjust accordingly. * pt.cc (tsubst_aggr_type): Likewise. (rebuild_function_or_method_type): Likewise. (tsubst): Likewise. (maybe_dependent_member_ref): Likewise. (unify): Likewise. * tree.cc (cp_build_qualified_type_real): Rename to ... (cp_build_qualified_type): ... this. Adjust accordingly.
2022-05-31c++: use current_template_constraints morePatrick Palka1-13/+4
gcc/cp/ChangeLog: * decl.cc (grokvardecl): Use current_template_constraints. (grokdeclarator): Likewise. (xref_tag): Likewise. * semantics.cc (finish_template_template_parm): Likewise.
2022-05-26c++: constrained partial spec forward decl [PR96363]Patrick Palka1-1/+2
Here during cp_parser_single_declaration for #2, we were calling associate_classtype_constraints for TPL<T> (the primary template type) before maybe_process_partial_specialization could get a chance to notice that we're in fact declaring a distinct constrained partial spec and not redeclaring the primary template. This caused us to emit a bogus error about differing constraints b/t the primary template and #2's constraints. This patch fixes this by moving the call to associate_classtype_constraints after the call to shadow_tag (which calls maybe_process_partial_specialization) and adjusting shadow_tag to use the return value of m_p_p_s. Moreover, if we later try to define a constrained partial specialization that's been declared earlier (as in the third testcase), then maybe_new_partial_specialization correctly notices it's a redeclaration and returns NULL_TREE. But in this case we also need to update TYPE to point to the redeclared partial spec (it'll otherwise continue pointing to the primary template type, eventually leading to a bogus error). PR c++/96363 gcc/cp/ChangeLog: * decl.cc (shadow_tag): Use the return value of maybe_process_partial_specialization. * parser.cc (cp_parser_single_declaration): Call shadow_tag before associate_classtype_constraints. * pt.cc (maybe_new_partial_specialization): Change return type to bool. Take 'type' argument by mutable reference. Set 'type' to point to the correct constrained specialization when appropriate. (maybe_process_partial_specialization): Adjust accordingly. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-partial-spec12.C: New test. * g++.dg/cpp2a/concepts-partial-spec12a.C: New test. * g++.dg/cpp2a/concepts-partial-spec13.C: New test.
2022-05-25c++: fix ICE on invalid attributes [PR96637]Marek Polacek1-9/+10
When chaining attributes, attr_chainon should be used rather than plain chainon, so that we don't end up with a TREE_LIST where one of the elements is error_mark_node, which causes problems. parser.cc has already been fixed to use attr_chainon, but decl.cc has not. Until now. PR c++/96637 gcc/cp/ChangeLog: * cp-tree.h (attr_chainon): Declare. * decl.cc (start_decl): Use attr_chainon. (grokdeclarator): Likewise. * parser.cc (cp_parser_statement): No longer static. gcc/testsuite/ChangeLog: * g++.dg/parse/error64.C: New test.
2022-05-17c++: constexpr ref to array of array [PR102307]Jason Merrill1-5/+12
The problem here is that first check_initializer calls build_aggr_init_full_exprs, which does overload resolution, but then in the case of failed constexpr throws away the result and does it again in build_functional_cast. But in the first overload resolution, reshape_init_array_1 decided to reuse the inner CONSTRUCTORs because tf_error is set, so we know we're committed. But the second pass gets confused by the CONSTRUCTORs with non-init-list types. Fixed by avoiding a second pass: instead, pass the call from build_aggr_init to build_cplus_new, which will turn it into a TARGET_EXPR. I don't bother to change the object argument because it will be replaced later in simplify_aggr_init_expr. PR c++/102307 gcc/cp/ChangeLog: * decl.cc (check_initializer): Use build_cplus_new in case of constexpr failure. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/constexpr-array2.C: New test.
2022-05-11[c++] Add module attachmentNathan Sidwell1-11/+12
This adds module attachment as a distinct flag to 'in module purview'. A declaration may have neither or both (as before), but can also have just the 'in [named-module] purview', which was previously not representable. This new state allows some cleanup of redeclarations (particularly the builtins), which was a little warty. Some other internal APIs get similarly clarified. gcc/cp/ * cp-tree.h (DECL_MODULE_ATTACH_P): New. (struct lang_decl_base): Add module_attach_p flag. * decl.cc (duplicate_decls): Rework module redeclaration checking. * module.cc (trees_out::lang_decl_bools): Write attach flag. (trees_in::lang_decl_bools): ... and read it back. (trees_out::decl_value): Rework module attachment handling. (trees_in::decl_value): Rename local var to reflect meaning. (trees_in::key_mergeable): Likewise. (get_originating_module): Use DECL_MODULE_ATTACH_P. No need to special-case mangling. (module_may_redeclare): Reimplement. (set_originating_module): Deal with attachment. * name-lookup.cc (maybe_record_mergeable_decl): Deal with attachment. (mergeable_namespace_slots): Likewise. (do_nonmember_using_decl): Likewise. * name-lookup.h (mergeable_namespace_slots): Adjust parm meaning. * ptree.cc (cxx_print_decl): Adjust purview & attach printing.
2022-05-10[c++] Disambiguate ModuleKind flagsNathan Sidwell1-1/+1
In modules, 'attached to global module' nearly always means 'not in module purview'. Also the implementation treats, 'in global module && in module purview' as meaning 'header unit'. The ModuleKind flags reflected that. The 'nearly always' means there are cases that the first condition is not invariant, and that of course invalidates the second equivalence. This disambiguates the ModuleKind flags to allow that 'not quite', and separate out header-unitness from the GMF & purview flags combination. 1) Separate out named-module vs header-unit from the MODULE/GLOBAL flags. 2) Replace the MODULE/GLOBAL flags with PURVIEW & ATTACH flags. 3) Adjust the parser state handling. Lays ground-work for language-declaration changes. gcc/cp/ * cp-tree.h (enum module_kind_bits): Disambiguate purview, attach, named module vs header-unit. (global_purview_p, not_module_p): Delete. (named_module_p): New. (header_module_p, module_purview_p): Adjust. (module_attach_p, named_module_purview_p): New. * decl.cc (duplicate_decls): Adjust. * module.cc (declare_module, preprocessed_module): Adjust. * name-lookup.cc (init_global_partition): Adjust. (get_fixed_binding_slot, pushdecl): Adjust. * parser.cc (cp_parser_module_declaration): Adjust. (cp_parser_import_declaration, cp_parser_declaration): Adjust.
2022-05-10c++: fix arm-eabi crash building libstdc++ [PR105529]Jason Merrill1-37/+10
My recent change to cxx_eval_store_expression asserts that the target and value can only end up having different types in the case of an empty base; this was crashing arm-eabi compilers because in that ABI [cd]tors return *this, and weren't converting it to void* first. This also shares the 'return this' code between the three places it occurs. Thanks to Marek for the tests. PR c++/105529 gcc/cp/ChangeLog: * decl.cc (maybe_return_this): Replace... (finish_constructor_body, finish_destructor_body): ...these. (finish_function_body): Call it. * optimize.cc (build_delete_destructor_body): Call it. * cp-tree.h (maybe_return_this): Declare. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/constexpr-dtor13.C: New test. * g++.dg/cpp2a/constexpr-dtor14.C: New test.
2022-05-09c++: constexpr init of union sub-aggr w/ base [PR105491]Patrick Palka1-10/+26
Here ever since r10-7313-gb599bf9d6d1e18, reduced_constant_expression_p in C++11/14 is rejecting the marked sub-aggregate initializer (of type S) W w = {.D.2445={.s={.D.2387={.m=0}, .b=0}}}; ^ ultimately because said initializer has CONSTRUCTOR_NO_CLEARING set, hence the function must verify that all fields of S are initialized. And before C++17 it doesn't expect to see base class fields (since next_initializable_field skips over them), so the presence thereof causes r_c_e_p to return false. The reason r10-7313-gb599bf9d6d1e18 causes this is because in that commit we began using CONSTRUCTOR_NO_CLEARING to precisely track whether we're in middle of activating a union member. This ends up affecting clear_no_implicit_zero, which recurses into sub-aggregate initializers only if the outer initializer has CONSTRUCTOR_NO_CLEARING set. After that commit, the outer union initializer above no longer has the flag set at this point and so clear_no_implicit_zero no longer recurses into the marked inner initializer. But arguably r_c_e_p should be able to accept the marked initializer regardless of whether CONSTRUCTOR_NO_CLEARING is set. The primary bug therefore seems to be that r_c_e_p relies on next_initializable_field which skips over base class fields in C++11/14. To fix this, this patch introduces a new helper function next_subobject_field which is like next_initializable_field except that it never skips base class fields, and makes r_c_e_p use it. This patch then renames next_initializable_field to next_aggregate_field (and makes it skip over vptr fields again). PR c++/105491 gcc/cp/ChangeLog: * call.cc (field_in_pset): Adjust after next_initializable_field renaming. (build_aggr_conv): Likewise. (convert_like_internal): Likewise. (type_has_extended_temps): Likewise. * class.cc (default_init_uninitialized_part): Likewise. (finish_struct): Likewise. * constexpr.cc (cx_check_missing_mem_inits): Likewise. (reduced_constant_expression_p): Use next_subobject_field instead. * cp-gimplify.cc (get_source_location_impl_type): Adjust after next_initializable_field renaming. (fold_builtin_source_location): Likewise. * cp-tree.h (next_initializable_field): Rename to ... (next_aggregate_field): ... this. (next_subobject_field): Declare. * decl.cc (next_aggregate_field): Renamed from ... (next_initializable_field): ... this. Skip over vptr fields again. (next_subobject_field): Define. (reshape_init_class): Adjust after next_initializable_field renaming. * init.cc (build_value_init_noctor): Likewise. (emit_mem_initializers): Likewise. * lambda.cc (build_capture_proxy): Likewise. * method.cc (build_comparison_op): Likewise. * pt.cc (maybe_aggr_guide): Likewise. * tree.cc (structural_type_p): Likewise. * typeck2.cc (split_nonconstant_init_1): Likewise. (digest_init_r): Likewise. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/constexpr-union7.C: New test. * g++.dg/cpp0x/constexpr-union7a.C: New test. * g++.dg/cpp2a/constinit17.C: New test.
2022-05-04c++: optimize reshape_initJason Merrill1-1/+7
If the index of a constructor_elt is a FIELD_DECL, the CONSTRUCTOR is already reshaped, so we can save time and memory by returning immediately. gcc/cp/ChangeLog: * decl.cc (reshape_init): Shortcut already-reshaped init. (reshape_init_class): Assert not getting one here.
2022-05-04c++: Remove cdtor_labelJason Merrill1-20/+0
Jakub pointed out that cdtor_label is unnecessary, we should get all the desired semantics with a normal return. gcc/cp/ChangeLog: * cp-tree.h (struct language_function): Remove x_cdtor_label. (cdtor_label, LABEL_DECL_CDTOR): Remove. * constexpr.cc (returns): Don't check LABEL_DECL_CDTOR. (cxx_eval_constant_expression): Don't call returns. * decl.cc (check_goto): Don't check cdtor_label. (start_preparsed_function): And don't set it. (finish_constructor_body, finish_destructor_body): Remove. (finish_function_body): Don't call them. * typeck.cc (check_return_expr): Handle cdtor_returns_this here. * semantics.cc (finish_return_stmt): Not here.
2022-04-29c++: reorganize friend template matching [PR91618]Jason Merrill1-9/+0
The the different calling of check_explicit_specialization for class and namespace scope friends bothered me, so this patch combines them. PR c++/91618 PR c++/96604 gcc/cp/ChangeLog: * friend.cc (do_friend): Call check_explicit_specialization here. * decl.cc (grokdeclarator): Not here. * decl2.cc (check_classfn): Or here.
2022-04-29c++: tidy auto deductionJason Merrill1-3/+2
In r185768 I added the !FUNCTION_DECL check, but we might as well just check for variable; nothing else should take this path, and asserting as much doesn't regress anything. gcc/cp/ChangeLog: * decl.cc (cp_finish_decl): Only consider auto for vars.
2022-04-29c++: check completeness after auto deduction [PR80351]Jason Merrill1-0/+11
Normally we check for incomplete type in start_decl, but that obviously doesn't work for auto variables. Thanks to Pokechu22 for the analysis and testcases: "When cp_finish_decl calls cp_apply_type_quals_to_decl on a const auto or constexpr auto variable, the type might not be complete the first time (this happened when auto deduces to an initializer_list). cp_apply_type_quals_to_decl removes the const qualifier if the type is not complete, which is appropriate for grokdeclarator, on the assumption that the type will be complete when called by cp_finish_decl." PR c++/80351 gcc/cp/ChangeLog: * decl.cc (cp_finish_decl): Check completeness of deduced type. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/constexpr-77482.C: Adjust message. * g++.dg/cpp1y/auto-fn27.C: Likewise. * g++.dg/cpp1y/lambda-generic-variadic22.C: Likewise. * g++.dg/cpp1z/decomp54.C: Likewise. * g++.dg/cpp0x/initlist-const1.C: New test. * g++.dg/warn/Wunused-var-37.C: New test. * g++.dg/warn/Wunused-var-38.C: New test. * g++.dg/warn/Wunused-var-39.C: New test.
2022-04-14c++: unsigned int32_t enum promotion [PR102804]Jason Merrill1-0/+2
There's been an extension for a long time to allow applying 'unsigned' to an int typedef, but that was confusing the integer promotion code. Fixed by forgetting about the typedef in that case. I'm going to make this an unconditional pedwarn in stage 1. PR c++/102804 gcc/cp/ChangeLog: * decl.cc (grokdeclarator): Drop typedef used with 'unsigned'. gcc/testsuite/ChangeLog: * g++.dg/ext/unsigned-typedef1.C: New test.
2022-04-13c++: NRV and ref-extended temps [PR101442]Jason Merrill1-1/+1
This issue goes back to r83221, where the cleanup for extended ref temps changed from being unconditional to being tied to the declaration they formed part of the initializer for. The named return value optimization changes the cleanup for the NRV variable to only run on the EH path; we don't want that change to affect temporary cleanups. The perform_member_init change isn't necessary (there 'decl' is a COMPONENT_REF), it's just for consistency. PR c++/101442 gcc/cp/ChangeLog: * decl.cc (cp_finish_decl): Don't pass decl to push_cleanup. * init.cc (perform_member_init): Likewise. * semantics.cc (push_cleanup): Adjust comment. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/initlist-nrv1.C: New test.
2022-04-12c++: local function versioning [PR104669]Jason Merrill1-6/+14
There were two problems with this testcase: we weren't copying the target attribute from the second declaration to the global alias for the first one (duplicate_decls hunk), and then we were treating the third one as matching the earlier one even though both are versioned (decls_match hunk). The latter change required a fix to find_last_decl (used for attribute mismatch warnings) to give up if we see a versioned function, as in that case we can't determine whether the decls match, because we are still in the process of setting the attributes on the new decl. PR c++/104669 gcc/cp/ChangeLog: * decl.cc (decls_match): Compare versions even if not recording. (duplicate_decls): Propagate attributes to alias. * decl2.cc (find_last_decl): Give up if versioned. gcc/testsuite/ChangeLog: * g++.target/i386/mv31.C: New test.
2022-04-11c++: rodata and defaulted ctor [PR104142]Jason Merrill1-0/+4
Trivial initialization shouldn't bump a variable out of .rodata; if the result of build_aggr_init is an empty STATEMENT_LIST, throw it away. PR c++/104142 gcc/cp/ChangeLog: * decl.cc (check_initializer): Check TREE_SIDE_EFFECTS. gcc/testsuite/ChangeLog: * g++.dg/opt/const7.C: New test.
2022-04-06c++: conversion with trailing return type [PR101051]Jason Merrill1-2/+5
We've had a diagnostic for this, but since r10-6571 added an assert to splice_late_return_type, we need to diagnose before we call it. PR c++/101051 gcc/cp/ChangeLog: * decl.cc (grokdeclarator): Reject conversion with trailing return sooner. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/trailing15.C: New test.
2022-04-04c++: repeated friend template [PR101894]Jason Merrill1-0/+5
Since olddecl isn't a definition, it doesn't get DECL_FRIEND_CONTEXT, so we need to copy it from newdecl when we merge the declarations. PR c++/101894 gcc/cp/ChangeLog: * decl.cc (duplicate_decls): Copy DECL_FRIEND_CONTEXT. gcc/testsuite/ChangeLog: * g++.dg/lookup/friend22.C: New test.
2022-03-24c++: ICE with template code in constexpr [PR104284]Marek Polacek1-0/+4
Since r9-6073 cxx_eval_store_expression preevaluates the value to be stored, and that revealed a crash where a template code (here, code=IMPLICIT_CONV_EXPR) leaks into cxx_eval*. It happens because we're performing build_vec_init while processing a template, which calls get_temp_regvar which creates an INIT_EXPR. This INIT_EXPR's RHS contains an rvalue conversion so we create an IMPLICIT_CONV_EXPR. Its operand is not type-dependent and the whole INIT_EXPR is not type-dependent. So we call build_non_dependent_expr which, with -fchecking=2, calls fold_non_dependent_expr. At this point the expression still has an IMPLICIT_CONV_EXPR, which ought to be handled in instantiate_non_dependent_expr_internal. However, tsubst_copy_and_build doesn't handle INIT_EXPR; it will just call tsubst_copy which does nothing when args is null. So we fail to replace the IMPLICIT_CONV_EXPR and ICE. The problem is that we call build_vec_init in a template in the first place. We can avoid doing so by checking p_t_d before calling build_aggr_init in check_initializer. PR c++/104284 gcc/cp/ChangeLog: * decl.cc (check_initializer): Don't call build_aggr_init in a template. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/constexpr-104284-1.C: New test. * g++.dg/cpp1y/constexpr-104284-2.C: New test. * g++.dg/cpp1y/constexpr-104284-3.C: New test. * g++.dg/cpp1y/constexpr-104284-4.C: New test.
2022-03-24c++: extern thread_local declarations in constexpr [PR104994]Jakub Jelinek1-3/+3
C++14 to C++20 apparently should allow extern thread_local declarations in constexpr functions, however useless they are there (because accessing such vars is not valid in a constant expression, perhaps sizeof/decltype). P2242 changed that for C++23 to passing through declaration but https://cplusplus.github.io/CWG/issues/2552.html has been filed for it yesterday. The following patch implements the proposed wording of CWG 2552 in addition to fixing the C++14 - C++20 handling bug. If you'd like instead to keep the current pedantic C++23 wording for now, that would mean taking out the first hunk (cxx_eval_constant_expression) and g++.dg/cpp23/constexpr-nonlit2.C hunk. 2022-03-24 Jakub Jelinek <jakub@redhat.com> PR c++/104994 * constexpr.cc (cxx_eval_constant_expression): Don't diagnose passing through extern thread_local declarations. Change wording from declaration to definition. (potential_constant_expression_1): Don't diagnose extern thread_local declarations. Change wording from declared to defined. * decl.cc (start_decl): Likewise. * g++.dg/diagnostic/constexpr1.C: Change expected diagnostic wording from declared to defined. * g++.dg/cpp23/constexpr-nonlit1.C: Likewise. (garply): Change dg-error into dg-bogus. * g++.dg/cpp23/constexpr-nonlit2.C: Change expected diagnostic wording from declaration to definition. * g++.dg/cpp23/constexpr-nonlit6.C: Change expected diagnostic wording from declared to defined. * g++.dg/cpp23/constexpr-nonlit7.C: New test. * g++.dg/cpp2a/constexpr-try5.C: Change expected diagnostic wording from declared to defined. * g++.dg/cpp2a/consteval3.C: Likewise.
2022-03-23c++: tweak PR103337 fixJason Merrill1-11/+21
Patrick suggested a way to implement the designated-init handling without (temporarily) modifying the CONSTRUCTOR being reshaped. PR c++/103337 gcc/cp/ChangeLog: * decl.cc (reshape_single_init): New. (reshape_init_class): Use it.
2022-03-21c++: designated init and aggregate members [PR103337]Jason Merrill1-5/+42
Our C++20 designated initializer handling was broken with members of class type; we would find the relevant member and then try to find a member of the member with the same name. Or we would sometimes ignore the designator entirely. The former problem is fixed by the change to reshape_init_class, the latter by the change to reshape_init_r. PR c++/103337 PR c++/102740 PR c++/103299 PR c++/102538 gcc/cp/ChangeLog: * decl.cc (reshape_init_class): Avoid looking for designator after we found it. (reshape_init_r): Keep looking for designator. gcc/testsuite/ChangeLog: * g++.dg/ext/flexary3.C: Remove one error. * g++.dg/parse/pr43765.C: Likewise. * g++.dg/cpp2a/desig22.C: New test. * g++.dg/cpp2a/desig23.C: New test. * g++.dg/cpp2a/desig24.C: New test. * g++.dg/cpp2a/desig25.C: New test.
2022-03-21c++: designator and anon struct [PR101767]Jason Merrill1-0/+5
We found .x in the anonymous struct, but then didn't find .y there; we should decide that means we're done with the struct rather than that the code is wrong. PR c++/101767 gcc/cp/ChangeLog: * decl.cc (reshape_init_class): Back out of anon struct if a designator doesn't match. gcc/testsuite/ChangeLog: * g++.dg/ext/anon-struct10.C: New test.
generated by cgit v1.1 at 2024-10-07 11:16:43 +0000