Re: [PATCH] c++: non-constant non-dependent decltype folding [PR104823]

On 3/8/22 16:57, Patrick Palka wrote: On Tue, 8 Mar 2022, Jason Merrill wrote: On 3/8/22 12:54, Patrick Palka wrote: On Mon, 7 Mar 2022, Jason Merrill wrote: On 3/7/22 14:41, Patrick Palka wrote: instantiate_non_dependent_expr_sfinae instantiates only potentially constant expressions

Re: [PATCH] c++: merge default targs for function templates [PR65396]

On 3/3/22 16:06, Patrick Palka wrote: We currently merge default template arguments for class templates, but not for function templates. This patch fixes this by splitting out the argument merging logic in redeclare_class_template into a separate function and using it in duplicate_decls as

Re: [PATCH] c++: detecting copy-init context during CTAD [PR102137]

On 3/8/22 14:38, Patrick Palka wrote: On Tue, 8 Mar 2022, Jason Merrill wrote: On 3/8/22 11:36, Patrick Palka wrote: On Mon, 7 Mar 2022, Jason Merrill wrote: On 3/7/22 10:47, Patrick Palka wrote: On Fri, 4 Mar 2022, Jason Merrill wrote: On 3/4/22 14:24, Patrick Palka wrote: Here we're

Re: [PATCH] c++: Attribute deprecated/unavailable divergence

On 3/2/22 14:31, Marek Polacek wrote: Attributes deprecated and unavailable are largely the same, except that the former produces a warning whereas the latter produces an error. So is_late_template_attribute should treat them the same. Confirmed by Iain that this divergence is not intentional:

Re: [PATCH] c++: Don't allow type-constraint auto(x) [PR104752]

On 3/2/22 14:31, Marek Polacek wrote: 104752 points out that template concept C = true; auto y = C auto(1); is ill-formed as per [dcl.type.auto.deduct]: "For an explicit type conversion, T is the specified type, which shall be auto." which doesn't allow type-constraint auto.

Re: [PATCH] c++: non-constant non-dependent decltype folding [PR104823]

On 3/8/22 12:54, Patrick Palka wrote: On Mon, 7 Mar 2022, Jason Merrill wrote: On 3/7/22 14:41, Patrick Palka wrote: instantiate_non_dependent_expr_sfinae instantiates only potentially constant expressions Hmm, that now strikes me as a problematic interface, as we don't know whether what

Re: [PATCH] c++: Don't suggest cdtor or conversion op identifiers in spelling hints [PR104806]

On 3/8/22 05:32, Jakub Jelinek wrote: On Tue, Mar 08, 2022 at 10:23:28AM +0100, Richard Biener wrote: On Tue, Mar 8, 2022 at 8:27 AM Jakub Jelinek via Gcc-patches On the following testcase, we emit "did you mean '__dt '?" in the error message. "__dt " shows there because it is

Re: [PATCH] c++: detecting copy-init context during CTAD [PR102137]

On 3/8/22 11:36, Patrick Palka wrote: On Mon, 7 Mar 2022, Jason Merrill wrote: On 3/7/22 10:47, Patrick Palka wrote: On Fri, 4 Mar 2022, Jason Merrill wrote: On 3/4/22 14:24, Patrick Palka wrote: Here we're failing to communicate to cp_finish_decl from tsubst_expr that we're in a

Re: [C++ PATCH] PR c++/96440: ICE-on-invalid-code error recovery.

On 3/7/22 08:55, Roger Sayle wrote: This patch fixes PR c++/96440 which is an ICE-on-invalid-code regression affecting mainline. This patch has been tested on x86_64-pc-linux-gnu, enabling languages c and c++, with make bootstrap and make -k check with no new failures. Ok for mainline?

Re: [C++ PATCH] PR c++/96329: ICE-on-invalid-code error recovery.

On 3/7/22 08:04, Roger Sayle wrote: This patch fixes PR c++/96329 which is an ICE-on-invalid-code regression affecting mainline. This patch has been tested on x86_64-pc-linux-gnu, enabling languages c and c++, with make bootstrap and make -k check with no new failures. Ok for mainline?

Re: [C++ PATCH] PR c++/96437: ICE-on-invalid-code error recovery.

On 3/7/22 08:33, Roger Sayle wrote: This patch fixes PR c++/96437 which is an ICE-on-invalid-code regression affecting mainline. This patch has been tested on x86_64-pc-linux-gnu, enabling languages c and c++, with make bootstrap and make -k check with no new failures. Ok for mainline?

Re: [pushed] c++: (*(fn))() [PR104618]

On 2/27/22 18:52, Jason Merrill wrote: The patch for PR90451 deferred marking to the point of actual use; we missed this one because of the parens. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/104618 gcc/cp/ChangeLog: * typeck.cc (cp_build_addr_expr_1): Also

Re: [PATCH] c++: detecting copy-init context during CTAD [PR102137]

