[wwdocs PATCH RFA] contribute: link to kernel doc about patch email

It occurred to me that it would be useful to link to the kernel's documentation for emailing patches. OK? --- htdocs/contribute.html | 5 + 1 file changed, 5 insertions(+) diff --git a/htdocs/contribute.html b/htdocs/contribute.html index c985b87d..60bcf3f8 100644 --- a/htdocs/contribute.ht

Re: [PATCH] libcpp, v3: Named universal character escapes and delimited escape sequence tweaks

On 9/3/22 06:54, Jakub Jelinek wrote: On Sat, Sep 03, 2022 at 12:29:52PM +0200, Jakub Jelinek wrote: On Thu, Sep 01, 2022 at 03:00:28PM -0400, Jason Merrill wrote: We might as well use the same flag name, and document it to mean what it currently means for GCC. Ok, following patch introduces

[PATCH RFA] libstdc++: small dynamic_cast optimization

An email discussion of optimizing EH led me to wonder why we weren't doing this already. Not that this change affects EH at all. Tested x86_64-pc-linux-gnu. Does this seem worthwhile? libstdc++-v3/ChangeLog: * libsupc++/dyncast.cc (__dynamic_cast): Avoid virtual function call i

Re: [PATCH] c++: Implement C++23 P2266R1, Simpler implicit move [PR101165]

On 9/3/22 12:42, Marek Polacek wrote: This patch implements https://wg21.link/p2266, which, once again, changes the implicit move rules. Here's a brief summary of various changes in this area: r125211: Introduced moving from certain lvalues when returning them r171071: CWG 1148, enable move fro

Re: [PATCH] c++: Fix type completeness checks for type traits [PR106838]

On 9/7/22 08:18, Jonathan Wakely wrote: Tested powerpc64le-linux. OK for trunk? -- >8 -- The check_trait_type function is used for a number of different type traits that have different requirements on their arguments. For example, __is_constructible allows arrays of unknown bound even if the ar

Re: [PATCH v2] coroutines: Ensure there's a top level bind when rewriting [PR106188]

On 9/4/22 15:04, Arsen Arsenović wrote: In the edge case of a coroutine not containing any locals, the ifcd/swch temporaries would get added to the coroutine frame, corrupting its layout. To prevent this, we can make sure there is always a BIND_EXPR at the top of the function body, and thus, alwa

[pushed] c++: diagnostic for template placeholder in parm [PR106793]

Talking about the declarator form doesn't help when fixing that would get you a different error about placeholders not being valid in a parameter. This also adds a <> fixit, which isn't enough for most templates, but is a start. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/10679

Re: [PATCH] c++: unnecessary instantiation of constexpr var [PR99130]

On 9/7/22 15:41, Patrick Palka wrote: Here the use of the constexpr member/variable specialization 'value' from within an unevaluated context causes us to overeagerly instantiate it, via maybe_instantiate_decl called from mark_used, despite only its declaration not its definition being needed.

Re: [PATCH] c++: unnecessary instantiation of constexpr var [PR99130]

On 9/7/22 16:40, Patrick Palka wrote: On Wed, 7 Sep 2022, Jason Merrill wrote: On 9/7/22 15:41, Patrick Palka wrote: Here the use of the constexpr member/variable specialization 'value' from within an unevaluated context causes us to overeagerly instantiate it, via maybe_instantiate_decl calle

Re: [PATCH v2] c++: Fix type completeness checks for type traits [PR106838]

On 9/8/22 08:56, Jonathan Wakely wrote: On Wed, 7 Sept 2022 at 16:11, Jason Merrill wrote: On 9/7/22 08:18, Jonathan Wakely wrote: @@ -12080,23 +12098,37 @@ finish_trait_expr (location_t loc, cp_trait_kind kind, tree type1, tree type2) case CPTK_HAS_TRIVIAL_COPY: case CPTK_HAS_T

Re: [PATCH] optc-save-gen.awk: adjust generated array compare

On 9/8/22 11:29, Chung-Lin Tang wrote: Hi Joseph, Jan-Benedict reported a build-bot error for the nios2 port under --enable-werror-always: options-save.cc: In function 'bool cl_target_option_eq(const cl_target_option*, const cl_target_option*)': options-save.cc:9291:38: error: comparison betwe

Re: [EXTERNAL] Re: [PING][PATCH] Add instruction level discriminator support.

On 9/1/22 18:22, Eugene Rozenfeld wrote: Jason, I made another small change in addressing your feedback (attached). Thanks, Eugene -Original Message- From: Gcc-patches On Behalf Of Eugene Rozenfeld via Gcc-patches Sent: Thursday, September 01, 2022 1:49 PM To: Jason Merrill ; gcc-pa

