Re: [PATCH v2 1/2] c++: overeager type completion in convert_to_void [PR111419]

On 9/18/23 12:19, Patrick Palka wrote: On Mon, 18 Sep 2023, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- Here convert_to_void always completes the type of an indirection or id-expression, but according to [expr.context] an

Re: [PATCH v2 2/2] c++: convert_to_void and volatile references

On 9/18/23 12:12, Patrick Palka wrote: Jason pointed out that even implicit loads of volatile references need to undergo lvalue-to-rvalue conversion, but we currently emit a warning in this case and discard the load. This patch changes this behavior so that we don't issue a warning, and

Re: [PATCH v7] c++: Move consteval folding to cp_fold_r

On 9/18/23 17:42, Marek Polacek wrote: + /* The purpose of this is not to emit errors for mce_unknown. */ + const tsubst_flags_t complain = (data->flags == ff_fold_immediate + ? tf_none : tf_error); Maybe check flags & ff_mce_false, instead? OK with that

Re: [PATCH] c++: optimize tsubst_template_decl for function templates

On 9/18/23 08:58, Patrick Palka wrote: On Sun, 17 Sep 2023, Jason Merrill wrote: On 9/17/23 15:13, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- r14-2655-g92d1425ca78040 made instantiate_template avoid redundantly performing a

Re: [PATCH] c++: non-dependent assignment checking [PR63198, PR18474]

On 9/18/23 09:12, Patrick Palka wrote: On Sun, 17 Sep 2023, Jason Merrill wrote: On 9/17/23 14:51, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? Patch generatde with -w to avoid noisy whitespace changes. -- >8 -- This patch makes us

[pushed] doc: GTY((cache)) documentation tweak

Applying to trunk as obvious (explaining existing behavior). -- 8< -- gcc/ChangeLog: * doc/gty.texi: Add discussion of cache vs. deletable. --- gcc/doc/gty.texi | 7 +++ 1 file changed, 7 insertions(+) diff --git a/gcc/doc/gty.texi b/gcc/doc/gty.texi index 15f9fa07405..1dfe4652644

Re: [pushed] c++: [[no_unique_address]] and cv-qualified type

On 9/5/23 23:19, Jason Merrill wrote: Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- We were checking for overlap using same_type_p and therefore allocating two Empty subobjects at the same offset because one was cv-qualified. This gives the warning at the location of the class name

Re: [PATCH] c++: non-dependent assignment checking [PR63198, PR18474]

On 9/17/23 14:51, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? Patch generatde with -w to avoid noisy whitespace changes. -- >8 -- This patch makes us recognize and check non-dependent simple assigments ahead of time, like we already do

Re: [PATCH] c++: optimize tsubst_template_decl for function templates

On 9/17/23 15:13, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- r14-2655-g92d1425ca78040 made instantiate_template avoid redundantly performing a specialization lookup when instantiating a function or alias template. This patch

Re: [PATCH] c++: constness of decltype of NTTP object [PR98820]

On 9/16/23 18:00, Patrick Palka wrote: On Sat, 16 Sep 2023, Jason Merrill wrote: On 9/15/23 13:55, Patrick Palka wrote: This corrects decltype of a (class) NTTP object as per [dcl.type.decltype]/1.2 and [temp.param]/6 in the type-dependent case. In the non-dependent case (nontype-class8.C) we

Re: [PATCH] c++: overeager type completion in convert_to_void [PR111419]

On 9/16/23 17:41, Patrick Palka wrote: On Sat, 16 Sep 2023, Jason Merrill wrote: On 9/15/23 12:03, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- Here convert_to_void always completes the type of an INDIRECT_REF or VAR_DECL

Re: [PATCH] c++: always check arity before deduction

On 9/12/23 20:33, Patrick Palka wrote: Bootstrpaped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? OK. -- >8 -- This simple patch extends the r12-3271-gf1e73199569287 optimization to apply to deduction without explicit template arguments as well. The motivation for this

Re: [PATCH] c++: unifying identical tmpls from current inst [PR108347]

On 9/13/23 13:53, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- Here more_specialized_partial_spec considers the two partial specializations to be unordered ultimately because unify for identical parm=arg=A::C returns failure due

Re: [PATCH] c++: optimize unification of class specializations [PR89231]

On 9/13/23 13:53, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? OK. -- >8 -- Since the LHS of a qualified-id is a non-deduced context, it effectively means we can't deduce from outer template arguments of a class template