On 3/7/22 10:47, Patrick Palka wrote: On Fri, 4 Mar 2022, Jason Merrill wrote: On 3/4/22 14:24, Patrick Palka wrote: Here we're failing to communicate to cp_finish_decl from tsubst_expr that we're in a copy-initialization context (via the LOOKUP_ONLYCONVERTING flag), which causes

Re: [PATCH] c++: non-constant non-dependent decltype folding [PR104823]

On 3/7/22 14:41, Patrick Palka wrote: instantiate_non_dependent_expr_sfinae instantiates only potentially constant expressions Hmm, that now strikes me as a problematic interface, as we don't know whether what we get back is template or non-template trees. Maybe we want to change

Re: [PATCH] c++: detecting copy-init context during CTAD [PR102137]

On 3/4/22 14:24, Patrick Palka wrote: Here we're failing to communicate to cp_finish_decl from tsubst_expr that we're in a copy-initialization context (via the LOOKUP_ONLYCONVERTING flag), which causes do_class_deduction to always consider explicit deduction guides when performing CTAD for a

Re: [PATCH] tree: Fix up warn_deprecated_use [PR104627]

On 3/1/22 14:33, Jakub Jelinek wrote: Hi! The r12-7287-g1b71bc7c8b18bd1b change improved the -Wdeprecated warning for C++, but regressed it for C, in particular in gcc.dg/deprecated.c testcase we now report a type that actually isn't deprecated as deprecated instead of the one that is

Re: [PATCH] c++: ->template and implicit typedef [PR104608]

On 2/22/22 17:46, Marek Polacek wrote: Here we have a forward declaration of Parameter for which we create an implicit typedef, which is a TYPE_DECL. Then, when looking it up at template definition time, cp_parser_template_id gets (since r12-6754) this TYPE_DECL which it can't handle. Hmm,

Re: [PATCH] c++: ICE with attribute on enumerator [PR104667]

On 2/28/22 12:22, Marek Polacek wrote: On Mon, Feb 28, 2022 at 12:16:47PM -0400, Jason Merrill wrote: On 2/25/22 17:59, Marek Polacek wrote: When processing a template, the enumerators we build don't have a type yet. But is_late_template_attribute is not prepared to see a _DECL without a

Re: [PATCH] c++: ICE with attribute on enumerator [PR104667]

On 2/25/22 17:59, Marek Polacek wrote: When processing a template, the enumerators we build don't have a type yet. But is_late_template_attribute is not prepared to see a _DECL without a type, so we crash on enum tree_code code = TREE_CODE (type); (I found that we don't give the "is

Re: [PATCH] c++: Lost deprecated/unavailable attr in class tmpl [PR104682]

On 2/25/22 17:59, Marek Polacek wrote: [ Most likely a GCC 13 patch, but I'm posting it now so that I don't lose it. ] When looking into the other PR I noticed that we fail to give a warning for a deprecated enumerator when the enum is in a class template. This only happens when the attribute

[pushed] c++: (*(fn))() [PR104618]

The patch for PR90451 deferred marking to the point of actual use; we missed this one because of the parens. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/104618 gcc/cp/ChangeLog: * typeck.cc (cp_build_addr_expr_1): Also maybe_undo_parenthesized_ref.

Re: [PATCH] c++: implicit 'this' in noexcept-spec within class tmpl [PR94944]

On 2/17/22 09:26, Patrick Palka wrote: Here when instantiating the noexcept-spec we fail to resolve the implicit object parameter for the call A::f() ultimately because maybe_instantiate_noexcept sets current_class_ptr/ref to the dependent 'this' (of type B) rather than the specialized 'this'

[pushed] c++: inlining explicit instantiations [PR104539]

The PR10968 fix cleared DECL_COMDAT to force output of explicit instantiations. Then the PR59469 fix added a call to mark_needed, after which we no longer need to clear DECL_COMDAT, and leaving it set allows us to inline explicit instantiations without worrying about symbol interposition. I

[pushed] tree: tweak warn_deprecated_use

While looking at PR90451 I noticed that this function was failing to find the attributes if called with a variant of the struct. And we were doing a redundant lookup_attribute. Tested x86_64-pc-linux-gnu, applying to trunk as obvious. gcc/ChangeLog: * tree.cc (warn_deprecated_use):

[pushed] c++: avoid duplicate deprecated warning [PR90451]

We were getting the deprecated warning twice for the same call because we called mark_used first in finish_qualified_id_expr and then again in build_over_call. Let's not call it the first time; C++17 clarified that a function is used only when it is selected from an overload set, which happens

Re: [PATCH] c++: double non-dep folding from finish_compound_literal [PR104565]

On 2/16/22 15:26, Patrick Palka wrote: In finish_compound_literal, we perform non-dependent expr folding before calling 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 cause tsubst to see

Re: [PATCH v7] c++: Add diagnostic when operator= is used as truth cond [PR25689]