Re: [PATCH] optc-save-gen.awk: adjust generated array compare

On 9/8/22 14:01, Martin Liška wrote: On 9/8/22 18:23, Jason Merrill wrote: It seems to me that the warning is pointing out that comparing the address of the array is nonsensical, and we should remove it and just have the memcmp. Yes, thanks for the pointer. We should always compare the array

Re: [PATCH v3] eliminate mutex in fast path of __register_frame

On 6/26/22 05:13, Thomas Neumann via Gcc-patches wrote: NOTE: A stress test program and a detailed walkthrough that breaks this patch into manageable parts can be found here: https://databasearchitects.blogspot.com/2022/06/making-unwinding-through-jit-ed-code.html The __register_frame/__deregist

Re: [PATCH] c++: Refer to internal linkage for -Wsubobject-linkage [PR86491]

Oops, failed to CC the list. Forwarded Message Subject: Re: [PATCH] c++: Refer to internal linkage for -Wsubobject-linkage [PR86491] Date: Mon, 12 Sep 2022 12:09:38 -0400 From: Jason Merrill To: Jonathan Wakely On 7/23/22 07:31, Jonathan Wakely wrote: I'll try that on Mon

[PATCH] c++: lambda capture of array with deduced bounds [PR106567]

We can't use the type of an array variable directly if we haven't deduced its length yet. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/106567 gcc/cp/ChangeLog: * lambda.cc (type_deducible_expression_p): Check array_of_unknown_bound_p. gcc/testsuite/ChangeLog:

[pushed] c++: cast to array of unknown bound [PR93259]

We already know to treat a variable of array-of-unknown-bound type as dependent, we should do the same for arr{}. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/93259 gcc/cp/ChangeLog: * pt.cc (type_dependent_expression_p): Treat a compound literal of array-of-unk

[pushed] c++: auto member function and auto variable [PR106893]

As with PR105623, we need to call mark_single_function sooner to resolve the type of a BASELINK. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/106893 PR c++/90451 gcc/cp/ChangeLog: * decl.cc (cp_finish_decl): Call mark_single_function. gcc/testsuite/ChangeLog:

Re: [PATCH] c++: remove '_sfinae' suffix from functions

On 9/9/22 08:52, Patrick Palka wrote: Each of the following functions instantiate_non_dependent_expr get_target_expr require_complete_type abstract_virtuals_error cxx_constant_value is (presumably for historical reasons) just a non-SFINAE-enabled wrapper for the corresponding SFI

Re: [PATCH] c++: Implement C++23 P2266R1, Simpler implicit move [PR101165]

On 9/8/22 18:54, Marek Polacek wrote: On Tue, Sep 06, 2022 at 10:38:12PM -0400, Jason Merrill wrote: On 9/3/22 12:42, Marek Polacek wrote: This patch implements https://wg21.link/p2266, which, once again, changes the implicit move rules. Here's a brief summary of various changes in this area:

Re: [PATCH] c++: partial ordering with dependent NTTP type [PR105289]

On 4/22/22 15:27, Patrick Palka wrote: On Fri, 22 Apr 2022, Patrick Palka wrote: Here ever since r11-6483-ge2e2f3f2c9400f we're rejecting and crashing (respectively) on two testcases that we used to accept in C++17 mode. Both testcases declare partial specializations for which the primary templ

Re: [PATCH] c++: __builtin_shufflevector with value-dep expr [PR105353]

On 4/22/22 19:57, Marek Polacek wrote: Here we issue an error from c_build_shufflevector while parsing a template because it got a TEMPLATE_PARM_INDEX, but this function expects INTEGER_CSTs (except the first two arguments). It checks if any of the arguments are type-dependent, if so, we leave t

Re: [PATCH] c++: crash with requires-expr and -Wsequence-point [PR105304]

On 4/22/22 14:36, Patrick Palka wrote: Here we're crashing from verify_sequence_points for this requires-expr condition because it contains a templated CAST_EXPR with empty operand, and verify_tree doesn't ignore this empty operand only because the manual tail recursion that it perform for unary

Re: [PATCH] c++: partial ordering with dependent NTTP type [PR105289]

On 4/25/22 14:10, Patrick Palka wrote: On Mon, 25 Apr 2022, Jason Merrill wrote: On 4/22/22 15:27, Patrick Palka wrote: On Fri, 22 Apr 2022, Patrick Palka wrote: Here ever since r11-6483-ge2e2f3f2c9400f we're rejecting and crashing (respectively) on two testcases that we used to accept in C+

[pushed] c++: generic lambda fn parm pack [PR104624]

