Re: [PATCH] c++: Fix up handling of vector CONSTRUCTORs with vectors in it in constexpr.cc [PR104226]

On 1/26/22 04:33, Jakub Jelinek wrote: Hi! The middle-end uses sometimes VECTOR_TYPE CONSTRUCTORs that contain some other VECTOR_TYPE elements in it (should be with compatible element size and smaller number of elements, e.g. a V8SImode vector can be constructed as { V4SImode_var_1,

[pushed] c++: alias template and typename [PR103057]

Usually we handle DR1558 substitution near the top of tsubst, but in this case while substituting TYPENAME_TYPE we were passing an alias specialization to tsubst_aggr_type, which ignored its aliasness. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/103057 gcc/cp/ChangeLog:

[pushed] c++: assignment to temporary [PR59950]

Given build_this of a TARGET_EXPR, cp_build_fold_indirect_ref returns the TARGET_EXPR. But that's the wrong value category for the result of the defaulted class assignment operator, which returns an lvalue, so we need to actually build the INDIRECT_REF. Tested x86_64-pc-linux-gnu, applying to

Re: [PATCH] c++: deleted fn and noexcept inst [PR101532, PR104225]

On 1/25/22 12:33, Patrick Palka wrote: On Tue, 25 Jan 2022, Patrick Palka wrote: 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 implicit noexcept specifier, which only silently

Re: [PATCH] dwarf2out: For ppc64le IEEE quad long double, emit DW_TAG_typedef to _Float128 [PR104194]

On 1/25/22 06:02, Jakub Jelinek wrote: On Mon, Jan 24, 2022 at 11:26:27PM +0100, Jakub Jelinek via Gcc-patches wrote: Yet another short term solution might be not use DW_TAG_base_type for the IEEE quad long double, but instead pretend it is a DW_TAG_typedef with DW_AT_name "long double" to

Re: [PATCH] c++: Fix non-portable default argument of make_auto_1 [PR104197]

On 1/24/22 10:27, Patrick Palka wrote: Avoid using the macro current_template_depth, which expands to an expression in terms of __FUNCTION__, within the signature of a function. Clang warns about this and MSVC rejects it. Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for

Re: [PATCH] c++: value category of compound object expr [PR104173]

On 1/22/22 16:24, Patrick Palka wrote: Here the call to the &&-qualified toLower() is incorrectly rejected because the object expression is deemed to be an lvalue, even though it's really a prvalue. The object expression, instance()->applicationName(), is expressed as an INDIRECT_REF of a

Re: [PATCH v3] c++: designated init of char array by string constant [PR55227]

On 1/17/22 14:29, will wray wrote: Attached (the cut n paste looks like it removed some whitespace formatting) Pushed, thanks! I incorporated the introduction from your initial email in the commit message. Jason

[pushed] c++: array temporary at file scope [PR104182]

This is the same issue as PR104031, but that patch doesn't fix this testcase because in this case, current_function_decl isn't set when we get to cp_genericize_target_expr. But there seems to be no need for is_local_temp to check for function scope; !TREE_STATIC should be enough. Tested

[pushed] c++: constexpr and -fno-elide-constructors [PR101072]

We've been trying for a while to avoid TARGET_EXPRs in template code, but there were still a few that snuck through, and the one in this case broke the code that tried to handle it. Fixed by using IMPLICIT_CONV_EXPR, as we have done elsewhere. I also noticed that finish_compound_literal was

[pushed] c++: explain failing static_assert

While looking at another bug I wanted the compiler to tell me what the two unequal values were. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/cp/ChangeLog: * semantics.cc (find_failing_clause): Return expr if not decomposable. (finish_static_assert): Show constant

[pushed] c++: class array new checking [PR104084]

My patch for PR20040 made us stop exiting early from build_new_1 in cases of trivial initialization if there's a class operator delete; as a result, code later in the function needs to handle this case properly. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/104084 PR

Re: [PATCH v3] c++: ICE with noexcept and canonical types [PR101715]

On 1/21/22 12:42, Marek Polacek wrote: On Fri, Jan 21, 2022 at 09:27:17AM -0500, Jason Merrill wrote: On 1/20/22 20:03, Marek Polacek wrote: @@ -2815,12 +2816,23 @@ fixup_deferred_exception_variants (tree type, tree raises) cp_cv_quals var_quals = TYPE_QUALS (variant);

[pushed] c++: [[no_unique_address]] and virtual base [PR104139]

Fixing a thinko in my patch for 103681: when computing the size of a virtual base, it would help to use its binfo instead of the one for the derived class. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/104139 PR c++/103681 gcc/cp/ChangeLog: * class.cc

Re: [PATCH v2] c++: ICE with noexcept and canonical types [PR101715]

On 1/20/22 20:03, Marek Polacek wrote: On Thu, Jan 20, 2022 at 03:23:24PM -0500, Jason Merrill wrote: On 1/18/22 11:05, Marek Polacek wrote: On Mon, Jan 17, 2022 at 01:48:48PM -0500, Jason Merrill wrote: On 1/14/22 19:22, Marek Polacek wrote: This is a "canonical types differ for identical

[pushed] c++: designator for base class member [PR101405]

A C++20 designator must name a direct non-static member of the class; in this case it names a member of a base class, and we should give an error instead of crashing. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/101405 gcc/cp/ChangeLog: * decl.cc (reshape_init_class):

Re: [PATCH] c++: ICE with noexcept and canonical types [PR101715]

On 1/18/22 11:05, Marek Polacek wrote: On Mon, Jan 17, 2022 at 01:48:48PM -0500, Jason Merrill wrote: On 1/14/22 19:22, Marek Polacek wrote: This is a "canonical types differ for identical types" ICE, which started with r11-4682. It's a bit tricky to explain. Consider: template struct

[pushed] c++: template-id with current inst qualifier [PR102300]

The patch for PR41723 properly changed one place to look into the current instantiation; now we need to fix this place as well. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/102300 gcc/cp/ChangeLog: * parser.cc (cp_parser_template_name): Use dependent_scope_p.

Re: [PATCH] c++: CTAD within alias template [PR91911]

On 1/19/22 17:32, Patrick Palka wrote: On Wed, 19 Jan 2022, Jason Merrill wrote: On 1/3/22 10:24, Patrick Palka wrote: On Wed, 22 Dec 2021, Jason Merrill wrote: On 12/21/21 14:08, Patrick Palka wrote: On Tue, Dec 21, 2021 at 2:03 PM Patrick Palka wrote: On Wed, Jun 30, 2021 at 4:23 PM

Re: [PATCH] c++: CTAD within alias template [PR91911]

On 1/3/22 10:24, Patrick Palka wrote: On Wed, 22 Dec 2021, Jason Merrill wrote: On 12/21/21 14:08, Patrick Palka wrote: On Tue, Dec 21, 2021 at 2:03 PM Patrick Palka wrote: On Wed, Jun 30, 2021 at 4:23 PM Jason Merrill wrote: On 6/30/21 4:18 PM, Patrick Palka wrote: On Wed, Jun 30,

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

On 1/19/22 11:15, Patrick Palka wrote: Here we're emitting a bogus error during ahead of time evaluation of a non-dependent immediate member function call such as a.f(args) because the defacto templated form for such a call is (a.f)(args) but we're trying to evaluate it using the intermediate

Re: [pushed] c++: input_location and lookahead [PR104025]

On 1/18/22 18:20, Jakub Jelinek wrote: On Tue, Jan 18, 2022 at 05:56:47PM -0500, Jason Merrill wrote: Debug information was getting confused because input_location was different depending on whether we had looked ahead to see if the next tokens look like a template argument list. I tried

Re: [PATCH] c++, v2: Fix handling of temporaries with consteval ctors and non-trivial dtors [PR104055]

On 1/18/22 18:07, Jakub Jelinek wrote: On Tue, Jan 18, 2022 at 11:51:31AM -0500, Jason Merrill wrote: On 1/18/22 09:26, Jakub Jelinek wrote: On Tue, Jan 18, 2022 at 09:08:03AM -0500, Jason Merrill wrote: which makes call a TARGET_EXPR with the dtor in TARGET_EXPR_CLEANUP, but then call

[pushed] c++: input_location and lookahead [PR104025]

Debug information was getting confused because input_location was different depending on whether we had looked ahead to see if the next tokens look like a template argument list. I tried resetting input_location in cp_lexer_rollback_tokens itself, but that caused regressions, so let's just do it

Re: [PATCH] waccess: Look at calls when tracking clobbers [PR104092]

On 1/18/22 13:06, Martin Sebor wrote: On 1/18/22 06:37, Richard Sandiford wrote: In this PR the waccess pass was fed:    D.10779 ={v} {CLOBBER};    VIEW_CONVERT_EXPR(D.10779) = .MASK_LOAD_LANES (addr_5(D), 64B, _2);    _7 = D.10779.__val[0]; However, the tracking of m_clobbers only looked

Re: [PATCH] c++: DEPENDENT_OPERATOR_TYPE as type of NTTP [PR104074]

On 1/18/22 11:08, Patrick Palka wrote: We're incorrectly rejecting the below testcase during template argument coercion because invalid_nontype_parm_type_p returns true for DEPENDENT_OPERATOR_TYPE. This patch fixes this by partially rewriting invalid_nontype_parm_type_p in terms of

[pushed] c++: new (nothrow) array cleanup [PR104007]

For this testcase, the cleanup that is supposed to happen if initialization throws was wrongly being run on the normal control path as well. This turns out to be because the EH-only handling in gimple_push_cleanup didn't apply to conditional cleanups such as we have for nothrow new, since we

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

On 1/18/22 11:40, Jakub Jelinek wrote: On Tue, Jan 18, 2022 at 11:25:38AM -0500, Jason Merrill wrote: Can you please comment on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86369#c1 then? Done. Thanks. About the rest of the patch, I thought I had seen richi comment on IRC (but can't find

Re: [PATCH] c++: Fix handling of temporaries with consteval ctors and non-trivial dtors [PR104055]

On 1/18/22 09:26, Jakub Jelinek wrote: On Tue, Jan 18, 2022 at 09:08:03AM -0500, Jason Merrill wrote: which makes call a TARGET_EXPR with the dtor in TARGET_EXPR_CLEANUP, but then call cxx_constant_value on it. In cxx_eval_outermost_constant_expr it triggers the: else if (TREE_CODE (t)

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

On 1/18/22 05:17, Jakub Jelinek wrote: On Thu, Jan 13, 2022 at 04:18:33PM -0500, Jason Merrill wrote: Note, address_compare has some special cases, e.g. it assumes that static vars are never adjacent to automatic vars, which is the case for the usual layout where automatic vars are on the stack

Re: [PATCH] c++: Fix handling of temporaries with consteval ctors and non-trivial dtors [PR104055]

On 1/18/22 05:10, Jakub Jelinek wrote: Hi! The following testcase is miscompiled. We see the constructor is immediate, in build_over_call we trigger: if (obj_arg && is_dummy_object (obj_arg)) { call = build_cplus_new (DECL_CONTEXT (fndecl), call,

Re: [PATCH] c++: error message for dependent template members [PR70417]

On Sat, Jan 15, 2022 at 3:28 AM Anthony Sharp wrote: > Hi Jason, > > Hope you are well. Apologies, I've not had time to sit down and look at > this since last month I quit my old job, then I had family around for the > whole of the Christmas period, and then even more recently I've had to >

Re: [PATCH] c++: ICE with noexcept and canonical types [PR101715]

On 1/14/22 19:22, Marek Polacek wrote: This is a "canonical types differ for identical types" ICE, which started with r11-4682. It's a bit tricky to explain. Consider: template struct S { S bar() noexcept(T::value); // #1 S foo() noexcept(T::value); // #2 }; template S

Re: [PATCH] c++: Fix cp_genericize_target_expr for TARGET_EXPRs created for global initialization [PR104031]

On 1/17/22 03:56, Jakub Jelinek wrote: Hi! The following patch is miscompiled, cp_genericize_target_expr expects that for the constant part split_nonconstant_init will emit an INIT_EXPR that will initialize it, but that doesn't happen and instead we get DECL_INITIAL on the TARGET_EXPR_SLOT that

Re: [PATCH v2 RFA] diagnostic: avoid repeating include path

On 1/13/22 17:30, David Malcolm wrote: On Thu, 2022-01-13 at 17:08 -0500, Jason Merrill wrote: When a sequence of diagnostic messages bounces back and forth repeatedly between two includes, as with  #include  std::map m ("123", "456"); The output is quite a bit longer than necessary

Re: [PATCH v3 RFC] c++: add color to function decl printing

On 1/14/22 16:49, David Malcolm wrote: On Mon, 2021-12-13 at 09:58 -0500, Jason Merrill via Gcc-patches wrote: On 12/13/21 06:02, Jonathan Wakely wrote: On Sun, 12 Dec 2021 at 05:39, Jason Merrill mailto:ja...@redhat.com>> wrote:  >  > In reading C++ diagnostics, it's often

Re: [PATCH] c++: Avoid some -Wreturn-type false positives with const{expr,eval} if [PR103991]

On 1/13/22 16:23, Jakub Jelinek wrote: On Thu, Jan 13, 2022 at 04:09:22PM -0500, Jason Merrill wrote: The changes done to genericize_if_stmt in order to improve -Wunreachable-code* warning (which Richi didn't actually commit for GCC 12) are I think fine for normal ifs, but for constexpr if and

[PATCH RFA] diagnostic: avoid repeating include path

When a sequence of diagnostic messages bounces back and forth repeatedly between two includes, as with #include std::map m ("123", "456"); The output is quite a bit longer than necessary because we dump the include path each time it changes. I'd think we could print the include path once for

Re: [PATCH] c++: Reject in constant evaluation address comparisons of start of one var and end of another [PR89074]

On 1/6/22 04:24, Jakub Jelinek wrote: The following testcase used to be incorrectly accepted. The match.pd optimization that uses address_compare punts on folding comparison of start of one object and end of another one only when those addresses are cast to integral types, when the comparison

Re: [PATCH] c++: Avoid some -Wreturn-type false positives with const{expr,eval} if [PR103991]

On 1/13/22 04:39, Jakub Jelinek wrote: Hi! The changes done to genericize_if_stmt in order to improve -Wunreachable-code* warning (which Richi didn't actually commit for GCC 12) are I think fine for normal ifs, but for constexpr if and consteval if we have two competing warnings. The problem is

Re: [PATCH] c++: error message for dependent template members [PR70417]

On 12/9/21 10:51, Jason Merrill wrote: On 12/4/21 12:23, Anthony Sharp wrote: Hi Jason, Hope you are well. Apologies for not coming back sooner.  >I'd put it just above the definition of saved_token_sentinel in parser.c. Sounds good, done.  >Maybe

Re: PING^2 (C/C++): Re: [PATCH 6/6] Add __attribute__ ((tainted))

On 1/12/22 10:33, David Malcolm wrote: On Tue, 2022-01-11 at 23:36 -0500, Jason Merrill wrote: On 1/10/22 16:36, David Malcolm via Gcc-patches wrote: On Thu, 2022-01-06 at 09:08 -0500, David Malcolm wrote: On Sat, 2021-11-13 at 15:37 -0500, David Malcolm wrote: This patch adds a new

Re: PING^2 (C/C++): Re: [PATCH 6/6] Add __attribute__ ((tainted))

On 1/10/22 16:36, David Malcolm via Gcc-patches wrote: On Thu, 2022-01-06 at 09:08 -0500, David Malcolm wrote: On Sat, 2021-11-13 at 15:37 -0500, David Malcolm wrote: This patch adds a new __attribute__ ((tainted)) to the C/C++ frontends. Ping for GCC C/C++ mantainers for review of the C/C++

Re: [PATCH v2 1/2] add -Wuse-after-free

On 11/30/21 17:32, Martin Sebor via Gcc-patches wrote: Attached is a revised patch with the following changes based on your comments: 1) Set and use statement uids to determine which statement    precedes which in the same basic block. 2) Avoid testing flag_isolate_erroneous_paths_dereference.

Re: [PATCH] Use enclosing object size if it's smaller than member [PR 101475]

On 12/16/21 14:56, Martin Sebor via Gcc-patches wrote: Enabling vectorization at -O2 caused quite a few tests for warnings to start failing in GCC 12.  These tests were xfailed and bugs were opened to track the problems until they can be fully analyzed and ultimately fixed before GCC 12 is

Re: [PATCH] c++: dependent bases and 'this' availability [PR103831]

On 12/28/21 10:08, Patrick Palka wrote: Here during satisfaction of B's associated constraints we're failing to reject the object-less call to the non-static member function A::size ultimately because satisfaction is performed in the (access) context of the class template B, which has a

Re: [PATCH] c++: Fix ICEs with OBJ_TYPE_REF pretty printing [PR101597]

On 12/31/21 04:13, Jakub Jelinek wrote: Hi! The following testcase ICEs, because middle-end uses the C++ FE pretty printing code through langhooks in the diagnostics. The FE expects OBJ_TYPE_REF_OBJECT's type to be useful (pointer to the class type it is called on), but in the middle-end

Re: [PATCH] c++: Silence -Wuseless-cast warnings during move [PR103480]

On 12/31/21 04:30, Jakub Jelinek wrote: Hi! This is maybe just a shot in the dark, but IMHO we shouldn't be diagnosing -Wuseless-cast on casts the compiler adds on its own when calling its move function. We don't seem to warn when user calls std::move either. We call move on elinit

Re: [PATCH] c-family: Fix up -W*conversion on bitwise &/|/^ [PR101537]

On 1/4/22 04:32, Jakub Jelinek wrote: Hi! The following testcases emit a bogus -Wconversion warning. This is because conversion_warning function doesn't handle BIT_*_EXPR (only unsafe_conversion_p that is called during the default: case, and that one doesn't handle SAVE_EXPRs added because the

Re: [PATCH] c++: constexpr base-to-derived conversion with offset 0 [PR103879]

On 1/4/22 11:54, Patrick Palka wrote: r12-136 made us canonicalize an object/offset pair with negative offset into one with a nonnegative offset, by iteratively absorbing the innermost component into the offset and stopping as soon as the offset becomes nonnegative. This patch strengthens this

Re: [PATCH] c++: "more constrained" vs staticness of memfn [PR103783]

On 1/4/22 13:01, Patrick Palka wrote: Here we're rejecting the calls to g1 and g2 as ambiguous even though one overload is more constrained than the other (and otherwise equivalent), because the implicit 'this' parameter of the non-static overload causes cand_parms_match to think the function

Re: [PATCH] Improve sequence logic in cxx_init_decl_processing

On 1/6/22 03:26, Olivier Hainque wrote: Hello, commit aa2c978400f3b3ca6e9f2d18598a379589e77ba0, introduced per https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545552.html makes references to __cxa_pure_virtual weak and this is causing issues on some VxWorks configurations, where weak

Re: [PATCH] c++: Ensure some more that immediate functions aren't gimplified [PR103912]

On 1/6/22 03:48, Jakub Jelinek wrote: Hi! Immediate functions should never be emitted into assembly, the FE doesn't genericize them and does various things to ensure they aren't gimplified. But the following testcase ICEs anyway due to that, because the consteval function returns a lambda, and

[pushed] c++: default mem-init of array [PR103946]

In the patch for PR92385 I added asserts to see if we tried to make a vec_init of a vec_init, but didn't see any in regression testing. This testcase is one case, which seems reasonable: we create a VEC_INIT_EXPR for the aggregate initializer, and then again to express the actual initialization

Re: [PATCH] c++, match.pd: Evaluate in constant evaluation comparisons like + 12 == + 24 [PR89074]

On 1/7/22 07:06, Jakub Jelinek wrote: Hi! The match.pd address_comparison simplification can only handle ADDR_EXPR comparisons possibly converted to some other type (I wonder if we shouldn't restrict it in address_compare to casts to pointer types or pointer-sized integer types, I think we

[pushed] c++: destroying delete, throw in new-expr [PR100588]

The standard says that a destroying operator delete is preferred, but that only applies to the delete-expression, not the cleanup if a new-expression initialization throws. As a result of this patch, several of the destroying delete tests don't get EH cleanups, but I'm turning off the warning in

[pushed] c++: check delete access with trivial init [PR20040]

Apparently we need to check the accessibility of the deallocation function even if there is no initialization. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/20040 gcc/cp/ChangeLog: * init.c (build_new_1): Also build pointer cleanup if TYPE_GETS_DELETE. *

[pushed] c++: temporarily restore VEC_INIT_EXPR gimplify [PR103936]

PR103936 demonstrates that some VEC_INIT_EXPR can still survive into GENERIC; until that's fixed let's put back the handling in cp_gimplify_expr. PR c++/103936 PR c++/65591 gcc/cp/ChangeLog: * cp-gimplify.c (cp_gimplify_expr): Restore VEC_INIT_EXPR handling.

[pushed 11/11] c++: when delegating constructor throws [PR103711]

We were always calling the complete destructor if the target constructor throws, even if we were calling the base constructor. PR c++/103711 gcc/cp/ChangeLog: * init.c (perform_target_ctor): Select destructor by in_chrg. gcc/testsuite/ChangeLog: *

[pushed 08/11] c++: clean up ref-extended temp on throwing dtor [PR53868]

We have wrap_temporary_cleanups to handle the EH region nesting problems between cleanups for complete variables and cleanups for temporaries used in their construction, but we weren't calling it for temporaries extended from binding to a reference. We still don't want this for array cleanups

[pushed 10/11] c++: nested catch in ctor fn-try-block [PR61611]

Being in_function_try_handler isn't enough to satisfy the condition of reaching the end of such a handler; in this case, we're reaching the end of a handler within that handler, so we don't want the special semantics. PR c++/61611 gcc/cp/ChangeLog: * except.c (in_nested_catch):

[pushed 09/11] c++: destroy retval on throwing cleanup in try [PR33799]

My earlier attempt to fix this bug didn't handle the case where both the return and the throwing cleanup are within a try-block that catches and discards the exception. Fixed by adding the retval cleanup to any try-blocks as well as the function body. PR102191 pointed out that we also weren't

[pushed 07/11] c++: keep destroying array after one dtor throws [PR66451]

When we're cleaning up an array, if one destructor throws, we should still try to clean up the rest of the array. We can use TRY_CATCH_EXPR for this, instead of a TARGET_EXPR like my other recent patches, because a destructor call can't involve any temporaries that need to live longer. I thought

[pushed 05/11] c++: EH and partially constructed aggr temp [PR66139]

Now that PR94041 is fixed, I can return to addressing PR66139, missing cleanups for partially constructed aggregate temporaries. My previous approach of calling split_nonconstant_init in cp_gimplify_init_expr broke because gimplification is too late to be introducing destructor calls. So instead

[pushed 06/11] c++: don't cleanup the last aggregate elt

Now that we're building cleanups for aggregate elements more often, it seems worth optimizing by avoiding building one for the last element; once it is initialized, the complete object is fully initialized, the element cleanups end in favor of the complete object cleanup, and so a cleanup for the

[pushed 04/11] c++: temporary lifetime with array aggr init [PR94041]

The previous patch fixed temporary lifetime for aggregate initialization of classes; this one extends that fix to arrays. This specifically reverses my r74790, the patch for PR12253, which was made wrong when these semantics were specified in DR201. Since the array cleanup region encloses the

[pushed 03/11] c++: temporary lifetime with aggregate init [PR94041]

In C++98 the lifetime of temporaries in aggregate initialization was unclear, but C++11 DR201 clarified that only temporaries created for default-initialization of an array element with no corresponding initializer-clause are destroyed immediately; all others persist until the end of the

[pushed 02/11] c++: loop over array elts w/o explicit init [PR92385]

The PR complains that initializing a large array with {} takes a long time to compile; this was because digest_init would turn {} into a long CONSTRUCTOR with an initializer for each element, instead of more sensibly generating a loop. The standard doesn't specify this implementation, but it does

[pushed 01/11] c++: don't preevaluate new-initializer

Here begins a series of EH cleanup bugfixes. The preevaluation code was causing trouble with my fix for PR94041, and now I see that it's actually wrong since P0145 was adopted for C++17, mandating order of evaluation for many expressions that were previously unspecified. I don't see a need to

[PATCH RFA] tree-pretty-print: still indent unhandled codes

It would be nice to handle language-specific codes in the tree pretty-printer, but until then we can at least indent them appropriately. Tested x86_64-pc-linux-gnu, ok for trunk? gcc/ChangeLog: * tree-pretty-print.c (do_niy): Add spc parameter. (NIY): Pass it.

[pushed] c++: fix array cleanup with throwing temp dtor

While working on PR66139 I noticed that if the destructor of a temporary created during array initialization throws, we were failing to destroy the last array element constructed. Throwing destructors are rare since C++11, but this should be fixed. Tested x86_64-pc-linux-gnu, applying to trunk.

[pushed] c++: don't wrap cleanups that can't throw

Since C++11, the vast majority of destructors are noexcept, so wrap_temporary_cleanups adds a bunch of useless TRY_CATCH_EXPR to be removed later in the optimizers. It's simple to avoid adding them in the first place. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/cp/ChangeLog: *

[pushed] c++: ICE on enum with bool value [PR99968]

BOOLEAN_TYPE also counts as integral, so verify_type should allow it. Tested x86_64-pc-linux-gnu, applying to trunk as obvious. PR c++/99968 gcc/ChangeLog: * tree.c (verify_type): Allow enumerator with BOOLEAN_TYPE. gcc/testsuite/ChangeLog: * g++.dg/ext/is_enum2.C:

Re: [PATCH] c++: hard error w/ ptr+CST and incomplete type [PR103700]

On 12/22/21 12:39, Patrick Palka wrote: In pointer_int_sum when called from a SFINAE context, we need to avoid calling size_in_bytes_loc on an incomplete pointed-to type since this latter function isn't SFINAE-friendly and always emits an error in this case. Bootstrapped and regtested on

Re: [PATCH] c++: CTAD within alias template [PR91911]

On 12/21/21 14:08, Patrick Palka wrote: On Tue, Dec 21, 2021 at 2:03 PM Patrick Palka wrote: On Wed, Jun 30, 2021 at 4:23 PM Jason Merrill wrote: On 6/30/21 4:18 PM, Patrick Palka wrote: On Wed, Jun 30, 2021 at 3:51 PM Jason Merrill wrote: On 6/30/21 11:58 AM, Patrick Palka wrote: On

Re: [PATCH] c-family: Have -Wformat-diag accept "decl-specifier" [PR103758]

On 12/17/21 17:59, Marek Polacek wrote: I'm tired of seeing cp/parser.c:15923:55: warning: misspelled term 'decl' in format; use 'declaration' instead [-Wformat-diag] cp/parser.c:15925:57: warning: misspelled term 'decl' in format; use 'declaration' instead [-Wformat-diag] every time I

Re: [PATCH] c++: Avoid narrowing in make_char_string_pack

On 12/17/21 17:58, Marek Polacek wrote: This fixes gcc/cp/parser.c:4618:41: warning: narrowing conversion of '(char)(*(str + ((sizetype)i)))' from 'char' to 'unsigned char' [-Wnarrowing] 4618 | unsigned char s[3] = { '\'', str[i], '\'' }; |

Re: [PATCH] c++: memfn lookup consistency in incomplete class context

On 12/20/21 12:46, Patrick Palka wrote: When instantiating a call to a member function of a class template, we repeat the member function lookup in order to obtain the corresponding partially instantiated functions. Within an incomplete-class context however, we need to be more careful when

Re: [PATCH] c++: don't ICE on NAMESPACE_DECL inside FUNCTION_DECL

On 12/15/21 03:53, Matthias Kretz wrote: OK for trunk? This fixes several modules.exp failures for me. OK. ── ✂ ── Code like void swap() { namespace __variant = __detail::__variant; ... } create a NAMESPACE_DECL where the

Re: [PATCH v3] attribs: Fix wrong error with -Wno-attribute=A::b [PR103649]

On 12/17/21 13:14, Marek Polacek wrote: On Thu, Dec 16, 2021 at 08:06:43PM -0500, Jason Merrill wrote: On 12/16/21 19:52, Marek Polacek wrote: --- /dev/null +++ b/gcc/testsuite/c-c++-common/Wno-attributes-6.c @@ -0,0 +1,14 @@ +/* PR c/103649 */ +/* { dg-do compile { target { c || c++11 } } }

[pushed] c++: layout of aggregate base with DMI [PR103681]

C++14 changed the definition of 'aggregate' to allow default member initializers, but such classes still need to be considered "non-POD for the purpose of layout" for ABI compatibility with C++11 code. It seems rare to derive from such a class, as evidenced by how long this bug has survived

Re: [PATCH] c++: Improve diagnostic for class tmpl/class redecl [PR103749]

On 12/16/21 17:36, Marek Polacek wrote: For code like template struct bar; struct bar { int baz; }; bar var; we emit a fairly misleading and unwieldy diagnostic: ~ $ g++ -c u.cc u.cc:6:8: error: template argument

Re: [PATCH] c++: delayed noexcept in member function template [PR99980]

On 12/16/21 11:00, Marek Polacek wrote: Some time ago I noticed that we don't properly delay parsing of noexcept for member function templates. This patch fixes that. It didn't work because even though we set CP_PARSER_FLAGS_DELAY_NOEXCEPT in cp_parser_member_declaration, member template

Re: [PATCH] c++: nested lambda capturing a capture proxy, part 2 [PR94376]

On 12/16/21 11:28, Patrick Palka wrote: On Wed, 15 Dec 2021, Jason Merrill wrote: On 12/15/21 15:36, Patrick Palka wrote: The r12-5403 fix apparently doesn't handle the case where the inner lambda explicitly rather implicitly captures the capture proxy from the outer lambda, and so we still

Re: [PATCH] c++: ahead-of-time overload set pruning for non-dep calls

On 12/16/21 14:53, Patrick Palka wrote: On Thu, 16 Dec 2021, Patrick Palka wrote: On Wed, 15 Dec 2021, Jason Merrill wrote: On 12/15/21 12:49, Patrick Palka wrote: This patch makes us remember the function selected by overload resolution during ahead of time processing of a non-dependent

Re: [PATCH] gengtype: remove "tree_exp" special attribute

On 12/10/21 10:41, Patrick Palka wrote: The function comment for adjust_field_tree_exp says this special case is for handling trees whose operands may contain pointers to RTL instead of to trees. But ever since r0-59671, which fixed/removed the last two tree codes for which this was possible

Re: [PATCH] c++: local_specializations and recursive constrained fn [PR103714]

On 12/14/21 17:26, Patrick Palka wrote: Here during constraint checking for the recursive call to 'f', substitution into the PARM_DECL 'd' in the atomic constraint gives us the wrong local specialization because local_specializations at this point contains entities associated with the _outer_

Re: [PATCH] Check for class type before assuming a type is one [PR103703]

On 12/14/21 17:28, Martin Sebor wrote: The attached patch avoids an ICE when using the CLASSTYPE_IMPLICIT_INSTANTIATION() macro with an argument that is not a class type but rather a typename_type. The test case should trigger a warning but doesn't because the code doesn't fully handle explicit

Re: [PATCH] c++: processing_template_decl vs template depth [PR103408]

On 12/15/21 09:09, Jakub Jelinek wrote: On Wed, Dec 15, 2021 at 08:58:45AM -0500, Patrick Palka wrote: Oops, thanks Jakub, I didn't realize we don't run the testsuite with -std=c++23 yet. I guess it'd be too expensive to add another std to the testing matrix at this point, but I wonder if the

Re: [PATCH] c++: Allow constexpr decltype(auto) [PR102229]

On 12/15/21 16:28, Marek Polacek wrote: On Wed, Dec 15, 2021 at 04:17:37PM -0500, Jason Merrill wrote: On 12/15/21 15:20, Marek Polacek wrote: On Mon, Dec 13, 2021 at 10:02:24AM -0500, Jason Merrill wrote: On 12/10/21 17:29, Marek Polacek wrote: My r11-2202 was trying to enforce

Re: [PATCH] c++: ahead-of-time overload set pruning for non-dep calls

On 12/15/21 12:49, Patrick Palka wrote: This patch makes us remember the function selected by overload resolution during ahead of time processing of a non-dependent call expression, so that we avoid repeating most of the work of overload resolution at instantiation time. This mirrors what we

Re: [PATCH] print-tree: dump DECL_LANG_FLAG_8

On 12/15/21 15:11, Patrick Palka wrote: Tested on x86_64-pc-linux-gnu, does this look OK for trunk? OK. gcc/ChangeLog: * print-tree.c (print_node) : Dump DECL_LANG_FLAG_8. --- gcc/print-tree.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/gcc/print-tree.c

Re: [PATCH] c++: Allow constexpr decltype(auto) [PR102229]

On 12/15/21 15:20, Marek Polacek wrote: On Mon, Dec 13, 2021 at 10:02:24AM -0500, Jason Merrill wrote: On 12/10/21 17:29, Marek Polacek wrote: My r11-2202 was trying to enforce [dcl.type.auto.deduct]/4, which says "If the placeholder-type-specifier is of the form type-constraint[opt]

Re: [PATCH] c++: nested lambda capturing a capture proxy, part 2 [PR94376]

On 12/15/21 15:36, Patrick Palka wrote: The r12-5403 fix apparently doesn't handle the case where the inner lambda explicitly rather implicitly captures the capture proxy from the outer lambda, and so we still reject the first example in the testcase below. The reason is that compared to an

Re: [PATCH] c++: two-stage name lookup for overloaded operators [PR51577]

On 12/10/21 09:53, Patrick Palka wrote: In order to properly implement two-stage name lookup for dependent operator expressions, we need to remember the result of unqualified lookup of the operator at template definition time, and reuse that result rather than performing another unqualified

Re: [PATCH] c++: processing_template_decl vs template depth [PR103408]

On 12/13/21 16:28, Patrick Palka wrote: On Sun, 12 Dec 2021, Jason Merrill wrote: On 12/10/21 14:12, Patrick Palka wrote: We use processing_template_decl in two slightly different ways: as a flag to signal that we're dealing with templated trees, and its magnitude is also used as a proxy for

Re: [PATCH] c++: remove COMPOUND_EXPR_OVERLOADED flag

On 12/10/21 10:48, Patrick Palka wrote: This flag is never set because non-dependent COMPOUND_EXPRs are fully resolved into a CALL_EXPR at template definition time (in build_x_compound_expr) ever since r6-5772. Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk?

Re: [PATCH] c++: don't leak 'arglist' in build_new_op

On 12/10/21 11:21, Patrick Palka wrote: 'arglist' can be captured by a conversion within 'candidates', but if we use a releasing_vec then we'll be sure to free it only after 'candidates' is freed by obstack_free. Bootstrapped and regtested in x86_64-pc-linux-gnu, does this look OK for trunk?

Re: [PATCH] c++: Allow constexpr decltype(auto) [PR102229]

On 12/10/21 17:29, Marek Polacek wrote: My r11-2202 was trying to enforce [dcl.type.auto.deduct]/4, which says "If the placeholder-type-specifier is of the form type-constraint[opt] decltype(auto), T shall be the placeholder alone." But this made us reject 'constexpr decltype(auto)', which,

[PATCH v2 RFC] c++: add color to function decl printing

On 12/13/21 06:02, Jonathan Wakely wrote: On Sun, 12 Dec 2021 at 05:39, Jason Merrill > wrote: > > In reading C++ diagnostics, it's often hard to find the name of the function > in the middle of the template header, return type, parameters, and template >

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