Re: [PATCH] c++: overeager type completion in convert_to_void [PR111419]

On 9/15/23 12:03, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- Here convert_to_void always completes the type of an INDIRECT_REF or VAR_DECL expression, but according to [expr.context] an lvalue-to-rvalue conversion is applied to

Re: [PATCH] c++: visibility wrt template and ptrmem targs [PR70413]

On 9/15/23 12:03, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? OK. -- >8 -- When constraining the visibility of an instantiation, we weren't properly considering the visibility of PTRMEM_CST and TEMPLATE_DECL template arguments.

Re: [PATCH] c++: constness of decltype of NTTP object [PR98820]

On 9/15/23 13:55, Patrick Palka wrote: This corrects decltype of a (class) NTTP object as per [dcl.type.decltype]/1.2 and [temp.param]/6 in the type-dependent case. In the non-dependent case (nontype-class8.C) we resolve the decltype ahead of time, and finish_decltype_type already made sure to

Re: [PATCH v6] c++: Move consteval folding to cp_fold_r

On 9/15/23 16:32, Marek Polacek wrote: On Fri, Sep 15, 2023 at 02:08:46PM -0400, Jason Merrill wrote: On 9/13/23 20:02, Marek Polacek wrote: On Wed, Sep 13, 2023 at 05:57:47PM -0400, Jason Merrill wrote: On 9/13/23 16:56, Marek Polacek wrote: On Tue, Sep 12, 2023 at 05:26:25PM -0400, Jason

Re: [PATCH v5] c++: Move consteval folding to cp_fold_r