Parameter packs from the enclosing context can be used unexpanded in a lambda that is itself part of a pack expansion, but not packs that are part of the lambda itself. We already check for capture packs; we also need to check for function parameter packs of the lambda call operator. Tested x86_6

Re: [PATCH] c++: decltype of non-dependent call of class type [PR105386]

On 4/26/22 09:45, Patrick Palka wrote: We need to pass tf_decltype when instantiating a non-dependent decltype operand, like tsubst does in the dependent case, so that we avoid materializing a temporary for a prvalue operand. Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK f

[pushed] c++: pack init-capture of unresolved overload [PR102629]

Here we were failing to diagnose that the initializer for the capture pack is an unresolved overload. It turns out that the reason we didn't recognize the deduction failure in do_auto_deduction was that the individual 'auto' in the expansion of the capture pack was still marked as a parameter pack

[PATCH RFA] c-family: attribute ((aligned, mode)) [PR100545]

The problem here was that handle_mode_attribute clobbered the changes of any previous attribute, only copying type qualifiers to the new type. And common_handle_aligned_attribute had previously set up the typedef, so when we later called set_underlying_type it saw DECL_ORIGINAL_TYPE set and just r

Re: [PATCH] c++: enum in generic lambda at global scope [PR105398]

On 4/27/22 08:59, Marek Polacek wrote: On Wed, Apr 27, 2022 at 08:24:54AM -0400, Patrick Palka wrote: On Tue, 26 Apr 2022, Marek Polacek via Gcc-patches wrote: We crash compiling this test since r11-7993 which changed lookup_template_class_1 so that we only call tsubst_enum when !uses_temp

Re: [PATCH] c++: enum in generic lambda at global scope [PR105398]

On 4/27/22 13:00, Marek Polacek wrote: On Wed, Apr 27, 2022 at 11:47:02AM -0400, Jason Merrill wrote: On 4/27/22 08:59, Marek Polacek wrote: On Wed, Apr 27, 2022 at 08:24:54AM -0400, Patrick Palka wrote: On Tue, 26 Apr 2022, Marek Polacek via Gcc-patches wrote: We crash compiling this test s

Re: [PATCH RFA] c-family: attribute ((aligned, mode)) [PR100545]