On 2/16/22 02:16, Zhao Wei Liew wrote: On Wed Feb 16, 2022 at 4:06 AM +08, Jason Merrill wrote: Ah, I see. I found it a bit odd that gcc-commit-mklog auto-generated a subject with "c:", but I just went with it as I didn't know any better. Unfortunately, I can't change it now on the current

Re: [PATCH] c-family: Fix up shorten_compare for decimal vs. non-decimal float comparison [PR104510]

On 2/15/22 05:07, Jakub Jelinek wrote: Hi! The comment in shorten_compare says: /* If either arg is decimal float and the other is float, fail. */ but the callers of shorten_compare don't expect anything like failure as a possibility from the function, callers require that the function

Re: [PATCH] c++: return-type-req in constraint using only outer tparms [PR104527]

On 2/14/22 11:32, Patrick Palka wrote: Here the template context for the atomic constraint has two levels of template arguments, but since it depends only on the innermost argument T we use a single-level argument vector during substitution into the constraint (built by get_mapped_args). We

Re: [PATCH] c++: NON_DEPENDENT_EXPR is not potentially constant [PR104507]

On 2/15/22 17:00, Patrick Palka wrote: On Tue, 15 Feb 2022, Jason Merrill wrote: On 2/15/22 15:13, Patrick Palka wrote: On Tue, 15 Feb 2022, Patrick Palka wrote: Here we're crashing from potential_constant_expression because it tries to perform trial evaluation of the first operand

Re: [PATCH] c++: NON_DEPENDENT_EXPR is not potentially constant [PR104507]

On 2/15/22 15:13, Patrick Palka wrote: On Tue, 15 Feb 2022, Patrick Palka wrote: 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

Re: [PATCH] c: Add diagnostic when operator= is used as truth cond [PR25689]

On 2/15/22 11:30, Zhao Wei Liew wrote: On Tue, 15 Feb 2022 at 21:05, Jason Merrill > wrote: > >> > >> I agree. However, I can't seem to call extract_call_expr directly > >> because it calls gcc_assert > >> to assert that the resulting expression is a CALL_EXPR or

Re: [PATCH] c: Add diagnostic when operator= is used as truth cond [PR25689]

On 2/15/22 07:48, Jason Merrill wrote: On 2/15/22 05:06, Zhao Wei Liew wrote: On Tue, 15 Feb 2022 at 13:13, Jason Merrill wrote: On 2/14/22 21:30, Zhao Wei Liew wrote: On 14/02/2022, Jason Merrill wrote: +/* Returns true if EXPR is a reference to an implicit +   call to operator=(). */

Re: [PATCH] c: Add diagnostic when operator= is used as truth cond [PR25689]

On 2/15/22 05:06, Zhao Wei Liew wrote: On Tue, 15 Feb 2022 at 13:13, Jason Merrill wrote: On 2/14/22 21:30, Zhao Wei Liew wrote: On 14/02/2022, Jason Merrill wrote: +/* Returns true if EXPR is a reference to an implicit + call to operator=(). */ +static bool

Re: [PATCH] c: Add diagnostic when operator= is used as truth cond [PR25689]

