aboutsummaryrefslogtreecommitdiff
path: root/gcc/cp
AgeCommit message (Collapse)AuthorFilesLines
2020-09-24c++: local-decls are never member fns [PR97186]Nathan Sidwell1-8/+13
This fixes an ICE in noexcept instantiation. It was presuming functions always have template_info, but that changed with my DECL_LOCAL_DECL_P changes. Fortunately DECL_LOCAL_DECL_P fns are never member fns, so we don't need to go fishing out a this pointer. Also I realized I'd misnamed local10.C, so renaming it local-fn3.C, and while there adding the effective-target lto that David E pointed out was missing. PR c++/97186 gcc/cp/ * pt.c (maybe_instantiate_noexcept): Local externs are never member fns. gcc/testsuite/ * g++.dg/template/local10.C: Rename ... * g++.dg/template/local-fn3.C: .. here. Require lto. * g++.dg/template/local-fn4.C: New.
2020-09-24Daily bump.GCC Administrator1-0/+12
2020-09-23c++: Remove some gratuitous typedefingNathan Sidwell1-7/+6
This is C++, we don't need 'typedef struct foo foo;'. Oh, and bool bitfields are a thing. gcc/cp/ * name-lookup.h (typedef cxx_binding): Delete tdef. (typedef cp_binding_level): Likewise. (struct cxx_binding): Flags are bools.
2020-09-23c++: dependent local extern decl ICE [PR97171]Nathan Sidwell1-0/+8
I'd missed the piece of substutution for the uses of a local extern decl. Just grab the local specialization. We need to do this regardless of dependentness because we always cloned the local extern. PR c++/97171 gcc/cp/ * pt.c (tsubst_copy) [FUNCTION_DECL,VAR_DECL]: Retrieve local specialization for DECL_LOCAL_P decls. gcc/testsuite/ * g++.dg/template/local10.C: New.
2020-09-23Daily bump.GCC Administrator1-0/+26
2020-09-22c++: Return only in-scope tparms in keep_template_parm [PR95310]Patrick Palka1-0/+44
In the testcase below, the dependent specializations iter_reference_t<F> and iter_reference_t<Out> share the same tree due to specialization caching. So when find_template_parameters walks through the requires-expression (as part of normalization), it sees and includes the out-of-scope template parameter F in the list of template parameters it found within the requires-expression (along with Out and N). From a correctness perspective this is harmless since the parameter mapping routines only care about the level and index of each parameter, so F is no different from Out in that sense. And it's also harmless that two parameters in the parameter mapping have the same level and index. But having both Out and F in the parameter mapping means extra work for hash_atomic_constrant, tsubst_parameter_mapping and get_mapped_args; and it also means we print this irrelevant template parameter in the testcase's diagnostics (via pp_cxx_parameter_mapping): in requirements with ‘Out o’ [with N = (const int&)&a; F = const int*; Out = const int*] This patch makes keep_template_parm return only in-scope template parameters by looking into ctx_parms for the corresponding in-scope one, through a new helper function corresponding_template_parameter. (That we sometimes print irrelevant template parameters in diagnostics is also the subject of PR99 and PR66968, so the above diagnostic issue could likely be fixed in a more general way, but this targeted fix to keep_template_parm is perhaps worthwhile on its own.) gcc/cp/ChangeLog: PR c++/95310 * pt.c (corresponding_template_parameter): Define. (keep_template_parm): Use it to adjust the given template parameter to the corresponding in-scope one from ctx_parms. gcc/testsuite/ChangeLog: PR c++/95310 * g++.dg/concepts/diagnostic15.C: New test.
2020-09-22c++: Remove a broken error-recovery pathNathan Sidwell3-24/+5
The remaining use of xref_tag_from_type was also suspicious. It turns out to be an error path. At parse time we diagnose that a class definition cannot appear, but we swallow the definition. This code was attempting to push it into the global scope (or find a conflict). This seems needless, just return error_mark_node. This was the simpler fix than going through the parser and figuring out how to get it to put in error_mark_node at the right point. gcc/cp/ * cp-tree.h (xref_tag_from_type): Don't declare. * decl.c (xref_tag_from_type): Delete. * pt.c (lookup_template_class_1): Erroneously located class definitions just give error_mark, don't try and inject it into the namespace.
2020-09-22c++: Ignore __sanitizer_ptr_{sub,cmp} builtin calls during constant ↵Jakub Jelinek1-0/+6
expression evaluation [PR97145] These two builtin calls are added already during parsing before pointer subtractions or comparisons, normally they perform runtime verification of whether the pointers point to the same object or different objects, but during constant expressione valuation we don't really need those builtins for anything. 2020-09-22 Jakub Jelinek <jakub@redhat.com> PR c++/97145 * constexpr.c (cxx_eval_builtin_function_call): Return void_node for calls to __sanitize_ptr_{sub,cmp} builtins. * g++.dg/asan/pr97145.C: New test.
2020-09-22c++: fix injected friend of template classNathan Sidwell1-19/+0
In working on fixing hiddenness, I discovered some suspicious code in template instantiation. I suspect it dates from when we didn't do the hidden friend injection thing at all. The xreftag finds the same class, but makes it visible to name lookup. Which is wrong. hurrah, fixing a bug by deleting code! gcc/cp/ * pt.c (instantiate_class_template_1): Do not repush and unhide injected friend. gcc/testsuite/ * g++.old-deja/g++.pt/friend34.C: Check injected friend is still invisible.
2020-09-22Daily bump.GCC Administrator1-0/+25
2020-09-21c++: DR 1722: Make lambda to function pointer conv noexcept [PR90583]Marek Polacek1-0/+2
DR 1722 clarifies that the conversion function from lambda to pointer to function should be noexcept(true). gcc/cp/ChangeLog: PR c++/90583 DR 1722 * lambda.c (maybe_add_lambda_conv_op): Mark the conversion function as noexcept. gcc/testsuite/ChangeLog: PR c++/90583 DR 1722 * g++.dg/cpp0x/lambda/lambda-conv14.C: New test.
2020-09-21c++: Implement -Wctad-maybe-unsupported.Marek Polacek1-4/+24
I noticed that clang++ has this CTAD warning and thought that it might be useful to have it. From clang++: "Some style guides want to allow using CTAD only on types that "opt-in"; i.e. on types that are designed to support it and not just types that *happen* to work with it." So this warning warns when CTAD deduced a type, but the type does not define any deduction guides. In that case CTAD worked only because the compiler synthesized the implicit deduction guides. That might not be intended. It can be suppressed by adding a deduction guide that will never be considered: struct allow_ctad_t; template <typename T> struct S { S(T) {} }; S(allow_ctad_t) -> S<void>; This warning is off by default. It doesn't warn when the type comes from a system header unless -Wsystem-headers. gcc/c-family/ChangeLog: * c.opt (Wctad-maybe-unsupported): New option. gcc/cp/ChangeLog: * pt.c (deduction_guides_for): Add a bool parameter. Set it. (do_class_deduction): Warn when CTAD succeeds but the type doesn't have any explicit deduction guides. gcc/ChangeLog: * doc/invoke.texi: Document -Wctad-maybe-unsupported. gcc/testsuite/ChangeLog: * g++.dg/warn/Wctad-maybe-unsupported.C: New test. * g++.dg/warn/Wctad-maybe-unsupported2.C: New test. * g++.dg/warn/Wctad-maybe-unsupported3.C: New test. * g++.dg/warn/Wctad-maybe-unsupported.h: New file.
2020-09-21c++: ts_lambda is not neededNathan Sidwell3-21/+15
We don't need ts_lambda, as IDENTIFIER_LAMBDA_P is sufficient. Killed thusly. gcc/cp/ * decl.c (xref_tag_1): Use IDENTIFIER_LAMBDA_P to detect lambdas. * lambda.c (begin_lambda_type): Use ts_current to push the tag. * name-lookup.h (enum tag_scope): Drop ts_lambda.
2020-09-21c++: Detect deduction guide redeclaration [PR97099]Marek Polacek1-6/+14
[temp.deduct.guide]p3: Two deduction guide declarations in the same translation unit for the same class template shall not have equivalent parameter-declaration-clauses. So let's detect that. gcc/cp/ChangeLog: PR c++/97099 * decl.c (redeclaration_error_message): Detect a redeclaration of deduction guides. gcc/testsuite/ChangeLog: PR c++/97099 * g++.dg/cpp1z/class-deduction74.C: New test.
2020-09-20Daily bump.GCC Administrator1-0/+52
2020-09-19Move loop and switch tree data structures from cp/ to c-family/.Sandra Loosemore6-570/+84
This patch moves the definitions for DO_STMT, FOR_STMT, WHILE_STMT, SWITCH_STMT, BREAK_STMT, and CONTINUE_STMT from the C++ front end to c-family. This includes the genericizers, pretty-printers, and dump support as well as the tree definitions and accessors. Some related code for OMP_FOR and similar OMP constructs is also moved. 2020-08-12 Sandra Loosemore <sandra@codesourcery.com> gcc/c-family/ * c-common.c (c_block_may_fallthrough): New, split from cxx_block_may_fallthrough in the cp front end. (c_common_init_ts): Move handling of loop and switch-related statements here from the cp front end. * c-common.def (FOR_STMT, WHILE_STMT, DO_STMT): Move here from cp front end. (BREAK_STMT, CONTINUE_STMT, SWITCH_STMT): Likewise. * c-common.h (c_block_may_fallthru): Declare. (bc_state_t): Move here from cp front end. (save_bc_state, restore_bc_state): Declare. (c_genericize_control_stmt): Declare. (WHILE_COND, WHILE_BODY): Likewise. (DO_COND, DO_BODY): Likewise. (FOR_INIT_STMT, FOR_COND, FOR_EXPR, FOR_BODY, FOR_SCOPE): Likewise. (SWITCH_STMT_COND, SWITCH_STMT_BODY): Likewise. (SWITCH_STMT_TYPE, SWITCH_STMT_SCOPE): Likewise. (SWITCH_STMT_ALL_CASES_P, SWITCH_STMT_NO_BREAK_P): Likewise. (LABEL_DECL_BREAK, LABEL_DECL_CONTINUE): Likewise. * c-dump.c (dump_stmt): Copy from cp front end. (c_dump_tree): Move code to handle structured loop and switch tree nodes here from cp front end. * c-gimplify.c: Adjust includes. (enum bc_t, bc_label, begin_bc_block, finish_bc_block): Move from cp front end. (save_bc_state, restore_bc_state): New functions using old code from cp front end. (get_bc_label, expr_loc_or_loc): Move from cp front end. (genericize_c_loop): Move from cp front end. (genericize_for_stmt, genericize_while_stmt): Likewise. (genericize_do_stmt, genericize_switch_stmt): Likewise. (genericize_continue_stmt, genericize_break_stmt): Likewise. (genericize_omp_for_stmt): Likewise. (c_genericize_control_stmt): New function using code split from cp front end. (c_genericize_control_r): New. (c_genericize): Call walk_tree with c_genericize_control_r. * c-pretty-print.c (c_pretty_printer::statement): Move code to handle structured loop and switch tree nodes here from cp front end. gcc/cp/ * cp-gimplify.c (enum bc_t, bc_label): Move to c-family. (begin_bc_block, finish_bc_block, get_bc_label): Likewise. (genericize_cp_loop): Likewise. (genericize_for_stmt, genericize_while_stmt): Likewise. (genericize_do_stmt, genericize_switch_stmt): Likewise. (genericize_continue_stmt, genericize_break_stmt): Likewise. (genericize_omp_for_stmt): Likewise. (cp_genericize_r): Call c_genericize_control_stmt instead of above functions directly. (cp_genericize): Call save_bc_state and restore_bc_state instead of manipulating bc_label directly. * cp-objcp-common.c (cxx_block_may_fallthru): Defer to c_block_may_fallthru instead of handling SWITCH_STMT here. (cp_common_init_ts): Move handling of loop and switch-related statements to c-family. * cp-tree.def (FOR_STMT, WHILE_STMT, DO_STMT): Move to c-family. (BREAK_STMT, CONTINUE_STMT, SWITCH_STMT): Likewise. * cp-tree.h (LABEL_DECL_BREAK, LABEL_DECL_CONTINUE): Likewise. (WHILE_COND, WHILE_BODY): Likewise. (DO_COND, DO_BODY): Likewise. (FOR_INIT_STMT, FOR_COND, FOR_EXPR, FOR_BODY, FOR_SCOPE): Likewise. (SWITCH_STMT_COND, SWITCH_STMT_BODY): Likewise. (SWITCH_STMT_TYPE, SWITCH_STMT_SCOPE): Likewise. (SWITCH_STMT_ALL_CASES_P, SWITCH_STMT_NO_BREAK_P): Likewise. * cxx-pretty-print.c (cxx_pretty_printer::statement): Move code to handle structured loop and switch tree nodes to c-family. * dump.c (cp_dump_tree): Likewise. gcc/ * doc/generic.texi (Basic Statements): Document SWITCH_EXPR here, not SWITCH_STMT. (Statements for C and C++): Rename node to reflect what the introduction already says about sharing between C and C++ front ends. Copy-edit and correct documentation for structured loops and switch.
2020-09-19c++: Fix self-mapping in map_arguments [PR96531, PR97103]Patrick Palka2-18/+29
With r10-8077 we stopped passing the argified current_template_parms to normalize_constraint_expression from finish_nested_requirement, and instead made map_arguments perform a self-mapping of parameters when args is NULL. But we're currently not handling parameter packs and BOUND_TEMPLATE_TEMPLATE_PARMs properly during this self-mapping, which leads to ICEs later during satisfaction. To properly handle self-mapping of a parameter pack, this patch extends template_parm_to_arg to handle TEMPLATE_PARM_P nodes, and makes map_arguments use it. (This change revealed that the call to template_parm_to_arg in convert_generic_types_to_packs was a no-op because the argument 't' is never a TREE_LIST, so this patch additionally removes this call.) As for bound ttps, map_arguments before r10-8077 would map a BOUND_TEMPLATE_TEMPLATE_PARM not to itself but to its underlying TEMPLATE_TEMPLATE_PARM. We could restore this behavior in map_arguments, but since a bound ttp is not really a template parameter it seems better to make keep_template_parm not give us a bound ttp in the first place. So this patch makes keep_template_parm return the underlying ttp when it sees a bound ttp. gcc/cp/ChangeLog: PR c++/96531 PR c++/97103 * constraint.cc (map_arguments): Call template_parm_to_arg in the self-mapping case. (finish_shorthand_constraint): No need to build a TREE_LIST before calling template_parm_to_arg. * pt.c (template_parm_to_arg): Rewrite to handle TEMPLATE_PARM_P nodes as well as DECL_TEMPLATE_PARM_P nodes, and to make the overlying TREE_LIST node optional. (keep_template_parm): Don't record a BOUND_TEMPLATE_TEMPLATE_PARM, instead record its corresponding TEMPLATE_TEMPLATE_PARM. (convert_generic_types_to_packs): Don't call template_parm_to_arg. gcc/testsuite/ChangeLog: PR c++/96531 PR c++/97103 * g++.dg/cpp2a/concepts-ttp2.C: New test. * g++.dg/cpp2a/concepts-variadic1.C: New test.
2020-09-19c++: std::is_constant_evaluated inside constraint [PR97051]Patrick Palka1-1/+2
According to [expr.const]/14, the result of substitution into an atomic constraint is manifestly constant-evaluated; this patch adjusts the call to maybe_constant_value in satisfy_atom to that effect. gcc/cp/ChangeLog: PR c++/97051 * constraint.cc (satisfy_atom): Pass true as the manifestly_const_eval argument to maybe_constant_value. gcc/testsuite/ChangeLog: PR c++/97051 * g++.dg/cpp2a/is-constant-evaluated11.C: New test.
2020-09-19Daily bump.GCC Administrator1-0/+10
2020-09-18c++: Fix bootstrap failure. [PR97118]Jason Merrill1-1/+2
gcc/cp/ChangeLog: PR bootstrap/97118 * decl.c (complete_vars): Only call layout_var_decl if completing the type succeeded.
2020-09-17c++: Layout decls with newly-complete type.Jason Merrill1-2/+2
Martin's -Wplacement-new patch ran into a problem with DECL_SIZE not being set on an extern variable for which the type was not complete until after its declaration. complete_vars was deliberately not calling layout_decl for some reason, instead leaving that for expand_expr_real_1 much later in the compilation. But if we layout decls at declaration time, I don't see any reason we shouldn't lay them out here, when their type is newly complete. gcc/cp/ChangeLog: * decl.c (complete_vars): Call layout_var_decl.
2020-09-18Daily bump.GCC Administrator1-0/+15
2020-09-17c++: requires-expressions and partial instantiation [PR96410]Patrick Palka3-9/+37
This patch makes tsubst_requires_expr avoid substituting into a requires-expression when partially instantiating a generic lambda. This is necessary in general to ensure that we always check requirements in lexical order (as in the first testcase below). A mechanism similar to PACK_EXPANSION_EXTRA_ARGS is added to remember template arguments and defer substitution of requires-expressions. Incidentally, this change also fixes the two mentioned PRs -- the problem there is that tsubst_requires_expr was performing semantic checks on template trees, and some of the checks are not prepared to handle such trees. With this patch, tsubst_requires_expr no longer does any semantic checking at all when processing_template_decl. gcc/cp/ChangeLog: PR c++/96409 PR c++/96410 * constraint.cc (tsubst_requires_expr): Use REQUIRES_EXPR_PARMS and REQUIRES_EXPR_REQS. Use REQUIRES_EXPR_EXTRA_ARGS, add_extra_args and build_extra_args to defer substitution until we have all the template arguments. (finish_requires_expr): Adjust the call to build_min so that REQUIRES_EXPR_EXTRA_ARGS gets set to NULL_TREE. * cp-tree.def (REQUIRES_EXPR): Give it a third operand. * cp-tree.h (REQUIRES_EXPR_PARMS, REQUIRES_EXPR_REQS, REQUIRES_EXPR_EXTRA_ARGS): Define. (add_extra_args, build_extra_args): Declare. gcc/testsuite/ChangeLog: PR c++/96409 PR c++/96410 * g++.dg/cpp2a/concepts-lambda13.C: New test. * g++.dg/cpp2a/concepts-lambda14.C: New test.
2020-09-17Daily bump.GCC Administrator1-0/+25
2020-09-16c++: local-scope OMP UDR reductions have no template headNathan Sidwell3-33/+41
This corrects the earlier problems with removing the template header from local omp reductions. And it uncovered a latent bug. When we tsubst such a decl, we immediately tsubst its body. cp_check_omp_declare_reduction gets a success return value to gate that instantiation. udr-2.C got a further error, as the omp checking machinery doesn't appear to turn the reduction into an error mark when failing. I didn't dig into that further. udr-3.C appears to have been invalid and accidentally worked. gcc/cp/ * cp-tree.h (cp_check_omp_declare_reduction): Return bool. * semantics.c (cp_check_omp_declare_reduction): Return true on for success. * pt.c (push_template_decl_real): OMP reductions do not get a template header. (tsubst_function_decl): Remove special casing for local decl omp reductions. (tsubst_expr): Call instantiate_body for a local omp reduction. (instantiate_body): Add nested_p parm, and deal with such instantiations. (instantiate_decl): Reject FUNCTION_SCOPE entities, adjust instantiate_body call. gcc/testsuite/ * g++.dg/gomp/udr-2.C: Add additional expected error. libgomp/ * testsuite/libgomp.c++/udr-3.C: Add missing ctor.
2020-09-16c++: Avoid confusing 'nested' nameNathan Sidwell1-9/+7
instantiate_body has a local var call 'nested', which indicates that this instantiation was caused during the body of some function -- not necessarily its containing scope. That's confusing, let's just use 'current_function_decl' directly. Then we can also simplify the push_to_top_level logic, which /does/ indicate whether this is an actual nested function. (C++ does not have nested functions, but OMP ODRs fall into that category. A follow up patch will use that more usual meaning of 'nested' wrt to functions.) gcc/cp/ * pt.c (instantiate_body): Remove 'nested' var, simplify push_to_top logic.
2020-09-16c++: Break out actual instantiation from instantiate_declNathan Sidwell1-148/+157
This refactors instantiate_decl, breaking out the actual instantiation work to instantiate_body. That'll allow me to address the OMP UDR issue, but it also means we have slightly neater code in instantiate_decl anyway. gcc/cp/ * pt.c (instantiate_body): New, broken out of .. (instantiate_decl): ... here. Call it.
2020-09-16Daily bump.GCC Administrator1-0/+13
2020-09-15c++: Partially revert: local externs in templates do not get template headNathan Sidwell1-5/+9
Turns out I didn't get OMP reductions correct. To address those I need to do some reorganization, so this patch just reverts the OMP-specific pieces of the local decl changes. gcc/cp/ * pt.c (push_template_decl_real): OMP reductions retain a template header. (tsubst_function_decl): Likewise.
2020-09-15OpenMP/Fortran: Fix (re)mapping of allocatable/pointer arrays [PR96668]Tobias Burnus3-4/+4
gcc/cp/ChangeLog: PR fortran/96668 * cp-gimplify.c (cxx_omp_finish_clause): Add bool openacc arg. * cp-tree.h (cxx_omp_finish_clause): Likewise * semantics.c (handle_omp_for_class_iterator): Update call. gcc/fortran/ChangeLog: PR fortran/96668 * trans.h (gfc_omp_finish_clause): Add bool openacc arg. * trans-openmp.c (gfc_omp_finish_clause): Ditto. Use GOMP_MAP_ALWAYS_POINTER with PSET for pointers. (gfc_trans_omp_clauses): Like the latter and also if the always modifier is used. gcc/ChangeLog: PR fortran/96668 * gimplify.c (gimplify_omp_for): Add 'bool openacc' argument; update omp_finish_clause calls. (gimplify_adjust_omp_clauses_1, gimplify_adjust_omp_clauses, gimplify_expr, gimplify_omp_loop): Update omp_finish_clause and/or gimplify_for calls. * langhooks-def.h (lhd_omp_finish_clause): Add bool openacc arg. * langhooks.c (lhd_omp_finish_clause): Likewise. * langhooks.h (lhd_omp_finish_clause): Likewise. * omp-low.c (scan_sharing_clauses): Keep GOMP_MAP_TO_PSET cause for 'declare target' vars. include/ChangeLog: PR fortran/96668 * gomp-constants.h (GOMP_MAP_ALWAYS_POINTER_P): Define. libgomp/ChangeLog: PR fortran/96668 * libgomp.h (struct target_var_desc): Add has_null_ptr_assoc member. * target.c (gomp_map_vars_existing): Add always_to_flag flag. (gomp_map_vars_existing): Update call to it. (gomp_map_fields_existing): Likewise (gomp_map_vars_internal): Update PSET handling such that if a nullptr is now allocated or if GOMP_MAP_POINTER is used PSET is updated and pointer remapped. (GOMP_target_enter_exit_data): Hanlde GOMP_MAP_ALWAYS_POINTER like GOMP_MAP_POINTER. * testsuite/libgomp.fortran/map-alloc-ptr-1.f90: New test. * testsuite/libgomp.fortran/map-alloc-ptr-2.f90: New test.
2020-09-15Daily bump.GCC Administrator1-0/+12
2020-09-14c++: Use VAR_OR_FUNCTION_DECL_P.Marek Polacek1-2/+1
gcc/cp/ChangeLog: * pt.c (push_template_decl_real): Use VAR_OR_FUNCTION_DECL_P.
2020-09-14c++: local externs in templates do not get template headNathan Sidwell1-20/+27
Now we consistently mark local externs with DECL_LOCAL_DECL_P, we can teach the template machinery not to give them a TEMPLATE_DECL head, and the instantiation machinery treat them as the local specialiations they are. (openmp UDRs also fall into this category, and are dealt with similarly.) gcc/cp/ * pt.c (push_template_decl_real): Don't attach a template head to local externs. (tsubst_function_decl): Add support for headless local extern decls. (tsubst_decl): Add support for headless local extern decls.
2020-09-12Daily bump.GCC Administrator1-0/+28
2020-09-11c++: Concepts and local externsNathan Sidwell1-4/+9
I discovered that we'd accept constraints on block-scope function decls inside templates. This fixes that. gcc/cp/ * decl.c (grokfndecl): Don't attach to local extern.
2020-09-11objc++: Always pop scope with method definitions [PR97015]Nathan Sidwell1-35/+26
Syntax errors in method definition lists could leave us in a function scope. My recent change for block scope externs didn't like that. This reimplements the parsing loop to finish the method definition we started. AFAICT the original code was attempting to provide some error recovery. Also while there, simply do the token peeking at the top of the loop, rather than at the two(!) ends. gcc/cp/ * parser.c (cp_parser_objc_method_definition_list): Reimplement loop, make sure we pop scope. gcc/testsuite/ * obj-c++.dg/syntax-error-9.mm: Adjust expected errors.
2020-09-11c++: Remove LOOKUP_CONSTINIT.Marek Polacek6-29/+19
Since we now have DECL_DECLARED_CONSTINIT_P, we no longer need LOOKUP_CONSTINIT. gcc/cp/ChangeLog: * cp-tree.h (LOOKUP_CONSTINIT): Remove. (LOOKUP_REWRITTEN): Adjust. * decl.c (duplicate_decls): Set DECL_DECLARED_CONSTINIT_P. (check_initializer): Use DECL_DECLARED_CONSTINIT_P instead of LOOKUP_CONSTINIT. (cp_finish_decl): Don't set DECL_DECLARED_CONSTINIT_P. Use DECL_DECLARED_CONSTINIT_P instead of LOOKUP_CONSTINIT. (grokdeclarator): Set DECL_DECLARED_CONSTINIT_P. * decl2.c (grokfield): Don't handle LOOKUP_CONSTINIT. * parser.c (cp_parser_decomposition_declaration): Remove LOOKUP_CONSTINIT handling. (cp_parser_init_declarator): Likewise. * pt.c (tsubst_expr): Likewise. (instantiate_decl): Likewise. * typeck2.c (store_init_value): Use DECL_DECLARED_CONSTINIT_P instead of LOOKUP_CONSTINIT.
2020-09-11Daily bump.GCC Administrator1-0/+30
2020-09-10c++: TINFO_VAR_DECLARED_CONSTINIT -> DECL_DECLARED_CONSTINIT_PNathan Sidwell3-28/+11
We need to record whether template function-scopestatic decls are constinit. That's currently held on the var's TEMPLATE_INFO data. But I want to get rid of such decl's template header as they're not really templates, and they're never instantiated separately from their containing function's definition. (Just like auto vars, which don't get them for instance). This patch moves the flag into a spare decl_lang_flag. gcc/cp/ * cp-tree.h (TINFO_VAR_DECLARED_CONSTINIT): Replace with ... (DECL_DECLARED_CONSTINIT_P): ... this. * decl.c (start_decl): No need to retrofit_lang_decl for constinit flag. (cp_finish_decl): Use DECL_DECLARED_CONSTINIT_P. * pt.c (tsubst_decl): No need to handle constinit flag propagation. (tsubst_expr): Or here.
2020-09-10c++: DECL_LOCAL_FUNCTION_P -> DECL_LOCAL_DECL_PNathan Sidwell7-51/+35
Our handling of block-scope extern decls is insufficient for modern C++, in particular modules, (but also constexprs). We mark such local function decls, and this patch extends that to marking local var decls too, so mainly a macro rename. Also, we set this flag earlier, rather than learning about it when pushing the decl. This is a step towards handling these properly. gcc/cp/ * cp-tree.h (DECL_LOCAL_FUNCTION_P): Rename to ... (DECL_LOCAL_DECL_P): ... here. Accept both fns and vars. * decl.c (start_decl): Set DECL_LOCAL_DECL_P for local externs. (omp_declare_variant_finalize_one): Use DECL_LOCAL_DECL_P. (local_variable_p): Simplify. * name-lookup.c (set_decl_context_in_fn): Assert DECL_LOCAL_DECL_P is as expected. Simplify. (do_pushdecl): Don't set decl_context_in_fn for friends. (is_local_extern): Simplify. * call.c (equal_functions): Use DECL_LOCAL_DECL_P. * parser.c (cp_parser_postfix_expression): Likewise. (cp_parser_omp_declare_reduction): Likewise. * pt.c (check_default_tmpl_args): Likewise. (tsubst_expr): Assert nested reduction function is local. (type_dependent_expression_p): Use DECL_LOCAL_DECL_P. * semantics.c (finish_call_expr): Likewise. libcc1/ * libcp1plugin.cc (plugin_build_call_expr): Use DECL_LOCAL_DECL_P.
2020-09-10Daily bump.GCC Administrator1-0/+37
2020-09-09c++: Further tweaks for new-expression and paren-init [PR77841]Marek Polacek2-32/+34
This patch corrects our handling of array new-expression with ()-init: new int[4](1, 2, 3, 4); should work even with the explicit array bound, and new char[3]("so_sad"); should cause an error, but we weren't giving any. Fixed by handling array new-expressions with ()-init in the same spot where we deduce the array bound in array new-expression. I'm now always passing STRING_CSTs to build_new_1 wrapped in { } which allowed me to remove the special handling of STRING_CSTs in build_new_1. And since the DIRECT_LIST_INIT_P block in build_new_1 calls digest_init, we report errors about too short arrays. reshape_init now does the {"foo"} -> "foo" transformation even for CONSTRUCTOR_IS_PAREN_INIT, so no need to do it in build_new. I took a stab at cp_complete_array_type's "FIXME: this code is duplicated from reshape_init", but calling reshape_init there, I ran into issues with has_designator_problem: when we reshape an already reshaped CONSTRUCTOR again, d.cur.index has been filled, so we think that we have a user-provided designator (though there was no designator in the source code), and report an error. gcc/cp/ChangeLog: PR c++/77841 * decl.c (reshape_init): If we're initializing a char array from a string-literal that is enclosed in braces, unwrap it. * init.c (build_new_1): Don't handle string-initializers here. (build_new): Handle new-expression with paren-init when the array bound is known. Always pass string constants to build_new_1 enclosed in braces. Don't handle string-initializers in any special way. gcc/testsuite/ChangeLog: PR c++/77841 * g++.old-deja/g++.ext/arrnew2.C: Expect the error only in C++17 and less. * g++.old-deja/g++.robertl/eb58.C: Adjust dg-error. * g++.old-deja/g++.robertl/eb63.C: Expect the error only in C++17 and less. * g++.dg/cpp2a/new-array5.C: New test. * g++.dg/cpp2a/paren-init36.C: New test. * g++.dg/cpp2a/paren-init37.C: New test. * g++.dg/pr84729.C: Adjust dg-error.
2020-09-09c++: Fix ICE in reshape_init with init-list [PR95164]Marek Polacek1-1/+1
This patch fixes a long-standing bug in reshape_init_r. Since r209314 we implement DR 1467 which handles list-initialization with a single initializer of the same type as the target. In this test this causes a crash in reshape_init_r when we're processing a constructor that has undergone the DR 1467 transformation. Take e.g. the foo({{1, {H{k}}}}); line in the attached test. {H{k}} initializes the field b of H in I. H{k} is a functional cast, so has TREE_HAS_CONSTRUCTOR set, so is COMPOUND_LITERAL_P. We perform the DR 1467 transformation and turn {H{k}} into H{k}. Then we attempt to reshape H{k} again and since first_initializer_p is null and it's COMPOUND_LITERAL_P, we go here: else if (COMPOUND_LITERAL_P (stripped_init)) gcc_assert (!BRACE_ENCLOSED_INITIALIZER_P (stripped_init)); then complain about the missing braces, go to reshape_init_class and ICE on gcc_checking_assert (d->cur->index == get_class_binding (type, id)); because due to the missing { } we're looking for 'b' in H, but that's not found. So we have to be prepared to handle an initializer whose outer braces have been removed due to DR 1467. gcc/cp/ChangeLog: PR c++/95164 * decl.c (reshape_init_r): When initializing an aggregate member with an initializer from an initializer-list, also consider COMPOUND_LITERAL_P. gcc/testsuite/ChangeLog: PR c++/95164 * g++.dg/cpp0x/initlist123.C: New test.
2020-09-09c++: omp reduction cleanupsNathan Sidwell2-12/+19
omp reductions are modeled as nested functions, which is a thing C++ doesn't have. Leading to much confusion until I figured out what was happening. Not helped by some duplicate code and inconsistencies in the dependent and non-dependent paths. This patch removes the parser duplication and fixes up some bookkeeping. Added some asserts and comments too. gcc/cp/ * parser.c (cp_parser_omp_declare_reduction): Refactor to avoid code duplication. Update DECL_TI_TEMPLATE's context. * pt.c (tsubst_expr): For OMP reduction function, set context to global_namespace before pushing. (tsubst_omp_udr): Assert current_function_decl, add comment about decl context.
2020-09-09c++: Fix resolving the address of overloaded pmf [PR96647]Patrick Palka3-2/+15
In resolve_address_of_overloaded_function, currently only the second pass over the overload set (which considers just the function templates in the overload set) checks constraints and performs return type deduction when necessary. But as the testcases below show, we need to do the same when considering non-template functions during the first pass. gcc/cp/ChangeLog: PR c++/96647 * class.c (resolve_address_of_overloaded_function): Check constraints_satisfied_p and perform return-type deduction via maybe_instantiate_decl when considering non-template functions in the overload set. * cp-tree.h (maybe_instantiate_decl): Declare. * decl2.c (maybe_instantiate_decl): Remove static. gcc/testsuite/ChangeLog: PR c++/96647 * g++.dg/cpp0x/auto-96647.C: New test. * g++.dg/cpp0x/error9.C: New test. * g++.dg/cpp2a/concepts-fn6.C: New test.
2020-09-05Daily bump.GCC Administrator1-0/+4
2020-09-04c++: Use iloc_sentinel in mark_use.Jason Merrill1-3/+1
gcc/cp/ChangeLog: * expr.c (mark_use): Use iloc_sentinel.
2020-09-04Daily bump.GCC Administrator1-0/+22
2020-09-03c++: Fix another PCH hash_map issue [PR96901]Jakub Jelinek1-1/+1
The recent libstdc++ changes caused lots of libstdc++-v3 tests FAILs on i686-linux, all of them in the same spot during constexpr evaluation of a recursive _S_gcd call. The problem is yet another hash_map that used the default hasing of tree keys through pointer hashing which is preserved across PCH write/read. During PCH handling, the addresses of GC objects are changed, which means that the hash values of the keys in such hash tables change without those hash tables being rehashed. Which in the fundef_copies_table case usually means we just don't find a copy of a FUNCTION_DECL body for recursive uses and start from scratch. But when the hash table keeps growing, the "dead" elements in the hash table can sometimes reappear and break things. In particular what I saw under the debugger is when the fundef_copies_table hash map has been used on the outer _S_gcd call, it didn't find an entry for it, so returned a slot with *slot == NULL, which is treated as that the function itself is used directly (i.e. no recursion), but that addition of a hash table slot caused the recursive _S_gcd call to actually find something in the hash table, unfortunately not the new *slot == NULL spot, but a different one from the pre-PCH streaming which contained the returned toplevel (non-recursive) call entry for it, which means that for the recursive _S_gcd call we actually used the same trees as for the outer ones rather than a copy of those, which breaks constexpr evaluation. 2020-09-03 Jakub Jelinek <jakub@redhat.com> PR c++/96901 * tree.h (struct decl_tree_traits): New type. (decl_tree_map): New typedef. * constexpr.c (fundef_copies_table): Change type from hash_map<tree, tree> * to decl_tree_map *.
2020-09-03c++: Fix P0960 in member init list and array [PR92812]Marek Polacek3-36/+53
This patch nails down the remaining P0960 case in PR92812: struct A { int ar[2]; A(): ar(1, 2) {} // doesn't work without this patch }; Note that when the target object is not of array type, this already works: struct S { int x, y; }; struct A { S s; A(): s(1, 2) { } // OK in C++20 }; because build_new_method_call_1 takes care of the P0960 magic. It proved to be quite hairy. When the ()-list has more than one element, we can always create a CONSTRUCTOR, because the code was previously invalid. But when the ()-list has just one element, it gets all kinds of difficult. As usual, we have to handle a("foo") so as not to wrap the STRING_CST in a CONSTRUCTOR. Always turning x(e) into x{e} would run into trouble as in c++/93790. Another issue was what to do about x({e}): previously, this would trigger "list-initializer for non-class type must not be parenthesized". I figured I'd make this work in C++20, so that given struct S { int x, y; }; you can do S a[2]; [...] A(): a({1, 2}) // initialize a[0] with {1, 2} and a[1] with {} It also turned out that, as an extension, we support compound literals: F (): m((S[1]) { 1, 2 }) so this has to keep working as before. Moreover, make sure not to trigger in compiler-generated code, like =default, where array assignment is allowed. I've factored out a function that turns a TREE_LIST into a CONSTRUCTOR to simplify handling of P0960. paren-init35.C also tests this with vector types. gcc/cp/ChangeLog: PR c++/92812 * cp-tree.h (do_aggregate_paren_init): Declare. * decl.c (do_aggregate_paren_init): New. (grok_reference_init): Use it. (check_initializer): Likewise. * init.c (perform_member_init): Handle initializing an array from a ()-list. Use do_aggregate_paren_init. gcc/testsuite/ChangeLog: PR c++/92812 * g++.dg/cpp0x/constexpr-array23.C: Adjust dg-error. * g++.dg/cpp0x/initlist69.C: Likewise. * g++.dg/diagnostic/mem-init1.C: Likewise. * g++.dg/init/array28.C: Likewise. * g++.dg/cpp2a/paren-init33.C: New test. * g++.dg/cpp2a/paren-init34.C: New test. * g++.dg/cpp2a/paren-init35.C: New test. * g++.old-deja/g++.brendan/crash60.C: Adjust dg-error. * g++.old-deja/g++.law/init10.C: Likewise. * g++.old-deja/g++.other/array3.C: Likewise.