On 4/27/22 13:02, Joseph Myers wrote: On Wed, 27 Apr 2022, Jason Merrill via Gcc-patches wrote: + if (typedef_variant_p (type)) + { + /* Set up the typedef all over again. */ This seems wrong when the typedef is just being used in another declaration with the mode

Re: [PATCH] c++: global-namespace-qualified var after class def [PR90107]

On 4/27/22 18:45, Marek Polacek wrote: Here we wrongly reject the definition of "::N::a" struct A; namespace N { extern A a; } struct A {} ::N::a; because our code to diagnose a missing ; after a class definition doesn't realize that :: can follow a class definition. Bootstrapped/regt

Re: [PATCH] c++, coroutines: Make sure our temporaries are in a bind expr [PR105287]

On 4/28/22 04:28, Iain Sandoe wrote: Hi Jason, On 20 Apr 2022, at 03:14, Jason Merrill wrote: On 4/18/22 10:02, Iain Sandoe wrote: There are a few cases where we can generate a temporary that does not need to be added to the coroutine frame (i.e. these are genuinely ephemeral). The intent w

Re: [PATCH] c++, coroutines: Avoid expanding within templates [PR103868]

On 4/28/22 04:24, Iain Sandoe wrote: Hi Jason, On 20 Apr 2022, at 04:45, Jason Merrill wrote: On 4/18/22 15:49, Eric Gallager via Gcc-patches wrote: On Mon, Apr 18, 2022 at 10:01 AM Iain Sandoe via Gcc-patches wrote: From: Nathan Sidwell This is a forward-port of a patch by Nathan (agai

[pushed] c++: typeid and instantiation [PR102651]

PR49387 was a problem with initially asking for a typeid for a class template specialization before it was complete, and later actually filling in the descriptor when the class was complete, and thus disagreeing on the form of the descriptor. I fixed that by forcing the class to be complete, but t

[pushed] c++: traits, array of unknown bound of incomplete

My r161129 changed check_trait_type to reject arrays of unknown bound of incomplete type, but I can't find a rationale for that, and now think it's wrong: the standard just requires that the type be "complete, cv void, or an array of unknown bound." I imagine that allowing arrays of unknown bound

[pushed] c++: dump alias-declaration scope

An alias can't be declared with a qualified-id in actual code, but in diagnostics we want to know which scope it belongs to, and I think a nested-name-specifier is the best way to provide that. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/cp/ChangeLog: * error.cc (dump_decl): Check

[pushed] c++: using in diagnostics [PR102987]

The decl pretty-printing code wasn't looking at the flags parameter, so we were printing 'using' in the middle of an expression. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/102987 gcc/cp/ChangeLog: * error.cc (dump_decl) [USING_DECL]: Respect flags. gcc/testsuite/Chan

[pushed] c++: check completeness after auto deduction [PR80351]

Normally we check for incomplete type in start_decl, but that obviously doesn't work for auto variables. Thanks to Pokechu22 for the analysis and testcases: "When cp_finish_decl calls cp_apply_type_quals_to_decl on a const auto or constexpr auto variable, the type might not be complete the first t

Re: [PATCH] Use CASE_CONVERT in a few more cases

On 4/29/22 05:37, Richard Biener wrote: This uses CASE_CONVERT more which eases eventual removal of NOP_EXPR. Bootstrapped and tested on x86_64-unknown-linux-gnu, OK for trunk? Jason, from the experiment this is from I know that the C++ FE distinguishes between CONVERT_EXPR and NOP_EXPR at the

Re: [PATCH] c++: pedwarn for empty unnamed enum in decl [PR67048]

On 4/29/22 10:12, Marek Polacek wrote: [dcl.dcl]/5 says that enum { }; is ill-formed, and since r197742 we issue a pedwarn. However, the pedwarn also fires for enum { } x; which is well-formed. So only warn when {} is followed by a ;. This should be correct since you can't have "enu

Re: [PATCH RFA] c-family: attribute ((aligned, mode)) [PR100545]

On 4/27/22 19:48, Jason Merrill wrote: On 4/27/22 13:02, Joseph Myers wrote: On Wed, 27 Apr 2022, Jason Merrill via Gcc-patches wrote: +  if (typedef_variant_p (type)) +    { +  /* Set up the typedef all over again.  */ This seems wrong when the typedef is just being used in another

[pushed] c++: lambda capture dependent type [PR82980]

The stage 4 patch limited direct propagation of dependent type to capture field/proxy to the "current instantiation", but many more types should be suitable as well. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/cp/ChangeLog: * lambda.cc (type_deducible_expression_p): Allow more typ

[pushed] c++: alias CTAD and member alias templates [PR104470]

In this testcase, we were trying to substitute into variant>::__accepted_type, but failed to look it up because variant> doesn't exist. In other cases we already rewrite such things into a dependent reference; we need to do that for alias templates as well. This caused some testsuite regressions

[pushed] c++: reorganize friend template matching [PR91618]

The the different calling of check_explicit_specialization for class and namespace scope friends bothered me, so this patch combines them. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/91618 PR c++/96604 gcc/cp/ChangeLog: * friend.cc (do_friend): Call check_expli

[pushed] c++: also note name used in enclosing class

While looking at PR96645 I noticed that while we were diagnosing names changing meaning in the full class context, we weren't doing this for lookups in nested class bodies. Note that this breaks current range-v3; I've submitted a pull request to fix its violation of the rule. Tested x86_64-pc-lin

[pushed] c++: improve template-id location

On PR102629 I noticed that we were giving the entire lambda as the location for this template-id. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/cp/ChangeLog: * pt.cc (tsubst_copy_and_build) [TEMPLATE_ID_EXPR]: Copy location. (do_auto_deduction): Use expr location. gcc/tests

Re: [PATCH] c++: make finish non_static_data_member SFINAE friendly [PR105351]

On 5/3/22 13:40, Patrick Palka wrote: Here, since finish_non_static_data_member isn't SFINAE friendly, we incorrectly emit an error during overload resolution: sfinae33.C: In substitution of ‘template A f() [with T = B]’: sfinae33.C:11:7: required from here sfinae33.C:5:31: error: invalid use

Re: [PATCH] c++: partial spec constraint checking context [PR105220]

On 5/2/22 14:50, Patrick Palka wrote: Currently when checking the constraints of a class template, we do so in the context of the template, not the specialized type. This is the best we can do for a primary template since the specialized type is valid only if the primary template's constraints a

Re: [PATCH] c++: parse error with >= in template argument list [PR105436]

On 5/2/22 12:19, Marek Polacek wrote: This patch fixes an oversight whereby we treated >= as the end of a template argument. This causes problems in C++14, because in cp_parser_template_argument we go different ways for C++14 and C++17: /* It must be a non-type argument. In C++17 any consta

Re: [PATCH] c++: wrong parse with functors [PR64679]

On 5/2/22 12:18, Marek Polacek wrote: Consider struct F { F(int) {} F operator()(int) const { return *this; } }; and F(i)(0)(0); where we're supposed to first call the constructor and then invoke the operator() twice. However, we parse this as an init-declarator: "(i)" loo

Re: [PATCH] c++: parse error with >= in template argument list [PR105436]

On 5/3/22 16:43, Jakub Jelinek wrote: On Tue, May 03, 2022 at 04:26:51PM -0400, Jason Merrill wrote: On 5/2/22 12:19, Marek Polacek wrote: This patch fixes an oversight whereby we treated >= as the end of a template argument. This causes problems in C++14, because in cp_parser_template_argumen

Re: [PATCH] c++: Don't emit deprecated warnings or unavailable errors on lambda declarations

On 5/2/22 07:11, Jakub Jelinek wrote: Hi! On the following testcase, we emit deprecated warnings or unavailable errors even on merge declarations of those lambdas (the dg-bogus directives), while IMHO we should emit them only when something actually calls those lambdas. The following patch temp

Re: [PATCH v2] c++: ICE with temporary of class type in DMI [PR100252]

On 4/27/22 16:30, Marek Polacek wrote: On Wed, Apr 27, 2022 at 11:00:46AM -0400, Patrick Palka wrote: On Tue, 26 Apr 2022, Marek Polacek wrote: Consider struct A { int x; int y = x; }; struct B { int x = 0; int y = A{x}.y; // #1 }; where for #1 we end up with

[pushed] c++: Remove cdtor_label

Jakub pointed out that cdtor_label is unnecessary, we should get all the desired semantics with a normal return. Tested x86_64-pc-linux-gnu and arm-eabi//arm-sim, applying to trunk. gcc/cp/ChangeLog: * cp-tree.h (struct language_function): Remove x_cdtor_label. (cdtor_label, LABE

Re: [PATCH] c++: parse error with >= in template argument list [PR105436]

On 5/4/22 11:15, Marek Polacek wrote: On Tue, May 03, 2022 at 04:46:11PM -0400, Jason Merrill wrote: On 5/3/22 16:43, Jakub Jelinek wrote: On Tue, May 03, 2022 at 04:26:51PM -0400, Jason Merrill wrote: On 5/2/22 12:19, Marek Polacek wrote: This patch fixes an oversight whereby we treated >= a

[pushed] c++: use %D more

There's no reason to call cxx_printable_name_translate here instead of using %D in the format string. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/cp/ChangeLog: * error.c (cp_print_error_function): Use %qD. (function_category): Use %qD. --- gcc/cp/error.cc | 29 +++

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

On 1/14/22 22:56, Jason Merrill wrote: 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:   >   >

Re: [PATCH] c++: ICE during aggr CTAD for member tmpl [PR105476]

On 5/4/22 10:09, Patrick Palka wrote: Here we're crashing from maybe_aggr_guide ultimately because processing_template_decl isn't set when partially instantiating the guide's parameter list. This causes us to prematurely force completion of the dependent type Visitor_functior, which fails and re

[pushed] c++: optimize reshape_init

If the index of a constructor_elt is a FIELD_DECL, the CONSTRUCTOR is already reshaped, so we can save time and memory by returning immediately. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/cp/ChangeLog: * decl.cc (reshape_init): Shortcut already-reshaped init. (reshape_in

Re: [PATCH] c++: wrong error with MVP and pushdecl [PR64679]

On 5/4/22 16:03, Marek Polacek wrote: This patch fixes the second half of 64679. Here we issue a wrong "redefinition of 'int x'" for the following: struct Bar { Bar(int, int, int); }; int x = 1; Bar bar(int(x), int(x), int{x}); // #1 cp_parser_parameter_declaration_list does

[pushed] c++: alias CTAD refactoring [PR104470]

In my previous PR104470 patch I added yet another place that needs to handle dependent member rewriting for deduction guides; this patches centralizes rewriting into maybe_dependent_member_ref. tsubst_baselink still has its own handling because that's simpler than teaching maybe_dependent_member_r

Re: [PATCH] c++: wrong error with MVP and pushdecl [PR64679]

On 5/4/22 19:20, Marek Polacek wrote: On Wed, May 04, 2022 at 05:44:45PM -0400, Jason Merrill wrote: On 5/4/22 16:03, Marek Polacek wrote: This patch fixes the second half of 64679. Here we issue a wrong "redefinition of 'int x'" for the following: struct Bar { Bar(int, int, int);

[PATCH RFA] attribs: fix typedefs in generic code [PR105492]

In my patch for PR100545 I added an assert to check for broken typedefs in set_underlying_type, and it found one in this case: rs6000_handle_altivec_attribute had the same problem as handle_mode_attribute. So let's move the fixup into decl_attributes. Tested that this fixes the ICE on a cross com

Re: [PATCH v2] c++: wrong error with MVP and pushdecl [PR64679]

On 5/5/22 16:57, Marek Polacek wrote: On Wed, May 04, 2022 at 09:29:46PM -0400, Jason Merrill wrote: On 5/4/22 19:20, Marek Polacek wrote: On Wed, May 04, 2022 at 05:44:45PM -0400, Jason Merrill wrote: On 5/4/22 16:03, Marek Polacek wrote: This patch fixes the second half of 64679. Here we i

Re: [PATCH] c++: constexpr init of union sub-aggr w/ base [PR105491]

On 5/6/22 11:22, Patrick Palka wrote: Here ever since r10-7313-gb599bf9d6d1e18, reduced_constant_expression_p in C++11/14 is rejecting the marked sub-aggregate initializer (of type S) W w = {.D.2445={.s={.D.2387={.m=0}, .b=0}}} ^ ultimately because said initializer has

Re: [PATCH] c++: constexpr init of union sub-aggr w/ base [PR105491]

On 5/6/22 14:00, Patrick Palka wrote: On Fri, 6 May 2022, Patrick Palka wrote: On Fri, 6 May 2022, Jason Merrill wrote: On 5/6/22 11:22, Patrick Palka wrote: Here ever since r10-7313-gb599bf9d6d1e18, reduced_constant_expression_p in C++11/14 is rejecting the marked sub-aggregate initializer

Re: [PATCH] c++: constexpr init of union sub-aggr w/ base [PR105491]

On 5/6/22 16:10, Patrick Palka wrote: On Fri, 6 May 2022, Patrick Palka wrote: On Fri, 6 May 2022, Jason Merrill wrote: On 5/6/22 14:00, Patrick Palka wrote: On Fri, 6 May 2022, Patrick Palka wrote: On Fri, 6 May 2022, Jason Merrill wrote: On 5/6/22 11:22, Patrick Palka wrote: Here ever

[pushed] c++: empty base constexpr adjustment [PR105245]

While looking at PR105245 in stage 4, I wanted to reorganize the code a bit, but it seemed prudent to defer that to stage 1. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/105245 PR c++/100111 gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_store_expression): Reorganiz

Re: [PATCH] c++: constexpr init of union sub-aggr w/ base [PR105491]

On 5/6/22 16:46, Patrick Palka wrote: On Fri, 6 May 2022, Jason Merrill wrote: On 5/6/22 16:10, Patrick Palka wrote: On Fri, 6 May 2022, Patrick Palka wrote: On Fri, 6 May 2022, Jason Merrill wrote: On 5/6/22 14:00, Patrick Palka wrote: On Fri, 6 May 2022, Patrick Palka wrote: On Fri, 6

Re: [PATCH v3] c++: ICE with temporary of class type in DMI [PR100252]

On 5/7/22 15:11, Marek Polacek wrote: On Tue, May 03, 2022 at 04:59:38PM -0400, Jason Merrill wrote: Does this testcase still work with this patch? struct A { const A* p = this; }; struct B { A a = A{}; }; constexpr B b; static_assert (b.a.p == &b.a); Ouch, no. Thanks for catching th

Re: [PATCH] c++: Implement P2324R2, labels at the end of compound-stmts [PR103539]

On 5/8/22 20:26, Marek Polacek wrote: This patch implements C++23 , which allows labels at the end of a compound statement. Its C FE counterpart was already implemented in r11-4813. In cp_parser_statement I rely on in_compound to determine whether we're in a compound

Re: [PATCH] c++: ICE with constexpr dtor on ARM [PR105529]

On 5/9/22 18:41, Marek Polacek wrote: When compiling this test on ARM with -O, we ICE in cxx_eval_store_expression while evaluating a CALL_EXPR allocator::~allocator (&D.4529). Its body has this store: = this The RHS is evaluated into &D.4529 of type allocator *. The object, , is of type

[pushed] c++: fix arm-eabi crash building libstdc++ [PR105529]

My recent change to cxx_eval_store_expression asserts that the target and value can only end up having different types in the case of an empty base; this was crashing arm-eabi compilers because in that ABI [cd]tors return *this, and weren't converting it to void* first. This also shares the 'retur

Re: [PATCH v2] c, c++: -Wswitch warning on [[maybe_unused]] enumerator [PR105497]

On 5/7/22 18:26, Marek Polacek wrote: Corrected version that avoids an uninitialized warning: This PR complains that we emit the "enumeration value not handled in switch" warning even though the enumerator was marked with the [[maybe_unused]] attribute. The first snag was that I couldn't just c

Re: [PATCH 1/2] c++: Harden *_PACK_EXPANSION and *_ARGUMENT_PACK macros

On 5/10/22 09:40, Patrick Palka wrote: The accessor macros for TYPE_PACK_EXPANSION/EXPR_PACK_EXPANSION and TYPE_ARGUMENT_PACK/NONTYPE_ARGUMENT_PACK should check the tree code of the argument. Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? OK. gcc/cp/ChangeLog

Re: [PATCH 2/2] c++: Remove SET_PACK_EXPANSION_PATTERN / SET_ARGUMENT_PACK_ARGS

On 5/10/22 09:40, Patrick Palka wrote: Unlike in C, in C++ the conditional operator yields an lvalue if both branches are lvalues, so we can just assign to PACK_EXPANSION_PATTERN and ARGUMENT_PACK_ARGS directly. Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? OK

PING Re: [PATCH RFA] attribs: fix typedefs in generic code [PR105492]

Ping? On 5/5/22 14:07, Jason Merrill wrote: In my patch for PR100545 I added an assert to check for broken typedefs in set_underlying_type, and it found one in this case: rs6000_handle_altivec_attribute had the same problem as handle_mode_attribute. So let's move the fixup into decl_attributes.

[pushed] c++: fix arm-eabi bootstrap [PR105567]

Since my r13-112, in the template we were changing 'return' to 'return this' on cdtor_returns_this targets, and then getting confused by that when instantiating. So only make that change at instantiation time. Tested x86_64-pc-linux-gnu and arm-eabi sim, applying to trunk. PR bootstrap/1

Re: [PATCH] tree: introduce range adaptor for TREE_VEC

On 5/11/22 15:20, Patrick Palka wrote: This patch implements a simple tree wrapper, named tree_vec_range, which lets us idiomatically iterate over all the elements of a TREE_VEC using a C++11 range-based for loop: // v is a TREE_VEC for (tree e : tree_vec_range (v)) ... This is simil

[pushed] c++: lambda template in requires [PR105541]

Since the patch for PR103408, the template parameters for the lambda in this test have level 1 instead of 2, and we were treating null template args as 1 level of arguments, so tsubst_template_parms decided it had nothing to do. Fixed by distinguishing between <> and no args at all, which is what w

Re: [PATCH] c++: improve a couple of TMPL_ARGS_* accessor macros

On 5/12/22 14:14, Patrick Palka wrote: On Thu, 12 May 2022, Patrick Palka wrote: After r13-332-g88459c3965e2a2, it looks like we can safely remove the NULL test from TMPL_ARGS_HAVE_MULTIPLE_LEVELS, which simplifies its semantics. And TMPL_ARGS_LEVEL should verify the level argument is sane in

Re: [PATCH v4] c++: ICE with temporary of class type in DMI [PR100252]

On 5/13/22 19:41, Marek Polacek wrote: On Sat, May 07, 2022 at 06:02:13PM -0400, Jason Merrill wrote: On 5/7/22 15:11, Marek Polacek wrote: On Tue, May 03, 2022 at 04:59:38PM -0400, Jason Merrill wrote: Does this testcase still work with this patch? struct A { const A* p = this; }; struc

[pushed] c++: array {}-init [PR105589]

My patch for 105191 made us use build_value_init more frequently from build_vec_init_expr, but build_value_init doesn't like to be called to initialize a class in a template. That's caused trouble in the past, and seems like a strange restriction, so let's fix it. Tested x86_64-pc-linux-gnu, appl

[pushed] c++: parsing injected-class-name as template

While I was backporting the patch for PR102300, it occurred to me that it would be cleaner to look through the injected-class-name earlier in the function. I don't think this changes any test results. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/cp/ChangeLog: * parser.cc (cp_parse

[pushed] c++: hidden friend access [DR1699]

It has come up several times that Clang considers hidden friends of a class to be sufficiently memberly to be covered by a friend declaration naming the class. This is somewhat unclear in the standard: [class.friend] says "Declaring a class to be a friend implies that private and protected members

PING#2 Re: [PATCH RFA] attribs: fix typedefs in generic code [PR105492]

Ping. On 5/10/22 16:48, Jason Merrill wrote: Ping? On 5/5/22 14:07, Jason Merrill wrote: In my patch for PR100545 I added an assert to check for broken typedefs in set_underlying_type, and it found one in this case: rs6000_handle_altivec_attribute had the same problem as handle_mode_attribute

[pushed] c++: constexpr ref to array of array [PR102307]

The problem here is that first check_initializer calls build_aggr_init_full_exprs, which does overload resolution, but then in the case of failed constexpr throws away the result and does it again in build_functional_cast. But in the first overload resolution, reshape_init_array_1 decided to reuse

Re: [PATCH] c++: suppress -Waddress warnings with *_cast [PR105569]

On 5/16/22 13:06, Marek Polacek wrote: dynamic_cast can legally return nullptr, so I don't think it's helpful for -Waddress to warn for if (dynamic_cast(&ref)) // ... More generally, it's likely not useful to warn for the artificial POINTER_PLUS_EXPRs created by build_base_path. Norma

Re: [PATCH] c++: set TYPE_CANONICAL for most templated types

On 5/16/22 15:58, Patrick Palka wrote: When processing a class template specialization, lookup_template_class uses structural equality for the specialized type whenever one of its template arguments uses structural equality. This the sensible thing to do in a vacuum, but given that we already ef

Re: [PATCH] c++: constexpr init of union sub-aggr w/ base [PR105491]

On 5/17/22 12:34, Patrick Palka wrote: On Sat, May 7, 2022 at 5:18 PM Jason Merrill wrote: On 5/6/22 16:46, Patrick Palka wrote: On Fri, 6 May 2022, Jason Merrill wrote: On 5/6/22 16:10, Patrick Palka wrote: On Fri, 6 May 2022, Patrick Palka wrote: On Fri, 6 May 2022, Jason Merrill wrote

Re: [PATCH v3] c, c++: -Wswitch warning on [[maybe_unused]] enumerator [PR105497]

On 5/17/22 19:55, Marek Polacek wrote: On Tue, May 10, 2022 at 09:54:12AM -0400, Marek Polacek wrote: On Tue, May 10, 2022 at 08:58:46AM -0400, Jason Merrill wrote: On 5/7/22 18:26, Marek Polacek wrote: Corrected version that avoids an uninitialized warning: This PR complains that we emit the

Re: [PATCH] c++: fix SIGFPE with -Wclass-memaccess [PR105634]

On 5/17/22 19:57, Marek Polacek wrote: Here we crash because we attempt to % by 0. Thus fixed. While at it, I've moved the -Wclass-memaccess tests into warn/. I've checked that the # of expected passes is the same before/after the move. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trun

Re: [PATCH] c++: set TYPE_CANONICAL for most templated types

On 5/23/22 16:25, Patrick Palka wrote: On 5/18/22, Jason Merrill wrote: On 5/16/22 15:58, Patrick Palka wrote: When processing a class template specialization, lookup_template_class uses structural equality for the specialized type whenever one of its template arguments uses structural equality

Re: [PATCH] c++: fix ICE on invalid attributes [PR96637]

On 4/29/22 10:12, Marek Polacek wrote: This patch fixes crashes with invalid attributes. Arguably it could make sense to assert seen_error() too. So in this testcase we have TREE_CHAIN of a TREE_LIST pointing to error_mark_node? Can we avoid that? Bootstrapped/regtested on x86_64-pc-linux

Re: [PATCH v5] c++: ICE with temporary of class type in DMI [PR100252]

On 5/16/22 11:36, Marek Polacek wrote: On Sat, May 14, 2022 at 11:13:28PM -0400, Jason Merrill wrote: On 5/13/22 19:41, Marek Polacek wrote: --- a/gcc/cp/typeck2.cc +++ b/gcc/cp/typeck2.cc @@ -1371,6 +1371,70 @@ digest_init_flags (tree type, tree init, int flags, tsubst_flags_t complain)

[pushed] c++: constexpr empty base redux [PR105622]

Here calling the constructor for s.__size_ had ctx->ctor for s itself because cxx_eval_store_expression doesn't create a ctor for the empty field. Then cxx_eval_call_expression returned the s initializer, and my empty base overhaul in r13-160 got confused because the type of init is not an empty cl

[pushed] c++: discarded-value and constexpr

I've been thinking for a while that the 'lval' parameter needed a third value for discarded-value expressions; most importantly, cxx_eval_store_expression does extra work for an lvalue result, and we also don't want to do the l->r conversion. Mostly this is pretty mechanical. Apart from the _stor

[pushed] c++: *this folding in constexpr call

The code in cxx_eval_call_expression to fold *this was doing the wrong thing for array decay; we can use cxx_fold_indirect_ref instead. This didn't end up being necessary to fix anything, but still seems like an improvement. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/cp/ChangeLog:

Re: [PATCH v5] c++: ICE with temporary of class type in DMI [PR100252]

On 5/24/22 09:55, Marek Polacek wrote: On Tue, May 24, 2022 at 08:36:39AM -0400, Jason Merrill wrote: On 5/16/22 11:36, Marek Polacek wrote: +static tree +replace_placeholders_for_class_temp_r (tree *tp, int *, void *data) +{ + tree t = *tp; + tree full_expr = *static_cast(data); + + /* We'r

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