aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-04-12c++: treat NON_DEPENDENT_EXPR as not potentially constant [PR104507]Patrick Palka2-1/+17
Here we're crashing from potential_constant_expression because it tries to perform trial evaluation of the first operand '(bool)__r' of the conjunction (which is overall wrapped in a NON_DEPENDENT_EXPR), but cxx_eval_constant_expression ICEs on unsupported trees (of which CAST_EXPR is one). The sequence of events is: 1. build_non_dependent_expr for the array subscript yields NON_DEPENDENT_EXPR<<<(bool)__r && __s>>> ? 1 : 2 2. cp_build_array_ref calls fold_non_dependent_expr on this subscript (after this point, processing_template_decl is cleared) 3. during which, the COND_EXPR case of tsubst_copy_and_build calls fold_non_dependent_expr on the first operand 4. during which, we crash from p_c_e_1 because it attempts trial evaluation of the CAST_EXPR '(bool)__r'. Note that even if this crash didn't happen, fold_non_dependent_expr from cp_build_array_ref would still ultimately be one big no-op here since neither constexpr evaluation nor tsubst handle NON_DEPENDENT_EXPR. In light of this and of the observation that we should never see NON_DEPENDENT_EXPR in a context where a constant expression is needed (it's used primarily in the build_x_* family of functions), it seems futile for p_c_e_1 to ever return true for NON_DEPENDENT_EXPR. And the otherwise inconsistent handling of NON_DEPENDENT_EXPR between p_c_e_1, cxx_evaluate_constexpr_expression and tsubst apparently leads to weird bugs such as this one. PR c++/104507 gcc/cp/ChangeLog: * constexpr.c (potential_constant_expression_1) <case NON_DEPENDENT_EXPR>: Return false instead of recursing. Assert tf_error isn't set. gcc/testsuite/ChangeLog: * g++.dg/template/non-dependent21.C: New test. (cherry picked from commit c19f317a78c0e4c1b51d0e5a8e4c0a3b985b7a8e)
2022-04-12c++: constrained auto in lambda using outer tparms [PR103706]Patrick Palka4-10/+51
Here we're crashing during satisfaction of the lambda's placeholder type constraints because the constraints depend on the template arguments from the enclosing scope, which aren't part of the lambda's DECL_TI_ARGS. This patch fixes this by making do_auto_deduction consider the "regenerating" template arguments of a lambda for satisfaction, mirroring what's done in satisfy_declaration_constraints. PR c++/103706 gcc/cp/ChangeLog: * constraint.cc (satisfy_declaration_constraints): Use lambda_regenerating_args instead. * cp-tree.h (lambda_regenerating_args): Declare. * pt.c (lambda_regenerating_args): Define, split out from satisfy_declaration_constraints. (do_auto_deduction): Use lambda_regenerating_args to obtain the full set of outer template arguments for satisfaction when inside a lambda. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-lambda18.C: New test. (cherry picked from commit 34ba3d9a2bf72742b1c150a2dd17d10e3e3f0964)
2022-04-12c++: var tmpl w/ dependent constrained auto type [PR103341]Patrick Palka3-1/+36
When deducing the type of a variable template (or templated static data member) with a constrained auto type, we might need its template arguments for satisfaction since the constraint could depend on them. PR c++/103341 gcc/cp/ChangeLog: * decl.c (cp_finish_decl): Pass the template arguments of a variable template specialization or a templated static data member to do_auto_deduction when the auto is constrained. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-class4.C: New test. * g++.dg/cpp2a/concepts-var-templ2.C: New test. (cherry picked from commit e272cf95ba048fde60b21aee046c9ca9c9264425)
2022-04-12c++: deleted fn and noexcept inst [PR101532, PR104225]Patrick Palka3-0/+19
Here when attempting to use B's implicitly deleted default constructor, mark_used rightfully returns false, but for the wrong reason: it tries to instantiate the synthesized noexcept specifier which then only silently fails because get_defaulted_eh_spec suppresses diagnostics for deleted functions. This lack of diagnostics causes us to crash on the first testcase below (thanks to the assert in finish_expr_stmt), and silently accept the second testcase. To fix this, this patch makes mark_used avoid attempting to instantiate the noexcept specifier of a deleted function, so that we'll instead directly reject (and diagnose) the function due to its deletedness. PR c++/101532 PR c++/104225 gcc/cp/ChangeLog: * decl2.c (mark_used): Don't consider maybe_instantiate_noexcept on a deleted function. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/nsdmi-template21.C: New test. * g++.dg/cpp0x/nsdmi-template21a.C: New test. (cherry picked from commit bc90dd0ecf02e11d47d1af7f627e2e2acaa40106)
2022-04-12c++: requires-expr in pack expansion using pack [PR103105]Patrick Palka3-1/+42
Here after dependent substitution of {Ts...} into the alias 'wrap', since we never partially instantiate a requires-expr, we end up with a requires-expr whose REQUIRES_EXPR_EXTRA_ARGS contains an ARGUMENT_PACK_SELECT (which just resolves to the parameter pack Ts). Then when hashing the resulting dependent specialization of A, we crash from iterative_hash_template_arg since it deliberately doesn't handle ARGUMENT_PACK_SELECT. Like in r12-7102-gdb5f1c17031ad8, it seems the right fix here is to resolve ARGUMENT_PACK_SELECT arguments before storing them into an extra args tree (such as REQUIRES_EXPR). PR c++/103105 gcc/cp/ChangeLog: * pt.c (build_extra_args): Call preserve_args. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-requires29.C: New test. * g++.dg/cpp2a/concepts-requires29a.C: New test. (cherry picked from commit e2c7070ac7740508a7c49bfee9f895e216a272d6)
2022-04-12c++: lambda in pack expansion using pack in constraint [PR103706]Patrick Palka2-2/+49
Here when expanding the pack expansion pattern containing a constrained lambda, the template argument for each Ts is an ARGUMENT_PACK_SELECT, which we store inside the lambda's LAMBDA_EXPR_REGEN_INFO. Then during satisfaction of the lambda's constraint C<Ts> the satisfaction cache uses this argument as part of the key to the corresponding sat_entry, but iterative_hash_template_arg and template_args_equal deliberately don't handle ARGUMENT_PACK_SELECT. Since it's wrong to preserve ARGUMENT_PACK_SELECT inside a hash table due to its instability (as documented in iterative_hash_template_arg), this patch helps make sure the satisfaction cache doesn't see such trees by resolving ARGUMENT_PACK_SELECT arguments before adding them to LAMBDA_EXPR_REGEN_INFO. PR c++/103706 gcc/cp/ChangeLog: * pt.c (preserve_args): New function. (tsubst_lambda_expr): Use it when setting LAMBDA_EXPR_REGEN_INFO. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-lambda19.C: New test. (cherry picked from commit db5f1c17031ad8a898d77121f1e0e0141306e22a)
2022-04-12libstdc++: Prevent -Wstringop-overread warning in std::deque [PR100516]Jonathan Wakely2-0/+17
The compiler warns about the loop in deque::_M_range_initialize because it doesn't know that the number of nodes has already been correctly sized to match the size of the input. Use __builtin_unreachable to tell it that the loop will never be entered if the number of elements is smaller than a single node. libstdc++-v3/ChangeLog: PR libstdc++/100516 * include/bits/deque.tcc (_M_range_initialize<ForwardIterator>): Add __builtin_unreachable to loop. * testsuite/23_containers/deque/100516.cc: New test. (cherry picked from commit eae41b4d2cc30327f9f15c7390438c46aa09ed3f)
2022-04-12rs6000: Handle pcrel sibcalls to longcall functions [PR104894]Peter Bergner3-2/+53
Before PCREL in POWER10, we were not allowed to perform sibcalls to longcall functions since callee's return would skip the TOC restore in the caller. However, with PCREL we can now safely perform a sibling call to longcall functions. The problem with the current code is that pcrel sibcall branches to a PLT stub label even though -fno-plt was used. The solution here is to check for a pcrel longcall and emit an inline plt stub in that case. 2022-04-11 Peter Bergner <bergner@linux.ibm.com> gcc/ PR target/104894 * config/rs6000/rs6000.c (rs6000_sibcall_aix): Handle pcrel sibcalls to longcall functions. gcc/testsuite/ PR target/104894 * gcc.target/powerpc/pr104894.c: New test. * gcc.target/powerpc/pr104894-2.c: New test. (cherry picked from commit d74c4c6a1b4956b5cd9b2a770bb7261836fa1289)
2022-04-12libstdc++: Fix std::exception_ptr regressions [PR103630]Jonathan Wakely2-6/+52
This restores support for std::make_exception_ptr<E&> and for using std::exception_ptr in C++98. Because the new non-throwing implementation needs to use std::decay to handle references the original throwing implementation is used for C++98. We also need to change the typeid expression so it doesn't yield the dynamic type when the function parameter is a reference to a polymorphic type. Otherwise the new exception object could be caught by any handler matching the dynamic type, even though the actual exception object is only a copy of the base class, sliced to the static type. libstdc++-v3/ChangeLog: PR libstdc++/103630 * libsupc++/exception_ptr.h (exception_ptr): Fix exception specifications on inline definitions. (make_exception_ptr): Decay the template parameter. Use typeid of the static type. * testsuite/18_support/exception_ptr/103630.cc: New test. (cherry picked from commit a1ca039fc0fe934ef36c25d8284e6e116bcaffa7)
2022-04-12libstdc++: Disable atomic wait for freestanding [PR105021]Jonathan Wakely1-1/+1
We use either condition variables or futexes to implement atomic waits, so we can't do it in freestanding. This is non-conforming, so should be revisited later, probably by making freestanding atomic waiting operations spin without ever blocking. Reviewed-by: Thomas Rodgers <trodgers@redhat.com> libstdc++-v3/ChangeLog: PR libstdc++/105021 * include/bits/atomic_base.h [!_GLIBCXX_HOSTED]: Do not include <bits/atomic_wait.h> for freestanding. (cherry picked from commit 5bf59b004808abf6acbfe5ef54a0f9216b8dce22)
2022-04-12libstdc++: Guard mutex and condvar with gthreads macro [PR103638]Jonathan Wakely1-0/+4
A mutex and condition variable is used for timed waits on atomics if there is no "platform wait" (e.g. futex) supported. But the use of those types wasn't guarded by the _GLIBCXX_HAS_GTHREADS macro, causing errors for --disable-threads builds. This fix allows <atomic> to work on targets with futexes but no gthreads. libstdc++-v3/ChangeLog: PR libstdc++/103638 * include/bits/atomic_timed_wait.h: Check _GLIBCXX_HAS_GTHREADS before using std::mutex and std::__condvar. (cherry picked from commit ffb632517fc446474baba10ee2ff13a218ec2c7b)
2022-04-12libstdc++: Add missing noexcept to std::variant helperJonathan Wakely1-1/+1
libstdc++-v3/ChangeLog: * include/std/variant (__detail::__variant::__as): Add missing noexcept to first overload. (cherry picked from commit 728e639d82099035fdfe69b716a54717ae7050e0)
2022-04-12libstdc++: Allow visiting inherited variants [PR 90943]Jonathan Wakely3-12/+79
Implement the changes from P2162R2 (as a DR for C++17). Signed-off-by: Jonathan Wakely <jwakely@redhat.com> libstdc++-v3/ChangeLog: PR libstdc++/90943 * include/std/variant (__cpp_lib_variant): Update value. (__detail::__variant::__as): New helpers implementing the as-variant exposition-only function templates. (visit, visit<R>): Use __as to upcast the variant parameters. * include/std/version (__cpp_lib_variant): Update value. * testsuite/20_util/variant/visit_inherited.cc: New test. (cherry picked from commit c46ecb0112e91c80ee111439e79a58a953e4479d)
2022-04-12c++: operator new lookup [PR98249]Jason Merrill2-1/+10
The standard says, as we quote in the comment just above, that if we don't find operator new in the allocated type, it should be looked up in the global scope. This is specifically ::, not just any namespace, and we already give an error for an operator new declared in any other namespace. PR c++/98249 gcc/cp/ChangeLog: * call.c (build_operator_new_call): Just look in ::. gcc/testsuite/ChangeLog: * g++.dg/lookup/new3.C: New test.
2022-04-12c++: -Wshadow=compatible-local type vs var [PR100608]Jason Merrill2-0/+14
The patch for PR92024 changed -Wshadow=compatible-local to warn if either new or old decl was a type, but the rationale only talked about the case where both are types. If only one is, they aren't compatible. PR c++/100608 gcc/cp/ChangeLog: * name-lookup.c (check_local_shadow): Use -Wshadow=local if exactly one of 'old' and 'decl' is a type. gcc/testsuite/ChangeLog: * g++.dg/warn/Wshadow-compatible-local-3.C: New test.
2022-04-12c++: elaborated-type-spec in requires-expr [PR101677]Jason Merrill4-4/+21
We were failing to declare class S in the global namespace because we were treating the requires-expression parameter scope as a normal block scope, so the implicit declaration went there. It seems to me that the requires parameter scope is more like a function parameter scope (not least in the use of the word "parameter"), so let's change the scope kind. But then we need to adjust the prohibition on placeholders declaring implicit template parameters. PR c++/101677 gcc/cp/ChangeLog: * name-lookup.h (struct cp_binding_level): Add requires_expression bit-field. * parser.c (cp_parser_requires_expression): Set it. (synthesize_implicit_template_parm): Check it. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-pr67178.C: Adjust error. * g++.dg/cpp2a/concepts-requires28.C: New test.
2022-04-12c++: hash table ICE with variadic alias [PR105003]Jason Merrill3-24/+84
For PR104008 we thought it might be enough to keep strip_typedefs from removing this alias template specialization, but this PR demonstrates that other parts of the compiler also need to know to consider it dependent. So, this patch changes complex_alias_template_p to no longer consider template parameters used when their only use appears in a pack expansion, unless they are the parameter packs being expanded. To do that I also needed to change it to use cp_walk_tree instead of for_each_template_parm. It occurs to me that find_template_parameters should probably also use cp_walk_tree, but I'm not messing with that now. PR c++/105003 PR c++/104008 PR c++/102869 gcc/cp/ChangeLog: * pt.c (complex_alias_template_r): walk_tree callback, replacing uses_all_template_parms_r, complex_pack_expansion_r. (complex_alias_template_p): Adjust. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/variadic-alias6.C: New test. * g++.dg/cpp0x/variadic-alias7.C: New test.
2022-04-12c++: repeated friend template [PR101894]Jason Merrill2-0/+12
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.c (duplicate_decls): Copy DECL_FRIEND_CONTEXT. gcc/testsuite/ChangeLog: * g++.dg/lookup/friend22.C: New test.
2022-04-12c++: CTAD and member function references [PR103943]Jason Merrill2-6/+79
More quirks of rewriting member references to dependent references for CTAD. A reference to a member of dependent scope is definitely dependent. And since r11-7044, tsubst_baselink builds a SCOPE_REF, so tsubst_qualified_id should just use it. PR c++/103943 gcc/cp/ChangeLog: * pt.c (tsubst_qualified_id): Handle getting SCOPE_REF from tsubst_baselink. (instantiation_dependent_scope_ref_p): Check dependent_scope_p. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/class-deduction109.C: New test.
2022-04-12c++: nested generic lambda in DMI [PR101717]Jason Merrill2-1/+14
We were already checking COMPLETE_TYPE_P to recognize instantiation of a generic lambda, but didn't consider that we might be nested in a non-generic lambda. PR c++/101717 gcc/cp/ChangeLog: * lambda.c (lambda_expr_this_capture): Check all enclosing lambdas for completeness. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/lambda-generic-this4.C: New test.
2022-04-12c++: conversion with trailing return type [PR101051]Jason Merrill2-2/+19
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.c (grokdeclarator): Reject conversion with trailing return sooner. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/trailing15.C: New test.
2022-04-12libstdc++: Avoid overflow in bounds checks [PR103955]Patrick Palka2-13/+64
We currently crash when the floating-point to_chars overloads are passed a precision value near INT_MAX, ultimately due to overflow in the bounds checks that verify the output range is large enough. The simplest portable fix seems to be to replace bounds checks of the form A >= B + C (where B + C may overflow) with the otherwise equivalent check A >= B && A - B >= C, which is the approach this patch takes. Before we could do this in __floating_to_chars_hex, there we first need to track the unbounded "excess" precision (i.e. the number of trailing fractional digits in the output that are guaranteed to be '0') separately from the bounded "effective" precision (i.e. the number of significant fractional digits in the output), like we do in __f_t_c_precision. PR libstdc++/103955 libstdc++-v3/ChangeLog: * src/c++17/floating_to_chars.cc (__floating_to_chars_hex): Track the excess precision separately from the effective precision. Avoid overflow in bounds check by splitting it into two checks. (__floating_to_chars_precision): Avoid overflow in bounds checks similarly. * testsuite/20_util/to_chars/103955.cc: New test. (cherry picked from commit c0e355c77972d96fcec2ff7da047ad03e10e51d9)
2022-04-12libstdc++: Implement LWG 3595 changes to common_iteratorPatrick Palka1-4/+6
libstdc++-v3/ChangeLog: * include/bits/stl_iterator.h (common_iterator::__arrow_proxy): Make fully constexpr as per LWG 3595. (common_iterator::__postfix_proxy): Likewise. (cherry picked from commit 1556e447c0fee5c77ccd9bda243d5281e10e895b)
2022-04-12libstdc++: Implement LWG 3591-3592 changes to split_viewPatrick Palka1-5/+9
libstdc++-v3/ChangeLog: * include/std/ranges (split_view::base): Add forward_range constraint as per LWG 3591. (split_view::begin, lazy_split_view::end): Also check simpleness of _Pattern as per LWG 3592. (cherry picked from commit 2d3ac6039074832978ce9bcd41ba93ef4812458f)
2022-04-12libstdc++: Implement LWG 3535 changes to ranges::join_viewPatrick Palka1-2/+4
libstdc++-v3/ChangeLog: * include/std/ranges (join_view::__iter_cat::_S_iter_cat): Adjust criteria for returning bidirectional_iterator_tag as per LWG 3535. (join_view::_Iterator::_S_iter_concept): Likewise. (cherry picked from commit 6667274b0593a64dd3de3c7c3565bec42af35b62)
2022-04-12libstdc++: Implement LWG 3481 change to ranges::viewable_rangePatrick Palka2-1/+17
libstdc++-v3/ChangeLog: * include/bits/ranges_base.h (viewable_range): Adjust as per LWG 3481. * testsuite/std/ranges/adaptors/all.cc (test07): New test. (cherry picked from commit a2c2dcc6ca205a8c5c76b04ef2eb4fb097dcb069)
2022-04-12libstdc++: Implement LWG 3580 change to ranges::iota_viewPatrick Palka1-2/+8
libstdc++-v3/ChangeLog: * include/std/ranges (iota_view::_Iterator::operator+): Adjust definition as per LWG 3580. (iota_view::_Iterator::operator-): Likewise. (cherry picked from commit 5566f3c6b46cf053ae4b918513e318561b7af053)
2022-04-12libstdc++: Implement LWG 3470 change to ranges::subrangePatrick Palka2-4/+28
libstdc++-v3/ChangeLog: * include/bits/ranges_util.h (__detail::__uses_nonqualification_pointer_conversion): Define and use it ... (__detail::__convertible_to_nonslicing): ... here, as per LWG 3470. * testsuite/std/ranges/subrange/1.cc: New test. (cherry picked from commit 98af6b86bc6cac705474c14bb3f9748f6866c859)
2022-04-12libstdc++: Implement LWG 3523 changes to ranges::iota_viewPatrick Palka2-0/+42
libstdc++-v3/ChangeLog: * include/std/ranges (iota_view::_Iterator): Befriend iota_view. (iota_view::_Sentinel): Likewise. (iota_view::iota_view): Add three overloads, each taking an iterator/sentinel pair as per LWG 3523. * testsuite/std/ranges/iota/iota_view.cc (test06): New test. (cherry picked from commit 861440a77b62756d200ae356c4fdfd9653902e77)
2022-04-12tree-optimization/105235 - clean EH in execute_cse_conv_1Richard Biener2-6/+21
When a FP conversion is removed we have to eventually clean EH. 2022-04-12 Richard Biener <rguenther@suse.de> PR tree-optimization/105235 * tree-ssa-math-opts.c (execute_cse_conv_1): Clean EH and return whether the CFG changed. (execute_cse_sincos_1): Adjust. * g++.dg/opt/pr105235-1.C: New testcase. (cherry picked from commit 31cccadcf2d3cc8acb7a5f36ed57ca847f7ea0ea)
2022-04-12tree-optimization/105232 - handle overly large sizes in component_ref_sizeRichard Biener1-0/+2
The following properly checks tree_fits_poly_int64_p before converting a size to a poly_int64. 2022-04-12 Richard Biener <rguenther@suse.de> PR tree-optimization/105232 * tree.c (component_ref_size): Bail out for too large or non-constant sizes. (cherry picked from commit 1bd96873cf73c4f59de48e9bc0d17a498f1ede04)
2022-04-12tree-optimization/105226 - avoid splitting abnormal edgesRichard Biener2-1/+25
Vectorizer loop versioning tries to version outer loops if possible but fails to check whether it can actually split the single exit edge as it will do. 2022-04-12 Richard Biener <rguenther@suse.de> PR tree-optimization/105226 * tree-vect-loop-manip.c (vect_loop_versioning): Verify we can split the exit of an outer loop we choose to version. * gcc.dg/pr105226.c: New testcase. (cherry picked from commit 62d5bb0f35fb6ec373eaac942755585a633528a0)
2022-04-12Daily bump.GCC Administrator3-1/+35
2022-04-11ppc: testsuite: require target effectively [PR104253]Alexandre Oliva1-1/+2
The testcase was missing dg- before require-effective-target. While at that, I'm also pruning the excess-error warning I got when the test failed to be disabled because of the above. I suppose it might be useful for some target variants. for gcc/testsuite/ChangeLog PR target/104253 * gcc.target/powerpc/pr104253.c: Add missing dg- before require-effective-target. Prune warning about -mfloat128 possibly not being fully supported. (cherry picked from commit ab0f04e4df1b7b312a4c9fa9b4d675778a0bae86)
2022-04-11RISC-V: Support -misa-spec for arch-canonicalize and multilib-generator. ↵Kito Cheng3-17/+51
[PR104853] We migrate the default ISA spec version from 2.2 to 20191213, but those scripts aren't updated at the same time, this patch is making both scripts support different ISA spec versions. gcc/ChangeLog: PR target/104853 * config.gcc: Pass -misa-spec to arch-canonicalize and multilib-generator. * config/riscv/arch-canonicalize: Adding -misa-spec option. (SUPPORTED_ISA_SPEC): New. (arch_canonicalize): New argument `isa_spec`. Handle multiple ISA spec versions. * config/riscv/multilib-generator: Adding -misa-spec option. (cherry picked from commit 4132f6ba9583e128a00d55961ae8c8e7245b2223)
2022-04-11RISC-V: Allow multi-lib build with different code modelKito Cheng2-30/+73
--with-multilib-generator was only support for different ISA/ABI combination, however code model is effect the code gen a lots it should able to handled in multilib mechanism. Adding `--cmodel=` option to `--with-multilib-generator` to generating multilib combination with different code model. E.g. --with-multilib-generator="rv64ima-lp64--;--cmodel=medlow,medany" will generate 3 multi-lib suppport: 1) rv64ima with lp64 2) rv64ima with lp64 and medlow code model 3) rv64ima with lp64 and medany code model gcc/ * config/riscv/multilib-generator: Support code model option for multi-lib. * doc/install.texi: Add document of new option for --with-multilib-generator. (cherry picked from commit fdd40498d1981fde0720a0886d6f59ea5fb7ab40)
2022-04-11Daily bump.GCC Administrator3-1/+62
2022-04-10Fortran: a RECURSIVE procedure cannot be an INTRINSICHarald Anlauf2-0/+15
gcc/fortran/ChangeLog: PR fortran/105138 * intrinsic.c (gfc_is_intrinsic): When a symbol refers to a RECURSIVE procedure, it cannot be an INTRINSIC. gcc/testsuite/ChangeLog: PR fortran/105138 * gfortran.dg/recursive_reference_3.f90: New test. Co-authored-by: Steven G. Kargl <kargl@gcc.gnu.org> (cherry picked from commit d46685b04071a485b56de353d997a866bfc8caba)
2022-04-10fortran: Separate associate character lengths earlier [PR104570]Mikael Morin3-3/+45
This change workarounds an ICE in the evaluation of the character length of an array expression referencing an associate variable; the code is not prepared to see a non-scalar expression as it doesn’t initialize the scalarizer. Before this change, associate length symbols get a new gfc_charlen at resolution stage to unshare them from the associate expression, so that at translation stage it is a decl specific to the associate symbol that is initialized, not the decl of some other symbol. This reinitialization of gfc_charlen happens after expressions referencing the associate symbol have been parsed, so that those expressions retain the original gfc_charlen they have copied from the symbol. At translation stage, the gfc_charlen for the associate symbol is setup with the decl holding the actual length value, but the expressions have retained the original gfc_charlen without any decl. So they need to evaluate the character length, and this is where the ICE happens. This change moves the reinitialization of gfc_charlen earlier at parsing stage, so that at resolution stage the gfc_charlen can be retained as it’s already not shared with any other symbol, and the expressions which now share their gfc_charlen with the symbol are automatically updated when the length decl is setup at translation stage. There is no need any more to evaluate the character length as it has all the required information, and the ICE doesn’t happen. The first resolve.c hunk is necessary to avoid regressing on the associate_35.f90 testcase. PR fortran/104228 PR fortran/104570 gcc/fortran/ChangeLog: * parse.c (parse_associate): Use a new distinct gfc_charlen if the copied type has one whose length is not known to be constant. * resolve.c (resolve_assoc_var): Reset charlen if it’s shared with the associate target regardless of the expression type. Don’t reinitialize charlen if it’s deferred. gcc/testsuite/ChangeLog: * gfortran.dg/associate_58.f90: New test. (cherry picked from commit 907811ddc35da6c1701ed22355ece63a8c3ed7fb)
2022-04-10fortran: Unshare associate var charlen [PR104228]Mikael Morin4-2/+39
PR104228 showed that character lengths were shared between associate variable and associate targets. This is problematic when the associate target is itself a variable and gets a variable to hold the length, as the length variable is added (and all the variables following it in the chain) to both the associate variable scope and the target variable scope. This caused an ICE when compiling with -O0 -fsanitize=address. This change forces the creation of a separate character length for the associate variable. It also forces the initialization of the character length variable to avoid regressing associate_32 and associate_47 tests. PR fortran/104228 gcc/fortran/ChangeLog: * resolve.c (resolve_assoc_var): Also create a new character length for non-dummy associate targets. * trans-stmt.c (trans_associate_var): Initialize character length even if no temporary is used for the associate variable. gcc/testsuite/ChangeLog: * gfortran.dg/asan/associate_58.f90: New test. * gfortran.dg/asan/associate_59.f90: New test. (cherry picked from commit 57da34939703a6e6d3267a0d25d1fb9369d3ac0e)
2022-04-10Daily bump.GCC Administrator1-1/+1
2022-04-09Daily bump.GCC Administrator4-1/+37
2022-04-08c++: parameter pack inside static_assert [PR99893]Patrick Palka2-0/+14
Here, we're not finding the parameter pack inside the static_assert because STATIC_ASSERT trees are tcc_exceptional, and we weren't explicitly walking them in cp_walk_subtrees. PR c++/99893 PR c++/103885 gcc/cp/ChangeLog: * tree.c (cp_walk_subtrees) <case STATIC_ASSERT>: New case. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/static_assert17.C: New test. (cherry picked from commit fc3fdf0f2196e805a3a43ccb73595c33673670f3)
2022-04-08tree-optimization/105198 - wrong code with predictive commoningRichard Biener2-5/+59
When predictive commoning looks for a looparound PHI it tries to match the entry value definition (a load) up with the appropriate member of the chain. But it fails to consider stmts clobbering the very same memory location inbetween the load and loop entry. In theory we could be more clever on must aliases that would be also picked up from a load (so not exactly stmt_kills_ref_p) and use the stored value from that if it is an exact match. But we currently have no way to propagate this information inside predcom. 2022-04-08 Richard Biener <rguenther@suse.de> PR tree-optimization/105198 * tree-predcom.c (find_looparound_phi): Check whether the found memory location of the entry value is clobbered inbetween the value we want to use and loop entry. * gcc.dg/torture/pr105198.c: New testcase. (cherry picked from commit e5453bcc217ea4ac53a4ac277661d6ef0ccd425b)
2022-04-08Daily bump.GCC Administrator7-1/+307
2022-04-07libstdc++: Avoid implicit narrowing from uint128_t [PR104859]Patrick Palka1-3/+3
We need to be explicit about narrowing conversions from uint128_t since, on targets that lack __int128, this type is defined as an integer-class type that is only _explicitly_ convertible to the builtin integer types. This issue was latent until r12-7563-ge32869a17b788b made the frontend correctly reject explicit conversion functions during (dependent) copy-initialization. PR libstdc++/104859 libstdc++-v3/ChangeLog: * src/c++17/floating_to_chars.cc (__floating_to_chars_hex): Be explicit when narrowing the shifted effective_mantissa, since it may have an integer-class type. (cherry picked from commit 65857caee8ccfac5007a9fd0e5f18cce5e5fe934)
2022-04-07c++: make -Wctad-maybe-unsupported respect complain [PR105143]Patrick Palka3-1/+27
We were attempting to issue a -Wctad-maybe-unsupported warning even when complain=tf_none, which led to a crash in the first testcase below and a bogus error during overload resolution in the second testcase. PR c++/105143 gcc/cp/ChangeLog: * pt.c (do_class_deduction): Check complain before attempting to issue a -Wctad-maybe-unsupported warning. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/nodiscard1.C: New test. * g++.dg/warn/Wctad-maybe-unsupported4.C: New test. (cherry picked from commit e58484a019c57b1085bbbcc1654f1944feddfe73)
2022-04-07c++: constrained template friend matching ICE [PR105064]Patrick Palka2-9/+16
Here during declaration matching for the two constrained template friends, we crash from maybe_substitute_reqs_for because the second friend doesn't yet have DECL_TEMPLATE_INFO set (we're being called indirectly from push_template_decl). As far as I can tell, this situation happens only when declaring a constrained template friend within a non-template class (as in the testcase), in which case the substitution would be a no-op anyway. So this patch rearranges maybe_substitute_reqs_for to gracefully handle missing DECL_TEMPLATE_INFO by just skipping the substitution. PR c++/105064 gcc/cp/ChangeLog: * constraint.cc (maybe_substitute_reqs_for): Don't assume DECL_TEMPLATE_INFO is available. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-friend9.C: New test. (cherry picked from commit ecb4882e362e80a1bf172453ac9b366edbb4e89c)
2022-04-07c++: double non-dep folding from finish_compound_literal [PR104565]Patrick Palka2-7/+15
In finish_compound_literal, we perform non-dependent expr folding before the call to check_narrowing ever since r9-5973. But ever since r10-7096, check_narrowing also performs non-dependent expr folding of its own. This double folding means tsubst will see non-templated trees during the second folding, which causes a spurious error in the below testcase. This patch removes the former folding operation; it seems obviated by the latter one. PR c++/104565 gcc/cp/ChangeLog: * semantics.c (finish_compound_literal): Don't perform non-dependent expr folding before calling check_narrowing. gcc/testsuite/ChangeLog: * g++.dg/template/non-dependent22.C: New test. (cherry picked from commit 6bbd8afee0036c274f5ebb5b48d6fdc2091bd046)
2022-04-07c++: dependence of member noexcept-spec [PR104079]Patrick Palka4-10/+59
Here a stale TYPE_DEPENDENT_P/_P_VALID value for f's function type after replacing the type's DEFERRED_NOEXCEPT with the parsed dependent noexcept-spec causes us to try to instantiate g's noexcept-spec ahead of time (since it in turn appears non-dependent), leading to an ICE. This patch fixes this by clearing TYPE_DEPENDENT_P_VALID in fixup_deferred_exception_variants appropriately (as in build_cp_fntype_variant). That turns out to fix the testcase for C++17 but not for C++11/14, because it's not until C++17 that a noexcept-spec is part of (and therefore affects dependence of) the function type. Since dependence of NOEXCEPT_EXPR is defined in terms of instantiation dependence, the most appropriate fix for earlier dialects seems to be to make instantiation dependence consider dependence of a noexcept-spec. PR c++/104079 gcc/cp/ChangeLog: * pt.c (value_dependent_noexcept_spec_p): New predicate split out from ... (dependent_type_p_r): ... here. (instantiation_dependent_r): Use value_dependent_noexcept_spec_p to consider dependence of a noexcept-spec before C++17. * tree.c (fixup_deferred_exception_variants): Clear TYPE_DEPENDENT_P_VALID. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/noexcept74.C: New test. * g++.dg/cpp0x/noexcept74a.C: New test. (cherry picked from commit 82e31c8973eb1a752c2ffd01005efe291d35cee3)
generated by cgit v1.1 at 2024-10-19 07:08:09 +0000