On 2/14/22 21:30, Zhao Wei Liew wrote: On 14/02/2022, Jason Merrill wrote: +/* Returns true if EXPR is a reference to an implicit + call to operator=(). */ +static bool +is_assignment_overload_ref_p (tree expr) +{ + if (expr == NULL_TREE || !REFERENCE_REF_P (expr)) +return false;

[pushed] c++: TTP in member alias template [PR104107]

In the first testcase, coerce_template_template_parms was adding too much of outer_args when coercing to match P's template parameters, so that when substituting into the 'const T&' parameter we got an unrelated template argument for T. We should only add outer_args when the argument template is

Re: [PATCH] c: Add diagnostic when operator= is used as truth cond [PR25689]

On 2/12/22 01:59, Zhao Wei Liew wrote: On Fri, 11 Feb 2022 at 20:47, Jason Merrill wrote: On the other hand, for empty classes, it seems that a COMPOUND_EXPR is built in build_over_call under the is_really_empty_class guard (line 9791). I don't understand the tree structure that I should

Re: [PATCH] c++: Don't reject GOTO_EXPRs to cdtor_label in potential_constant_expression_1 [PR104513]

On 2/14/22 04:54, Jakub Jelinek wrote: return in ctors on targetm.cxx.cdtor_returns_this () target like arm is emitted as GOTO_EXPR cdtor_label where at cdtor_label it emits RETURN_EXPR with the this. Similarly, in all dtors regardless of targetm.cxx.cdtor_returns_this () a return is emitted

Re: [PATCH] Fix PR 101515 (ICE in pp_cxx_unqualified_id, at cp/cxx-pretty-print.c:128)

On 2/11/22 15:29, Qing Zhao wrote: On Feb 11, 2022, at 1:39 PM, Jason Merrill wrote: On 2/11/22 13:11, Qing Zhao wrote: Hi, Jason, On Feb 11, 2022, at 11:27 AM, Jason Merrill wrote: Sure, we might as well make this code more robust. But we can do better than if we check

Re: [PATCH] Fix PR 101515 (ICE in pp_cxx_unqualified_id, at cp/cxx-pretty-print.c:128)

On 2/11/22 13:11, Qing Zhao wrote: Hi, Jason, On Feb 11, 2022, at 11:27 AM, Jason Merrill wrote: Sure, we might as well make this code more robust. But we can do better than if we check TYPE_PTRMEMFUNC_P. Okay, so what should we print to the user if it's “TYPE_PTRMEMFUNC_P”? Print

Re: [PATCH] middle-end/104497 - gimplification of vector indexing

On 2/11/22 06:26, Richard Biener wrote: The following attempts to address gimplification of ... = VIEW_CONVERT_EXPR((i & 1) != 0 ? inv : src)[i]; which is problematic since gimplifying the base object ? inv : src produces a register temporary but GIMPLE does not really support a register

Re: [PATCH] Fix PR 101515 (ICE in pp_cxx_unqualified_id, at cp/cxx-pretty-print.c:128)

On 2/11/22 11:07, Qing Zhao wrote: Hi, Jason, On Feb 9, 2022, at 3:01 PM, Qing Zhao via Gcc-patches mailto:gcc-patches@gcc.gnu.org>> wrote: On Feb 9, 2022, at 12:23 PM, Jason Merrill > wrote: On 2/9/22 10:51, Qing Zhao wrote: On Feb 8, 2022, at 4:20 PM, Jason

Re: [PATCH] c++: Fix up constant expression __builtin_convertvector folding [PR104472]

On 2/11/22 05:13, Jakub Jelinek wrote: Hi! The following testcase ICEs, because due to the -frounding-math fold_const_call fails, which is it returns NULL, and returning NULL from cxx_eval* is wrong, all the callers rely on them to either return folded value or original with *non_constant_p =

Re: [PATCH] c: Add diagnostic when operator= is used as truth cond [PR25689]

On 2/10/22 23:01, Zhao Wei Liew wrote: On Fri, 11 Feb 2022 at 00:14, Jason Merrill wrote: On 2/9/22 21:18, Zhao Wei Liew via Gcc-patches wrote: Hi! I wrote a patch for PR 25689, but I feel like it may not be the ideal fix. Furthermore, there are some standing issues with the patch for which

[pushed] c++: ICE on xtreme-header_a.H

This test regressed after my PR103752 patch with -march=cascadelake. I don't understand why that flag makes a difference, but this patch is correct in any case. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/cp/ChangeLog: * module.cc (depset::hash::add_specializations): Use

Re: [PATCH] c: Add diagnostic when operator= is used as truth cond [PR25689]

On 2/9/22 21:18, Zhao Wei Liew via Gcc-patches wrote: Hi! I wrote a patch for PR 25689, but I feel like it may not be the ideal fix. Furthermore, there are some standing issues with the patch for which I would like tips on how to fix them. Specifically, there are 2 issues: 1. GCC warns about

Re: [PATCH] c++: memfn lookup consistency and using-decls [PR104432]

On 2/9/22 15:15, Patrick Palka wrote: On Wed, 9 Feb 2022, Jason Merrill wrote: On 2/9/22 11:36, Patrick Palka wrote: On Wed, 9 Feb 2022, Jason Merrill wrote: On 2/9/22 10:45, Patrick Palka wrote: In filter_memfn_lookup, we weren't correctly recognizing and matching up member functions

Re: [PATCH] Fix PR 101515 (ICE in pp_cxx_unqualified_id, at cp/cxx-pretty-print.c:128)

On 2/9/22 16:01, Qing Zhao wrote: On Feb 9, 2022, at 12:23 PM, Jason Merrill wrote: On 2/9/22 10:51, Qing Zhao wrote: On Feb 8, 2022, at 4:20 PM, Jason Merrill wrote: On 2/8/22 15:11, Qing Zhao wrote: Hi, This is the patch to fix PR101515 (ICE in pp_cxx_unqualified_id, at

Re: [PATCH] Fix PR 101515 (ICE in pp_cxx_unqualified_id, at cp/cxx-pretty-print.c:128)

On 2/9/22 10:51, Qing Zhao wrote: On Feb 8, 2022, at 4:20 PM, Jason Merrill wrote: On 2/8/22 15:11, Qing Zhao wrote: Hi, This is the patch to fix PR101515 (ICE in pp_cxx_unqualified_id, at cp/cxx-pretty-print.c:128) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101515 It's possible that

Re: [PATCH] c++: memfn lookup consistency and using-decls [PR104432]

On 2/9/22 11:36, Patrick Palka wrote: On Wed, 9 Feb 2022, Jason Merrill wrote: On 2/9/22 10:45, Patrick Palka wrote: In filter_memfn_lookup, we weren't correctly recognizing and matching up member functions introduced via a non-dependent using-decl. This caused us to crash in the below

Re: [PATCH] c++: memfn lookup consistency and using-decls [PR104432]

On 2/9/22 10:45, Patrick Palka wrote: In filter_memfn_lookup, we weren't correctly recognizing and matching up member functions introduced via a non-dependent using-decl. This caused us to crash in the below testcases in which we correctly pruned the overload set for the non-dependent call

[pushed] c++: modules and explicit(bool) [PR103752]

We weren't streaming a C++20 dependent explicit-specifier. gcc/cp/ChangeLog: * module.cc (trees_out::core_vals): Stream explicit specifier. (trees_in::core_vals): Likewise. * pt.cc (store_explicit_specifier): No longer static. (tsubst_function_decl): Clear

Re: [PATCH] handle "invisible" reference in -Wdangling-pointer (PR104436)

On 2/9/22 03:30, Richard Biener wrote: On Tue, Feb 8, 2022 at 11:38 PM Jason Merrill via Gcc-patches wrote: On 2/8/22 16:59, Martin Sebor wrote: Transforming a by-value arguments to by-reference as GCC does for some class types can trigger -Wdangling-pointer when the argument is used

[pushed] c++: P2493 feature test macro updates

The C++ committee just updated the values of these macros to reflect some late C++20 papers that we implement but others don't yet; see PR103891. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/c-family/ChangeLog: * c-cppbuiltin.cc (c_cpp_builtins): Update values of

Re: [PATCH] handle "invisible" reference in -Wdangling-pointer (PR104436)

On 2/8/22 16:59, Martin Sebor wrote: Transforming a by-value arguments to by-reference as GCC does for some class types can trigger -Wdangling-pointer when the argument is used to store the address of a local variable.  Since the stored value is not accessible in the caller the warning is a

Re: [PATCH] Fix PR 101515 (ICE in pp_cxx_unqualified_id, at cp/cxx-pretty-print.c:128)

On 2/8/22 15:11, Qing Zhao wrote: Hi, This is the patch to fix PR101515 (ICE in pp_cxx_unqualified_id, at cp/cxx-pretty-print.c:128) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101515 It's possible that the TYPE_NAME of a record_type is NULL, therefore when printing the TYPE_NAME, we should

Re: [PATCH] dwarf2out: Don't call expand_expr during early_dwarf [PR104407]

On 2/8/22 03:35, Richard Biener wrote: On Tue, 8 Feb 2022, Jakub Jelinek wrote: Hi! As mentioned in the PR, since PR96690 r11-2834 we call rtl_for_decl_init which can call expand_expr already during early_dwarf. The comment and PR explains it that the intent is to ensure the referenced vars

Re: [PATCH] c++: Don't emit repeated -Wshadow warnings for templates/ctors [PR104379]

On 2/8/22 03:22, Jakub Jelinek wrote: Hi! The following patch suppresses extraneous -Wshadow warnings. On the testcase without the patch we emit 14 -Wshadow warnings, with the patch just 4. It is enough to warn once e.g. during parsing of the template or the abstract ctor, while previously

Re: [PATCH] c++: Remove superflous assert [PR104403]

On 2/8/22 03:16, Jakub Jelinek wrote: Hi! I've added the assert because start_decl diagnoses such vars for C++20 and earlier: if (current_function_decl && VAR_P (decl) && DECL_DECLARED_CONSTEXPR_P (current_function_decl) && cxx_dialect < cxx23) but as can be seen, we cam

Re: [PATCH] c++: satisfaction value of type const bool [PR104410]

On 2/7/22 09:57, Patrick Palka wrote: Here constant evaluation of the atomic constraint use_func_v with T=int sensibly yields an INTEGER_CST of type const bool, but the assert in satisfaction_value expects unqualified bool. Let's just relax the assert to accept cv-qualified bool more generally.

Re: [PATCH] c++: deducing only from noexcept-spec [PR80951]

On 2/7/22 09:57, Patrick Palka wrote: The fail-fast predicate uses_deducible_template_parms used by unify_one_argument is neglecting to look inside the noexcept-spec of a function type, and this causes deduction to fail for the below testcase since the noexcept-spec is the only part of the type

Re: [PATCH] c++: lambda in pack expansion using outer pack in constraint [PR103706]

On 2/7/22 12:34, Patrick Palka wrote: On Thu, 3 Feb 2022, Jason Merrill wrote: On 2/3/22 15:55, Patrick Palka wrote: On Thu, Feb 3, 2022 at 3:20 PM Jason Merrill wrote: On 2/3/22 12:04, Patrick Palka wrote: On Wed, 2 Feb 2022, Jason Merrill wrote: On 2/2/22 12:09, Patrick Palka wrote:

Re: [PATCH] c++, v4: Further address_compare fixes [PR89074]

On 2/5/22 07:17, Jakub Jelinek wrote: On Sat, Feb 05, 2022 at 12:02:14AM +0100, Jakub Jelinek via Gcc-patches wrote: You mean for folding_cxx_constexpr ? The code does that basically, with one exception, the folding_initializer FUNCTION_DECL cmp FUNCTION_DECL case. We don't track sizes of

[pushed] c++: assignment, aggregate, array [PR104300]

The PR92385 fix meant that we see more VEC_INIT_EXPR outside of INIT_EXPR; in such cases, we need to wrap them in TARGET_EXPR. I previously fixed that in build_array_copy; we also need it in process_init_constructor. After fixing that, I needed to adjust a few places to recognize the

Re: [PATCH] c++: Improve diagnostics for template args terminated with >= or >>= [PR104319]

On 2/4/22 17:10, Jakub Jelinek wrote: On Fri, Feb 04, 2022 at 04:54:39PM -0500, Jason Merrill wrote: Bootstrapped/regtested on powerpc64le-linux, ok for trunk? Or shall it wait for GCC 13? Hmm, I lean toward GCC 13; this seems more of a stage 3 change. Ok. I see you test valid uses of >=

Re: [PATCH] c++: conditional noexcept-spec on defaulted comparison op [PR96242]

On 2/4/22 12:04, Patrick Palka wrote: On Thu, 3 Feb 2022, Jason Merrill wrote: On 2/3/22 16:06, Patrick Palka wrote: On Thu, 3 Feb 2022, Jason Merrill wrote: On 2/3/22 14:58, Patrick Palka wrote: When synthesizing a defaulted comparison op from maybe_instantiate_noexcept, we seem to be

Re: [PATCH] c++: Improve diagnostics for template args terminated with >= or >>= [PR104319]

On 2/4/22 09:12, Jakub Jelinek wrote: Hi! As mentioned in the PR, for C++98 we have diagnostics that expect terminating template arguments to be a mistake for > > (C++11 said it has to be treated that way), while if user trying to spare the spacebar doesn't separate > from following = or >>

Re: [PATCH] c++, v3: Further address_compare fixes [PR89074]

On 2/4/22 08:41, Jakub Jelinek wrote: On Thu, Feb 03, 2022 at 04:34:17PM -0500, Jason Merrill wrote: On 2/3/22 16:18, Jakub Jelinek wrote: On Thu, Feb 03, 2022 at 04:04:57PM -0500, Jason Merrill wrote: I think it would be clearer to leave the !DECL_P case alone and add /* In C++ it is

Re: [PATCH] c++: conditional noexcept-spec on defaulted comparison op [PR96242]

On 2/3/22 16:06, Patrick Palka wrote: On Thu, 3 Feb 2022, Jason Merrill wrote: On 2/3/22 14:58, Patrick Palka wrote: When synthesizing a defaulted comparison op from maybe_instantiate_noexcept, we seem to be forgetting to instantiate the noexcept-spec afterwards. Hmm, there shouldn't be any

Re: [PATCH] c++, v2: Further address_compare fixes [PR89074]

On 2/3/22 16:18, Jakub Jelinek wrote: On Thu, Feb 03, 2022 at 04:04:57PM -0500, Jason Merrill wrote: I think it would be clearer to leave the !DECL_P case alone and add /* In C++ it is unspecified, and so non-constant, whether two equivalent strings have the same address. */ else if

Re: [PATCH] c++: lambda in pack expansion using outer pack in constraint [PR103706]

On 2/3/22 15:55, Patrick Palka wrote: On Thu, Feb 3, 2022 at 3:20 PM Jason Merrill wrote: On 2/3/22 12:04, Patrick Palka wrote: On Wed, 2 Feb 2022, Jason Merrill wrote: On 2/2/22 12:09, Patrick Palka wrote: The satisfaction cache needs to look through ARGUMENT_PACK_SELECT template

Re: [PATCH] c++, v2: Further address_compare fixes [PR89074]

On 2/3/22 15:33, Jakub Jelinek wrote: On Thu, Feb 03, 2022 at 03:07:03PM -0500, Jason Merrill wrote: --- gcc/fold-const.h.jj 2022-02-01 20:10:51.235856007 +0100 +++ gcc/fold-const.h2022-02-03 15:02:02.700228631 +0100 -/* Non-zero if we are folding constants inside an initializer; zero -

Re: [PATCH] c++: conditional noexcept-spec on defaulted comparison op [PR96242]

On 2/3/22 14:58, Patrick Palka wrote: When synthesizing a defaulted comparison op from maybe_instantiate_noexcept, we seem to be forgetting to instantiate the noexcept-spec afterwards. Hmm, there shouldn't be any need to instantiate the noexcept-spec afterwards, it should have been set by

Re: [PATCH] c++: lambda in pack expansion using outer pack in constraint [PR103706]

On 2/3/22 12:04, Patrick Palka wrote: On Wed, 2 Feb 2022, Jason Merrill wrote: On 2/2/22 12:09, Patrick Palka wrote: The satisfaction cache needs to look through ARGUMENT_PACK_SELECT template arguments before calling iterative_hash_template_arg and template_args_equal, which would otherwise

Re: [PATCH] c++: dependence of member's noexcept-spec [PR104079]

On 2/3/22 11:49, Patrick Palka wrote: Here a stale value of TYPE_DEPENDENT_P/_P_VALID for f's function type after replacing its DEFERRED_NOEXCEPT with its parsed (dependent) noexcept-spec leads us to try to instantiate g's noexcept-spec (which incorrectly appears non-dependent) ahead of time,

Re: [PATCH] c++, v2: Further address_compare fixes [PR89074]

On 2/3/22 10:52, Jakub Jelinek wrote: On Tue, Jan 18, 2022 at 05:40:48PM +0100, Jakub Jelinek via Gcc-patches wrote: About the rest of the patch, I thought I had seen richi comment on IRC (but can't find the comment now) that these cases where we could give a constant answer but decide not to

Re: [PATCH v2] constrain conservative string lengths to array sizes [PR104119]

On 1/20/22 17:54, Martin Sebor wrote: The updated patch ensures the tighter bound isn't used to compute the sprintf result and adds a test to verify that.  (This is messy in the strlen/sprintf pass and should be cleaned up to avoid this mistake in the future.) Rested on x86_64-linux. OK,

Re: [PATCH] debug/104337 - avoid messing with the abstract origin chain in NRV

On 2/3/22 05:27, Richard Biener wrote: The following avoids NRV from massaging DECL_ABSTRACT_ORIGIN after variable creation since NRV runs _after_ the function was inlined and thus affects the inlined variables copy indirectly. We may adjust the abstract origin of a variable only at the point

[PATCH] c++: dependent array bounds completion [PR104302]

The patch for PR55227 changed the minimal init-list handling in cp_complete_array_type to a call to reshape_init, which broke on the dependent initializer. It occurred to me that trying to deduce the array size from a dependent init-list is wrong in general, as we can see with the second

Re: [PATCH] c++: constrained auto in lambda using outer tparms [PR103706]

On 2/2/22 13:21, Patrick Palka wrote: On Wed, 2 Feb 2022, Patrick Palka wrote: 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 a part of the lambda's

Re: [PATCH] c++: lambda in pack expansion using outer pack in constraint [PR103706]

On 2/2/22 12:09, Patrick Palka wrote: The satisfaction cache needs to look through ARGUMENT_PACK_SELECT template arguments before calling iterative_hash_template_arg and template_args_equal, which would otherwise crash. Maybe we should handle ARGUMENT_PACK_SELECT in

Re: [PATCH] libcpp: Avoid PREV_WHITE and other random content on CPP_PADDING tokens

On 2/1/22 10:31, Jakub Jelinek wrote: On Tue, Feb 01, 2022 at 10:03:57AM +0100, Jakub Jelinek via Gcc-patches wrote: I wonder if we shouldn't replace that toks[0] = pfile->directive_result; line with toks[0] = pfile->avoid_paste; or even replace those toks = XNEW

Re: [PATCH] libcpp: Fix up padding handling in funlike_invocation_p [PR104147]

On 1/31/22 14:03, Jakub Jelinek wrote: Hi! As mentioned in the PR, in some cases we preprocess incorrectly when we encounter an identifier which is defined as function-like macro, followed by at least 2 CPP_PADDING tokens and then some other identifier. On the following testcase, the problem is

PING Re: [PATCH RFA (tree)] c++: lambda in template default argument [PR103186]

Ping. On 1/26/22 18:16, Jason Merrill wrote: The problem with this testcase was that since my patch for PR97900 we weren't preserving DECL_UID identity for parameters of instantiations of templated functions, so using those parameters as the keys for the defarg_inst map broke. I think this was

Re: [PATCH] c++: CTAD for class tmpl defined inside partial spec [PR104294]

On 1/31/22 11:14, Patrick Palka wrote: On Mon, Jan 31, 2022 at 11:07 AM Patrick Palka wrote: Here during deduction guide generation for the nested class template B::C, the computation of outer_targs yields the template arguments relative to the primary template for B (i.e. {char(int)}) but

Re: [PATCH] c++: Reject union std::initializer_list [PR102434]

On 1/28/22 20:21, Marek Polacek wrote: Weird things are going to happen if you define your std::initializer_list as a union. In this case, we crash in output_constructor_regular_field. Let's not allow such a definition in the first place. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for

Re: [PATCH v2] c++: ICE with auto[] and VLA [PR102414]

On 1/28/22 15:49, Marek Polacek wrote: On Thu, Jan 27, 2022 at 10:17:00PM -0500, Jason Merrill wrote: On 1/27/22 20:02, Marek Polacek wrote: @@ -11159,8 +11159,16 @@ create_array_type_for_decl (tree name, tree type, tree size, location_t loc) /* Figure out the index type for the array.

Re: [PATCH] c++: CONSTRUCTORs are non-deduced contexts [PR104291]

On 1/31/22 12:27, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? PR c++/104291 gcc/cp/ChangeLog: * pt.cc (for_each_template_parm_r) : Don't walk subtrees if !include_nondeduced_p. Simplify given that

Re: [PATCH] c++: bogus warning with value init of const pmf [PR92752]

On 1/28/22 12:54, Patrick Palka wrote: Here we're emitting a -Wignored-qualifiers warning for an intermediate compiler-generated cast of 0 to 'method-type* const' as part of value initialization of a const pmf. This patch suppresses the warning by stripping cv-quals from this pointer type

[pushed] c++: pack in enumerator in lambda [PR100198]

The GCC 8 lambda overhaul fixed most uses of lambdas in pack expansions, but local enums and classes within such lambdas that depend on parameter packs are still broken. For now, give a sorry instead of an ICE or incorrect error. Tested x86_64-pc-linux-gnu, applying to trunk. PR

Re: [PATCH] c++: ICE with auto[] and VLA [PR102414]

On 1/27/22 20:02, Marek Polacek wrote: Here we ICE in unify_array_domain when we're trying to deduce the type of an array, as in auto(*p)[i] = (int(*)[i])0; but unify_array_domain doesn't arbitrarily complex bounds. Another test is, e.g., auto (*b)[0/0] = where the type of the array

Re: [PATCH] c++: var tmpl w/ dependent constrained auto type [PR103341]

On 1/27/22 13:06, Patrick Palka wrote: On Thu, 27 Jan 2022, Patrick Palka wrote: When deducing the type of a variable template specialization with a constrained auto type, we might need the template arguments for satisfaction in case the constraint is dependent. It looks like templated

[pushed] c++: dependent and non-dependent attributes [PR104245]

A flaw in my patch for PR51344 was that cplus_decl_attributes calls decl_attributes after save_template_attributes, which messes up the ordering that save_template_attributes set up. Fixed by splitting save_template_attributes around the call to decl_attributes. Tested x86_64-pc-linux-gnu,

Re: [PATCH] c++: constrained partial spec using qualified name [PR92944]

On 1/26/22 12:49, Patrick Palka wrote: In the nested_name_specifier branch within cp_parser_class_head, we need to update TYPE with the result of maybe_process_partial_specialization just like we do in the template_id_p branch. Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look

Re: [PATCH] c++: non-dependent immediate member fn call [PR99895]

On 1/27/22 09:02, Patrick Palka wrote: On Wed, 26 Jan 2022, Patrick Palka wrote: On Wed, 26 Jan 2022, Patrick Palka wrote: On Wed, Jan 19, 2022 at 2:19 PM Jason Merrill wrote: On 1/19/22 11:15, Patrick Palka wrote: Here we're emitting a bogus error during ahead of time evaluation of a

Re: [PATCH] c++: new-expr of array of deduced class tmpl [PR101988]

On 1/26/22 18:55, Marek Polacek wrote: In r12-1933 I attempted to implement DR2397 aka allowing int a[3]; auto ()[3] = a; by removing the type_uses_auto check in create_array_type_for_decl. That may have gone too far, because it also allows arrays of CLASS_PLACEHOLDER_TEMPLATE and it

[PATCH RFA (tree)] c++: lambda in template default argument [PR103186]

The problem with this testcase was that since my patch for PR97900 we weren't preserving DECL_UID identity for parameters of instantiations of templated functions, so using those parameters as the keys for the defarg_inst map broke. I think this was always fragile given the possibility of

[pushed] c++: vector compound literal [PR104206]

My patch for PR101072 removed the specific VECTOR_TYPE handling here, which broke pr72747-2.c on PPC; this patch restores it. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/104206 PR c++/101072 gcc/cp/ChangeLog: * semantics.cc (finish_compound_literal): Restore

[pushed] c++: ->template and using-decl [PR104235]

cp_parser_template_id wasn't prepared to handle getting a USING_DECL back from cp_parser_template_name. Let's defer that case to instantiation time, as well. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/104235 gcc/cp/ChangeLog: * parser.cc (cp_parser_template_name):

Re: [PATCH] warn-access: Prevent -Wuse-after-free on ARM [PR104213]

On 1/25/22 18:33, Marek Polacek wrote: Here, -Wuse-after-free warns about using 'this' which, on ARM, cdtors return, as mandated by the EABI. To be entirely correct, it only requires it for C1 and C2 ctors and D2 and D1 dtors, but I don't feel like changing that now and possibly running into

<    8   9   10   11   12   13   14   15   16   17   >