On 9/13/23 20:02, Marek Polacek wrote: On Wed, Sep 13, 2023 at 05:57:47PM -0400, Jason Merrill wrote: On 9/13/23 16:56, Marek Polacek wrote: On Tue, Sep 12, 2023 at 05:26:25PM -0400, Jason Merrill wrote: On 9/8/23 14:24, Marek Polacek wrote: + switch (TREE_CODE (stmt)) +{ +/*

Re: [PATCH v4] c++: Move consteval folding to cp_fold_r

On 9/13/23 16:56, Marek Polacek wrote: On Tue, Sep 12, 2023 at 05:26:25PM -0400, Jason Merrill wrote: On 9/8/23 14:24, Marek Polacek wrote: + switch (TREE_CODE (stmt)) +{ +/* Unfortunately we must handle code like +false ? bar () : 42 + where we have to check bar too.

Re: [PATCH v3] c++: Move consteval folding to cp_fold_r

On 9/8/23 14:24, Marek Polacek wrote: On Thu, Sep 07, 2023 at 02:32:51PM -0400, Jason Merrill wrote: On 9/7/23 11:23, Marek Polacek wrote: On Tue, Sep 05, 2023 at 04:36:34PM -0400, Jason Merrill wrote: On 9/5/23 15:59, Marek Polacek wrote: On Tue, Sep 05, 2023 at 10:52:04AM -0400, Jason

[PATCH RFC] diagnostic: add permerror variants with opt

Tested x86_64-pc-linux-gnu. Does this approach make sense to you? Or do you have another idea? Perhaps the warn_system_headers adjustment should also be part of this? -- 8< -- In the discussion of promoting some pedwarns to be errors by default, rather than move them all into -fpermissive it

[pushed] c++: __integer_pack with class argument [PR111357]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- The argument might not already be an integer. PR c++/111357 gcc/cp/ChangeLog: * pt.cc (expand_integer_pack): Convert argument to int. gcc/testsuite/ChangeLog: * g++.dg/ext/integer-pack7.C: New test. ---

[pushed] c++: ICE with -fno-exceptions and array init [PR107198]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- The removed line no longer has an effect on anew5.C error recovery, and removing it improves error recovery for this testcase. PR c++/107198 gcc/cp/ChangeLog: * typeck2.cc (process_init_constructor_array): Use

Re: [PATCH] c++: cache conversion function lookup

On 9/7/23 16:12, Patrick Palka wrote: On Thu, 7 Sep 2023, Jason Merrill wrote: On 9/6/23 18:07, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? This cache apparently has a 98% hit rate for TYPE_HAS_CONVERSION types on some test files.

Re: [PATCH] c++: cache conversion function lookup

On 9/6/23 18:07, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? This cache apparently has a 98% hit rate for TYPE_HAS_CONVERSION types on some test files. Does it make a measurable difference in compile time? +/* A cache of the result of

Re: [PATCH] c++: refine CWG 2369 satisfaction vs non-dep convs [PR99599]

On 9/6/23 18:09, Patrick Palka wrote: On Mon, 28 Aug 2023, Jason Merrill wrote: On 8/24/23 09:31, Patrick Palka wrote: On Wed, 23 Aug 2023, Jason Merrill wrote: On 8/21/23 21:51, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look like a reasonable

Re: [PATCH v2] c++: Move consteval folding to cp_fold_r

On 9/7/23 11:23, Marek Polacek wrote: On Tue, Sep 05, 2023 at 04:36:34PM -0400, Jason Merrill wrote: On 9/5/23 15:59, Marek Polacek wrote: On Tue, Sep 05, 2023 at 10:52:04AM -0400, Jason Merrill wrote: On 9/1/23 13:23, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok

[pushed] c++: [[no_unique_address]] and cv-qualified type

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- We were checking for overlap using same_type_p and therefore allocating two Empty subobjects at the same offset because one was cv-qualified. This gives the warning at the location of the class name rather than the member declaration, but

Re: [PATCH] c++: Additional warning for name-hiding [PR12341]

On 9/4/23 13:18, priour...@gmail.com wrote: From: benjamin priour Hi, This patch was the first I wrote and had been at that time returned to me because ill-formatted. Getting busy with other things, I forgot about it. I've now fixed the formatting. Succesfully regstrapped on

Re: [PATCH] c++: Move consteval folding to cp_fold_r

On 9/5/23 15:59, Marek Polacek wrote: On Tue, Sep 05, 2023 at 10:52:04AM -0400, Jason Merrill wrote: On 9/1/23 13:23, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- In the review of P2564:

Re: [PATCH] c++: improve verify_constant diagnostic [PR91483]

On 9/1/23 20:00, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- When verify_constant complains, it's pretty terse. Consider void test () { constexpr int i = 42; constexpr const int *p = } where it says "'& i' is not a constant

Re: [PATCH] c++: Move consteval folding to cp_fold_r

On 9/1/23 13:23, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- In the review of P2564: it turned out that in order to correctly handle an example in the paper, we should stop doing

Re: [PATCH] c++, v2: Diagnose [basic.scope.block]/2 violations even in compound-stmt of function-try-block [PR52953]

On 9/1/23 09:24, Jakub Jelinek wrote: On Thu, Aug 31, 2023 at 03:52:22PM -0400, Jason Merrill wrote: On 8/31/23 03:20, Jakub Jelinek wrote: As the following testcase shows, while check_local_shadow diagnoses most of the [basic.scope.block]/2 violations, it doesn't diagnose when parameter's

Re: [PATCH] c++, v2: Diagnose [basic.scope.block]/2 violations even for block externs [PR52953]

On 9/1/23 09:34, Jakub Jelinek wrote: On Thu, Aug 31, 2023 at 05:46:28PM -0400, Jason Merrill wrote: I've suggested this to Core. Thanks. So, I'm not really sure what to do. Intuitively the patch seems right because even block externs redeclare stuff and change meaning of the identifiers

Re: [RFC PATCH] c++: Diagnose [basic.scope.block]/2 violations even for block externs [PR52953]

On 8/31/23 04:08, Jakub Jelinek wrote: Hi! C++17 had in [basic.block.scope]/2 "A parameter name shall not be redeclared in the outermost block of the function definition nor in the outermost block of any handler associated with a function-try-block." and in [basic.block.scope]/4 similar rule

Re: [PATCH] c++: Diagnose [basic.scope.block]/2 violations even in compound-stmt of function-try-block [PR52953]

On 8/31/23 03:20, Jakub Jelinek wrote: Hi! As the following testcase shows, while check_local_shadow diagnoses most of the [basic.scope.block]/2 violations, it doesn't diagnose when parameter's name is redeclared inside of the compound-stmt of a function-try-block. There is in that case an

Re: [PATCH] c++, v3: Fix up mangling of function/block scope static structured bindings and emit abi tags [PR111069]

On 8/31/23 15:14, Jakub Jelinek wrote: On Thu, Aug 31, 2023 at 01:11:57PM -0400, Jason Merrill wrote: 2023-08-28 Jakub Jelinek PR c++/111069 gcc/ * common.opt (fabi-version=): Document version 19. * doc/invoke.texi (-fabi-version=): Likewise. gcc/c-family/ *

Re: [PATCH] c++, v2: Fix up mangling of function/block scope static structured bindings and emit abi tags [PR111069]

On 8/28/23 09:58, Jakub Jelinek wrote: Hi! On Thu, Aug 24, 2023 at 06:39:10PM +0200, Jakub Jelinek via Gcc-patches wrote: Maybe do this in mangle_decomp, based on the actual mangling in process instead of this pseudo-mangling? Not sure that is possible, for 2 reasons: 1)

Re: [PATCH] c++: Check for indirect change of active union member in constexpr [PR101631]

On 8/29/23 09:35, Nathaniel Shead wrote: This is an attempt to improve the constexpr machinery's handling of union lifetime by catching more cases that cause UB. Is this approach OK? I'd also like some feedback on a couple of pain points with this implementation; in particular, is there a good

Re: [PATCH] c++: disallow constinit on functions [PR111173]

On 8/29/23 15:01, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? OK. -- >8 -- [dcl.constinit]/1: The constinit specifier shall be applied only to a declaration of a variable with static or thread storage duration. and while we detect constinit int

Re: [PATCH] c++: CWG 2359, wrong copy-init with designated init [PR91319]

On 8/28/23 19:09, Marek Polacek wrote: On Mon, Aug 28, 2023 at 06:27:26PM -0400, Jason Merrill wrote: On 8/25/23 12:44, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- This CWG clarifies that designated initializer support direct-initialization.

Re: [PATCH v2] c++: tweaks for explicit conversion fns diagnostic

On 8/28/23 19:24, Marek Polacek wrote: On Fri, Aug 25, 2023 at 08:34:37PM -0400, Jason Merrill wrote: On 8/25/23 19:37, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- 1) When saying that a conversion is erroneous because it would use an explicit

Re: [PATCH] c++: implement P2564, consteval needs to propagate up [PR107687]

On 8/23/23 15:49, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- This patch implements P2564, described at , whereby certain functions are promoted to consteval. For example: Great, thanks! consteval int id(int i) { return i; } template

Re: [PATCH] c++: refine CWG 2369 satisfaction vs non-dep convs [PR99599]

On 8/24/23 09:31, Patrick Palka wrote: On Wed, 23 Aug 2023, Jason Merrill wrote: On 8/21/23 21:51, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look like a reasonable approach? I didn't observe any compile time/memory impact of this change. -- >8 -- As

Re: [PATCH] c++: use conversion_obstack_sentinel throughout

On 8/25/23 12:33, Patrick Palka wrote: Boostrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? OK. -- >8 -- This replaces manual memory management via conversion_obstack_alloc(0) and obstack_free with the recently added conversion_obstack_sentinel, and also uses the

Re: [PATCH] c++: more dummy non_constant_p arg avoidance

On 8/25/23 13:41, Patrick Palka wrote: Tested on x86_64-pc-linux-gnu, does this look OK for trunk? This reduces calls to is_rvalue_constant_expression from cp_parser_constant_expression by 10% for stdc++.h. OK. -- >8 -- As a follow-up to Marek's r14-3088-ga263152643bbec, this patch makes

Re: [PATCH] c++: CWG 2359, wrong copy-init with designated init [PR91319]

On 8/25/23 12:44, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- This CWG clarifies that designated initializer support direct-initialization. Just be careful what Note 2 in [dcl.init.aggr]/4.2 says: "If the initialization is by

Re: [PATCH] c++: tweaks for explicit conversion fns diagnostic

On 8/25/23 19:37, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- 1) When saying that a conversion is erroneous because it would use an explicit constructor, it might be nice to show where exactly the explicit constructor is located. For example,

Re: [PATCH] c++: Fix up mangling of function/block scope static structured bindings [PR111069]

On 8/22/23 04:12, Jakub Jelinek wrote: As can be seen on the testcase, we weren't correctly mangling static/thread_local structured bindings (C++20 feature) at function/block scope. The following patch fixes that by using what write_local_name does for those cases (note, structured binding

Re: [PATCH] c++: refine CWG 2369 satisfaction vs non-dep convs [PR99599]

On 8/21/23 21:51, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look like a reasonable approach? I didn't observe any compile time/memory impact of this change. -- >8 -- As described in detail in the PR, CWG 2369 has the surprising consequence of

Re: [PATCH] debug/111080 - avoid outputting debug info for unused restrict qualified type

On 8/21/23 05:11, Richard Biener wrote: The following applies some maintainance with respect to type qualifiers and kinds added by later DWARF standards to prune_unused_types_walk. The particular case in the bug is not handling (thus marking required) all restrict qualified type DIEs. I've

Re: [PATCH v7 2/4] p1689r5: initial support

On 7/2/23 12:32, Ben Boeckel wrote: This patch implements support for [P1689R5][] to communicate to a build system the C++20 module dependencies to build systems so that they may build `.gcm` files in the proper order. Support is communicated through the following three new flags: -

Re: [PATCH v7 1/4] driver: add a spec function to join arguments

On 7/2/23 12:32, Ben Boeckel wrote: When passing `-o` flags to other options, the typical `-o foo` spelling leaves a leading whitespace when replacing elsewhere. This ends up creating flags spelled as `-some-option-with-arg= foo.ext` which doesn't parse properly. When attempting to make a spec

[pushed 2/2] c++: maybe_substitute_reqs_for fix

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- While working on PR109751 I found that maybe_substitute_reqs_for was doing the wrong thing for a non-template friend, substituting in the template args of the scope's original template rather than those of the instantiation. This didn't end

[pushed 1/2] c++: constrained hidden friends [PR109751]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- r13-4035 avoided a problem with overloading of constrained hidden friends by checking satisfaction, but checking satisfaction early is inconsistent with the usual late checking and can lead to hard errors, so let's not do that after all.

Re: [PATCH v4] c++: extend cold, hot attributes to classes

On 8/15/23 09:41, Javier Martinez wrote: On Mon, Aug 14, 2023 at 8:32 PM Jason Merrill > wrote: > I think you also want to check for ATTR_FLAG_TYPE_IN_PLACE. > [...] > > +  propagate_class_warmth_attribute (t); > Maybe call this in check_bases_and_members instead?

Re: [PATCH v3] c++: extend cold, hot attributes to classes

On 8/11/23 09:18, Javier Martinez wrote: Hi Jason, Regarding the initialization example - no, the set of classes that we consider cold is more loosely defined. On Thu, Aug 10, 2023 at 11:01 PM Jason Merrill > wrote: > Yes, but that's because the implicit op== isn't

Re: [PATCH v1] c++: follow DR 2386 and update implementation of get_tuple_size [PR110216]

On 8/12/23 04:16, gnaggnoyil wrote: DR 2386 updated the tuple_size requirements for structured binding and it now requires tuple_size to be considered only if std::tuple_size names a complete class type with member value. GCC before this patch does not follow the updated requrements, and this

[pushed] c++: -fconcepts and __cpp_concepts

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Since -fconcepts no longer implies -fconcepts-ts, we shouldn't advertise TS support with __cpp_concepts=201507L. Also fix one case where -std=c++14 -fconcepts wasn't working (as found by range-v3 calendar). Fixing other cases is not a

Re: [PATCH] tree-pretty-print: delimit TREE_VEC with braces

On 8/11/23 13:35, Patrick Palka wrote: Tested on x86_64-pc-linux-gnu, does this look OK for trunk? OK. -- >8 -- This makes the generic pretty printer print braces around a TREE_VEC like we do for CONSTRUCTOR. This should improve readability of nested TREE_VECs in particular.

Re: [PATCH] c, c++, v2: Accept __builtin_classify_type (typename)

On 8/11/23 04:48, Jakub Jelinek wrote: On Fri, Aug 11, 2023 at 01:13:32AM +0200, Jakub Jelinek wrote: Looking at the first uses of the builtin back in 90s in va*.h, it certainly relied on array/function decay there (the macros would abort e.g. on array_type_class, function_type_class and

Re: [PATCH] c++: bogus warning w/ deduction guide in anon ns [PR106604]

On 8/11/23 09:54, Patrick Palka wrote: On Thu, 10 Aug 2023, Jason Merrill wrote: On 8/10/23 16:40, Patrick Palka wrote: On Thu, 10 Aug 2023, Jason Merrill wrote: On 8/10/23 12:09, Patrick Palka wrote: Booststrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk and

Re: [PATCH] c, c++, v2: Accept __builtin_classify_type (typename)

On 8/10/23 11:35, Jakub Jelinek wrote: Hi! I'd like to ping this patch. Reposting it as I found a typo in the documentation - s/builtin-in/built-in/. Bootstrapped/regtested again on x86_64-linux and i686-linux, ok for trunk? On Mon, Jun 12, 2023 at 09:57:17PM +0200, Jakub Jelinek via

Re: [PATCH] c++: dependently scoped template-id in type-req [PR110927]

On 8/10/23 12:08, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps 13? OK. -- >8 -- Here we're incorrectly rejecting the first type-requirement at parse time with concepts-requires35.C:14:56: error: ‘typename A::B’ is not a

Re: [PATCH] c++: recognize in-class var tmpl partial spec [PR71954]

On 8/10/23 12:08, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? OK. -- >8 -- This makes us recognize variable template partial specializations defined directly inside the class body. It seems to suffice to call

Re: [PATCH] c++: bogus warning w/ deduction guide in anon ns [PR106604]

On 8/10/23 16:40, Patrick Palka wrote: On Thu, 10 Aug 2023, Jason Merrill wrote: On 8/10/23 12:09, Patrick Palka wrote: Booststrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps 13? -- >8 -- We shouldn't issue a "declared static but never defined" warning

Re: [PATCH] c++: improve debug_tree for templated types/decls

On 8/10/23 16:59, Patrick Palka wrote: On Tue, 8 Aug 2023, Jason Merrill wrote: On 7/31/23 20:34, Patrick Palka wrote: Tested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- gcc/cp/ChangeLog: * ptree.cc (cxx_print_decl): Check for DECL_LANG_SPECIFIC and

Re: [RFC PATCH v2] c++: extend cold, hot attributes to classes

On 8/10/23 14:06, Javier Martinez wrote: Thanks for the comments, Jason. v2: + Fix formatting, remove unnecessarily warning. On Tue, Aug 8, 2023 at 10:28 PM Jason Merrill > wrote: > Seems reasonable, but how do you expect this to be used? We have large applications

Re: [PATCH] c++: bogus warning w/ deduction guide in anon ns [PR106604]

On 8/10/23 12:09, Patrick Palka wrote: Booststrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps 13? -- >8 -- We shouldn't issue a "declared static but never defined" warning for a deduction guide (declared in an anonymous namespace). PR c++/106604

Re: [PATCH] preprocessor: c++: Support `#pragma GCC target' macros [PR87299]

On 7/31/23 22:22, Lewis Hyatt via Gcc-patches wrote: `#pragma GCC target' is not currently handled in preprocess-only mode (e.g., when running gcc -E or gcc -save-temps). As noted in the PR, this means that if the target pragma defines any macros, those macros are not effective in

Re: [PATCH] c++: parser cleanup, remove dummy arguments

On 7/31/23 17:52, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Now that cp_parser_constant_expression accepts a null non_constant_p, we can transitively remove dummy arguments in the call chain. Running dg.exp and counting the # of

Re: [PATCH] c++: improve debug_tree for templated types/decls

On 7/31/23 20:34, Patrick Palka wrote: Tested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- gcc/cp/ChangeLog: * ptree.cc (cxx_print_decl): Check for DECL_LANG_SPECIFIC and TS_DECL_COMMON only when necessary. Print DECL_TEMPLATE_INFO for all decls that

Re: [PATCH 04/14] c++: use _P() defines from tree.h

On 8/2/23 12:51, Patrick Palka via Gcc-patches wrote: On Thu, Jun 1, 2023 at 2:11 PM Bernhard Reutner-Fischer wrote: Hi David, Patrick, On Thu, 1 Jun 2023 18:33:46 +0200 Bernhard Reutner-Fischer wrote: On Thu, 1 Jun 2023 11:24:06 -0400 Patrick Palka wrote: On Sat, May 13, 2023 at 7:26 

Re: [RFC] c++: extend cold, hot attributes to classes

On 8/3/23 07:07, Javier Martinez via Gcc-patches wrote: Most code is cold. This patch extends support for attribute ((cold)) to C++ Classes, Unions, and Structs (RECORD_TYPES and UNION_TYPES) to benefit from encapsulation - reducing the verbosity of using the attribute where deserved. The

Re: [PATCH] c++: Report invalid id-expression in decltype [PR100482]

On 8/7/23 22:48, Nathaniel Shead wrote: Sorry, noticed I provided the wrong version of the test. Here is the correct version (not relying on 'namespace std' being implicitly defined). Bootstrapped + regtested on x86_64-pc-linux-gnu. Pushed, thanks! -- 8< -- This patch ensures that any

Re: [PATCH] c++: follow DR 2386 and update implementation of get_tuple_size [PR110216]

On 8/6/23 14:15, gnaggnoyil wrote: DR 2386 updated the tuple_size requirements for structured binding and it now requires tuple_size to be considered only if std::tuple_size names a complete class type with member value. GCC before this patch does not follow the updated requrements, and this

Re: [PATCH v2] c-family: Implement pragma_lex () for preprocess-only mode

On 7/28/23 07:14, Lewis Hyatt wrote: On Thu, Jul 27, 2023 at 06:18:33PM -0700, Jason Merrill wrote: On 7/27/23 18:59, Lewis Hyatt wrote: In order to support processing #pragma in preprocess-only mode (-E or -save-temps for gcc/g++), we need a way to obtain the #pragma tokens from libcpp. In

Re: [PATCH] c++: devirtualization of array destruction [PR110057]

On 7/26/23 20:06, Ng YongXiang wrote: Hi Jason, I've made the following changes. 1. Add pr83054-2.C 2. Move the devirt tests to tree-ssa. 3. Remove dg do run for devirt tests 4. Add // PR c++/110057 5. Generate commit message with git gcc-commit-mklog 6. Check commit format with git gcc-verify

Re: [PATCH v2] c-family: Implement pragma_lex () for preprocess-only mode

On 7/27/23 18:59, Lewis Hyatt wrote: In order to support processing #pragma in preprocess-only mode (-E or -save-temps for gcc/g++), we need a way to obtain the #pragma tokens from libcpp. In full compilation modes, this is accomplished by calling pragma_lex (), which is a symbol that must be

Re: [PATCH v5 4/5] c++modules: report imported CMI files as dependencies

On 7/23/23 20:26, Ben Boeckel wrote: On Fri, Jul 21, 2023 at 16:23:07 -0400, Nathan Sidwell wrote: It occurs to me that the model I am envisioning is similar to CMake's object libraries. Object libraries are a convenient name for a bunch of object files. IIUC they're linked by naming the

Re: [PATCH] c++: Fix ICE with parameter pack of decltype(auto) [PR103497]

On 6/30/23 03:05, Nathaniel Shead wrote: On Thu, Jun 29, 2023 at 01:43:07PM -0400, Jason Merrill wrote: On 6/24/23 09:24, Nathaniel Shead wrote: On Fri, Jun 23, 2023 at 11:59:51AM -0400, Patrick Palka wrote: Hi, On Sat, 22 Apr 2023, Nathaniel Shead via Gcc-patches wrote: Bootstrapped and

Re: [PATCH] c-family: Implement pragma_lex () for preprocess-only mode

On 6/30/23 18:59, Lewis Hyatt wrote: In order to support processing #pragma in preprocess-only mode (-E or -save-temps for gcc/g++), we need a way to obtain the #pragma tokens from libcpp. In full compilation modes, this is accomplished by calling pragma_lex (), which is a symbol that must be

Re: [PATCH 1/2][frontend] Add novector C++ pragma

On 7/26/23 15:32, Tamar Christina wrote: + + cp_token *tok = pragma_tok; + + do { - tok = cp_lexer_consume_token (parser->lexer); - ivdep = cp_parser_pragma_ivdep (parser, tok); - tok = cp_lexer_peek_token (the_parser->lexer); +

Re: [PATCH v2][RFC] c-family: Implement __has_feature and __has_extension [PR60512]

On 6/28/23 06:35, Alex Coplan wrote: Hi, This patch implements clang's __has_feature and __has_extension in GCC. This is a v2 of the original RFC posted here: https://gcc.gnu.org/pipermail/gcc-patches/2023-May/617878.html Changes since v1: - Follow the clang behaviour where -pedantic-errors

Re: [PATCH] c++: constexpr empty subobject confusion [PR110197]

On 7/26/23 12:57, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/13 (later)? OK. -- >8 -- Now that init_subob_ctx no longer sets new_ctx.ctor for a subobject of empty type, it seems we need to ensure its callers cxx_eval_bare_aggregate

Re: [PATCH] c++: unifying REAL_CSTs [PR110809]

On 7/26/23 12:57, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/13 (after the branch is unfrozen)? OK. -- >8 -- This teaches unify how to compare two REAL_CSTs. PR c++/110809 gcc/cp/ChangeLog: * pt.cc (unify) :

[pushed] c++: member vs global template [PR106310]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- For backward compatibility we still want to allow patterns like this->A::foo, but the template keyword in a qualified name is specifically to specify that a dependent name is a template, so don't look in the enclosing scope at all. Also

Re: [PATCH] c++: devirtualization of array destruction [PR110057]

On 7/26/23 12:00, Ng YongXiang wrote: Hi Jason, Thanks for the reply and review. I've attached an updated patch with the change log and sign off. The change made in gcc/testsuite/g++.dg/warn/pr83054.C is because I think there is no more warning since we have already devirtualized the

Re: [PATCH] - Devirtualization of array destruction (C++) - 110057

On 7/12/23 10:10, Ng YongXiang via Gcc-patches wrote: Component: c++ Bug ID: 110057 Bugzilla link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110057 Description: Array should not call virtual destructor of object when array is destructed ChangeLog: 2023-07-12 Ng YongXiang PR c++

Re: [PATCH] c++: fix ICE with is_really_empty_class [PR110106]

On 7/25/23 16:30, Marek Polacek wrote: On Tue, Jul 25, 2023 at 04:24:39PM -0400, Jason Merrill wrote: On 7/25/23 15:59, Marek Polacek wrote: Something like this, then? I see that cp_parser_initializer_clause et al offer further opportunities (because they sometimes use a dummy too) but this

Re: [PATCH v5 0/3] c++: Track lifetimes in constant evaluation [PR70331, ...]

On 7/22/23 11:12, Nathaniel Shead wrote: This is an update of the patch series at https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625050.html I applied the patches, with an addition to the first patch to fix constexpr-mutable3.C in C++11 mode, which was not part of the default std set.

[pushed] testsuite: run C++11 tests in C++11 mode

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- A recent change missed updating constexpr-mutable3.C because it wasn't run in C++11 mode even though it checks the behavior for { target c++11_only }. gcc/testsuite/ChangeLog: * lib/g++-dg.exp (g++-dg-runtest): Check for

Re: [PATCH 1/2][frontend] Add novector C++ pragma

On 7/19/23 11:15, Tamar Christina wrote: Hi All, FORTRAN currently has a pragma NOVECTOR for indicating that vectorization should not be applied to a particular loop. ICC/ICX also has such a pragma for C and C++ called #pragma novector. As part of this patch series I need a way to easily turn

Re: [PATCH] c++: clear tf_partial et al in instantiate_template [PR108960]

On 7/25/23 15:55, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? OK. -- >8 -- In we concluded that we might clear all flags except tf_warning_or_error when performing

Re: [PATCH] c++: fix ICE with is_really_empty_class [PR110106]

On 7/25/23 15:59, Marek Polacek wrote: On Fri, Jul 21, 2023 at 01:44:17PM -0400, Jason Merrill wrote: On 7/20/23 17:58, Marek Polacek wrote: On Thu, Jul 20, 2023 at 03:51:32PM -0400, Marek Polacek wrote: On Thu, Jul 20, 2023 at 02:37:07PM -0400, Jason Merrill wrote: On 7/20/23 14:13, Marek

Re: [PATCH 2/1] c++: passing partially inst ttp as ttp [PR110566]

On 7/24/23 13:03, Patrick Palka wrote: On Fri, 21 Jul 2023, Jason Merrill wrote: On 7/21/23 14:34, Patrick Palka wrote: (This is a follow-up of https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624951.html) Bootstrapped and regtested on x86_64-pc-linux-gnu, how does this look? -- >8 --

Re: [PATCH v3] c++: fix ICE with constexpr ARRAY_REF [PR110382]

On 7/25/23 12:59, Marek Polacek wrote: On Tue, Jul 25, 2023 at 11:15:07AM -0400, Jason Merrill wrote: On 7/24/23 18:37, Marek Polacek wrote: On Sat, Jul 22, 2023 at 12:28:59AM -0400, Jason Merrill wrote: On 7/21/23 18:38, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok

Re: [PATCH v2] c++: fix ICE with constexpr ARRAY_REF [PR110382]

On 7/24/23 18:37, Marek Polacek wrote: On Sat, Jul 22, 2023 at 12:28:59AM -0400, Jason Merrill wrote: On 7/21/23 18:38, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/13? -- >8 -- This code in cxx_eval_array_reference has been hard to get right. In r12-2304

Re: [PATCH] c++: fix ICE with constexpr ARRAY_REF [PR110382]

On 7/21/23 18:38, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/13? -- >8 -- This code in cxx_eval_array_reference has been hard to get right. In r12-2304 I added some code; in r13-5693 I removed some of it. Here the problematic line is "S s = arr[0];" which

  1   2   3   4   5   6   7   8   9   10   >