Re: [PATCH] c++: canonicity of fn types w/ complex eh specs [PR115159]

On 5/21/24 21:55, Patrick Palka wrote: On Tue, 21 May 2024, Jason Merrill wrote: On 5/21/24 17:27, Patrick Palka wrote: On Tue, 21 May 2024, Jason Merrill wrote: On 5/21/24 15:36, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk

Re: [PATCH] c++: canonicity of fn types w/ complex eh specs [PR115159]

On 5/22/24 09:01, Patrick Palka wrote: On Tue, 21 May 2024, Jason Merrill wrote: On 5/21/24 21:55, Patrick Palka wrote: On Tue, 21 May 2024, Jason Merrill wrote: On 5/21/24 17:27, Patrick Palka wrote: On Tue, 21 May 2024, Jason Merrill wrote: On 5/21/24 15:36, Patrick Palka wrote

[PATCH RFC] c++: add module extensions

Tested x86_64-pc-linux-gnu. Any thoughts about the mkdeps output? -- 8< -- There is a trend in the broader C++ community to use a different extension for module interface units, even though they are compiled in the same way as other source files. Let's also support these extensions. .ixx is th

Re: [PATCH] Fix auto deduction for template specialization scopes [114915].

Thanks for the patch! Please review https://gcc.gnu.org/contribute.html for more details of the format patches should have. In particular, you don't seem to have a copyright assignment on file with the FSF, so you'll need to either do that or certify that the contribution is under the DCO.

Re: [PATCH] Fix auto deduction for template specialization scopes [114915].

On 5/22/24 12:48, Patrick Palka wrote: On Wed, 22 May 2024, Jason Merrill wrote: Thanks for the patch! Please review https://gcc.gnu.org/contribute.html for more details of the format patches should have. In particular, you don't seem to have a copyright assignment on file with the FS

Re: [PATCH v4] c++: fix constained auto deduction in templ spec scopes [PR114915]

OK, on the right patch this time I hope. Looks like you still need either FSF copyright assignment or DCO certification per https://gcc.gnu.org/contribute.html#legal On 5/15/24 13:27, Seyed Sajad Kahani wrote: This patch resolves PR114915 by replacing the logic that fills in the missing level

Re: [PATCH 1/2] c++/modules: Fix treatment of unnamed types

On 5/23/24 09:27, Nathaniel Shead wrote: On Mon, May 20, 2024 at 06:00:09PM -0400, Jason Merrill wrote: On 5/17/24 02:14, Nathaniel Shead wrote: On Tue, May 14, 2024 at 06:21:48PM -0400, Jason Merrill wrote: On 5/12/24 22:58, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc

Re: [PATCH 2/2] c++/modules: Remember that header units have CMIs

On 5/23/24 09:29, Nathaniel Shead wrote: And here's that patch. As far as I can tell there should be no visible change anymore, so there aren't any testcases. Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? OK. -- >8 -- This appears to be an oversight in the definition of

Re: [PATCH] c++/modules: Ensure all partial specialisations are tracked [PR114947]

On 5/12/24 09:29, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? -- >8 -- Constrained partial specialisations aren't all necessarily tracked on the instantiation table. The modules code uses a separate 'partial_specializations' table to track them inste

Re: [PATCH] c++: mark TARGET_EXPRs for function arguments eliding [PR114707]

On 5/23/24 10:41, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Coming back to our discussion in : TARGET_EXPRs that initialize a function argument are not marked TARGET_EXPR_ELIDING_P

[pushed] c++: deleting array temporary [PR115187]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Decaying the array temporary to a pointer and then deleting that crashes in verify_gimple_stmt, because the TARGET_EXPR is first evaluated inside the TRY_FINALLY_EXPR, but the cleanup point is outside. Fixed by using get_target_expr instead

Re: [PATCH] c++/modules: Improve errors for bad module-directives [PR115200]

On 5/23/24 10:54, Nathaniel Shead wrote: Bootstrapped and regtested (so far just modules.exp and dg.exp) on x86_64-pc-linux-gnu, OK for trunk if full regtest succeeds? -- >8 -- This fixes an ICE when a module directive is not given at global scope. Although not explicitly mentioned, it seems im

Re: [PATCH] c++: alias CTAD and copy deduction guide [PR115198]

On 5/23/24 14:06, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/14? -- >8 -- Here we're neglecting to update DECL_NAME during the alias CTAD guide transformation, which causes copy_guide_p to return false for the transformed copy deduction g

Re: [PATCH] c++: alias CTAD and copy deduction guide [PR115198]

On 5/23/24 17:42, Patrick Palka wrote: On Thu, 23 May 2024, Jason Merrill wrote: On 5/23/24 14:06, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/14? -- >8 -- Here we're neglecting to update DECL_NAME during the alias CT

Re: [PATCH][14 backport] c++: Fix instantiation of imported temploid friends [PR114275]

On 5/13/24 07:56, Nathaniel Shead wrote: @@ -11751,9 +11767,16 @@ tsubst_friend_class (tree friend_tmpl, tree args) if (tmpl != error_mark_node) { /* The new TMPL is not an instantiation of anything, so we -forget its origins. We don't reset CLASSTYPE_TI_TE

PING Re: PING Re: [PATCH RFA (cgraph)] c++: pragma target and static init [PR109753]

Ping On 5/14/24 17:21, Jason Merrill wrote: Ping On 5/2/24 09:54, Jason Merrill wrote: Tested x86_64-pc-linux-gnu, OK for trunk?  14.2? This two-year-old thread seems relevant: https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593410.html -- 8< --   #pragma target and optimize sho

Re: [PATCH][14 backport] c++: Fix instantiation of imported temploid friends [PR114275]

On 5/24/24 04:06, Nathaniel Shead wrote: On Thu, May 23, 2024 at 06:41:06PM -0400, Jason Merrill wrote: On 5/13/24 07:56, Nathaniel Shead wrote: @@ -11751,9 +11767,16 @@ tsubst_friend_class (tree friend_tmpl, tree args) if (tmpl != error_mark_node) { /* The new TMPL

Re: [PATCH 1/2] c++/modules: Fix treatment of unnamed types

On 5/23/24 21:27, Nathaniel Shead wrote: On Thu, May 23, 2024 at 03:36:48PM -0400, Jason Merrill wrote: On 5/23/24 09:27, Nathaniel Shead wrote: On Mon, May 20, 2024 at 06:00:09PM -0400, Jason Merrill wrote: On 5/17/24 02:14, Nathaniel Shead wrote: On Tue, May 14, 2024 at 06:21:48PM -0400

Re: [PATCH v2] c++: mark TARGET_EXPRs for function arguments eliding [PR114707]

On 5/23/24 20:32, Marek Polacek wrote: On Thu, May 23, 2024 at 04:04:13PM -0400, Jason Merrill wrote: On 5/23/24 10:41, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Coming back to our discussion in <https://gcc.gnu.org/pipermail/gcc-patche

Re: [PATCH v2] c++/modules: Improve errors for bad module-directives [PR115200]

On 5/23/24 19:58, Nathaniel Shead wrote: On Thu, May 23, 2024 at 05:11:39PM -0400, Jason Merrill wrote: On 5/23/24 10:54, Nathaniel Shead wrote: Bootstrapped and regtested (so far just modules.exp and dg.exp) on x86_64-pc-linux-gnu, OK for trunk if full regtest succeeds? -- >8 -- This fi

Re: [PATCH] c++: extend -Wself-move for mem-init-list [PR109396]

On 5/23/24 19:57, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- We already warn for: x = std::move (x); which triggers: warning: moving 'x' of type 'int' to itself [-Wself-move] but bug 109396 reports that this doesn't work for a member-init

Re: [PATCH][14 backport] c++: Fix instantiation of imported temploid friends [PR114275]

On 5/24/24 10:40, Iain Sandoe wrote: On 24 May 2024, at 14:54, Jason Merrill wrote: On 5/24/24 04:06, Nathaniel Shead wrote: On Thu, May 23, 2024 at 06:41:06PM -0400, Jason Merrill wrote: On 5/13/24 07:56, Nathaniel Shead wrote: @@ -11751,9 +11767,16 @@ tsubst_friend_class (tree

Re: [PATCH] c++/modules: Improve diagnostic when redeclaring builtin in module [PR102345]

On 5/24/24 11:20, Nathaniel Shead wrote: This is just a small improvement to a diagnostic. I thought about also adding an inform to suggest something like "standard library headers should be included in the GMF" or somesuch, but I'm not sure that'll be especially valuable and may be confusing if

Re: [PATCH] c++/modules: Improve diagnostic when redeclaring builtin in module [PR102345]

On 5/24/24 11:32, Nathaniel Shead wrote: On Fri, May 24, 2024 at 11:24:38AM -0400, Jason Merrill wrote: On 5/24/24 11:20, Nathaniel Shead wrote: This is just a small improvement to a diagnostic. I thought about also adding an inform to suggest something like "standard library headers s

Re: [PATCH] Add testcase for PR c++/105229: ICE in lookup_template_class_1

On 5/24/24 08:16, Simon Martin wrote: The test case in PR c++/105229 has been fixed since 11.4 (via PR c++/106024) - the attached patch simply adds the case to the test suite. Successfully tested on x86_64-pc-linux-gnu. OK for trunk? OK, thanks. BTW, the patch was corrupted by your mail clien

Re: [PATCH] c++: Fix parsing of abstract-declarator starting with ... followed by [ or ( [PR115012]

On 5/9/24 14:12, Jakub Jelinek wrote: The C++26 P2662R3 Pack indexing paper mentions that both GCC and MSVC don't handle T...[10] parameter declaration when T is a pack. While that will change meaning in C++26, in C++11 .. C++23 this ought to be valid. Sure, but I don't think it does anyone a

Re: [PATCH] c++/modules: Prevent revealing a using-decl affecting cached overloads [PR114867]

On 5/26/24 09:01, Nathaniel Shead wrote: Is this approach OK? Alternatively I suppose we could do a deep copy of the overload list when this occurs to ensure we don't affect existing referents, would that be preferable? This strategy makes sense, but I have other concerns: Bootstrapped and r

Re: [PATCH] c++: canonicity of fn types w/ instantiated eh specs [PR115223]

On 5/25/24 19:18, Patrick Palka wrote: Bootstrap and regtest on x86_64-pc-linux-gnu in progress, does this look OK for trunk if successful? OK. -- >8 -- When propagating structural equality in build_cp_fntype_variant, we should consider structural equality of the exception-less variant, not

Re: [PATCH v3 #1/2] enable adjustment of return_pc debug attrs

On 5/25/24 08:12, Alexandre Oliva wrote: On Apr 27, 2023, Alexandre Oliva wrote: On Apr 14, 2023, Alexandre Oliva wrote: On Mar 23, 2023, Alexandre Oliva wrote: This patch introduces infrastructure for targets to add an offset to the label issued after the call_insn to set the call_return_p

Re: [PATCH v2] C/C++: add hints for strerror

Pushed, thanks! On 2/27/24 20:13, Oskari Pirhonen wrote: Add proper hints for implicit declaration of strerror. The results could be confusing depending on the other included headers. These example messages are from compiling a trivial program to print the string for an errno value. It only inc

[pushed] c++: add module extensions

Revised to change mkdeps and the docs. Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- There is a trend in the broader C++ community to use a different extension for module interface units, even though (in GCC) they are compiled in the same way as other source files. Let's recognize the

[pushed] c++: pragma target and static init [PR109753]

Revised to drop the cgraph change so I can self-approve the remaining patch. Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- #pragma target and optimize should also apply to implicitly-generated functions like static initialization functions and defaulted special member functions. Th

Re: [PATCH v2] c++/modules: Fix revealing with using-decls [PR114867]

On 5/31/24 11:57, Nathaniel Shead wrote: On Tue, May 28, 2024 at 02:57:09PM -0400, Jason Merrill wrote: What if we're revealing without exporting? That is, a using-declaration in module purview that isn't exported? Such a declaration should still prevent discarding, which is my und

Re: [PATCH] Fix PR c++/109958: ICE taking the address of bound static member function brought into derived class by using-declaration

On 5/31/24 09:58, Simon Martin wrote: From: Simon Martin We currently ICE upon the following because we don't properly handle the overload created for B::f through the using statement. === cut here === struct B { static int f(); }; struct D : B { using B::f; }; void f(D d) { &d.f; } === cut he

Re: [PATCH] Fix PR c++/111106: missing ; causes internal compiler error

On 5/30/24 07:31, Simon Martin wrote: We currently fail upon the following because an assert in dependent_type_p fails for f's parameter === cut here === consteval int id (int i) { return i; } constexpr int f (auto i) requires requires { id (i) } { return i; } void g () { f (42); } === cut here

Re: [PATCH] c-family: Introduce the -Winvalid-noreturn flag from clang with extra tuneability

On 5/29/24 09:58, Julian Waters wrote: Currently, gcc warns about noreturn marked functions that return both explicitly and implicitly, with no way to turn this warning off. clang does have an option for these classes of warnings, -Winvalid-noreturn. However, we can do better. Instead of just

Re: [PATCH v2 1/2] Factor out static_assert constexpr string extraction for reuse

On 6/2/24 23:45, Andi Kleen wrote: No intentional semantics change. gcc/cp/ChangeLog: * cp-tree.h (struct cstr): Add structure. (get_cstr): Declare. (extract_cstr): Declare. (free_cstr): Declare. * semantics.cc (finish_static_assert): Factor out constant

Re: [PATCH v7 4/9] C++: Support clang compatible [[musttail]] (PR83324)

On 6/2/24 13:16, Andi Kleen wrote: This patch implements a clang compatible [[musttail]] attribute for returns. musttail is useful as an alternative to computed goto for interpreters. With computed goto the interpreter function usually ends up very big which causes problems with register allocat

Re: [PATCH v7 6/9] Add tests for C/C++ musttail attributes

On 6/2/24 13:16, Andi Kleen wrote: Mostly adopted from the existing C musttail plugin tests. gcc/testsuite/ChangeLog: * c-c++-common/musttail1.c: New test. * c-c++-common/musttail2.c: New test. * c-c++-common/musttail3.c: New test. * c-c++-common/musttail4.c: New

Re: [PATCH v2 2/2] C++: Support constexpr strings for asm statements

On 6/2/24 23:45, Andi Kleen wrote: Some programing styles use a lot of inline assembler, and it is common to use very complex preprocessor macros to generate the assembler strings for the asm statements. In C++ there would be a typesafe alternative using templates and constexpr to generate the as

Re: [PATCH v7 4/9] C++: Support clang compatible [[musttail]] (PR83324)

On 6/3/24 11:44, Jakub Jelinek wrote: On Mon, Jun 03, 2024 at 08:33:52AM -0700, Andi Kleen wrote: On Mon, Jun 03, 2024 at 10:42:20AM -0400, Jason Merrill wrote: @@ -30316,7 +30348,7 @@ cp_parser_std_attribute (cp_parser *parser, tree attr_ns) /* Maybe we don't expect to se

Re: [PATCH] c-family: Introduce the -Winvalid-noreturn flag from clang with extra tuneability

OPT_ entries? Typically = options will specify RejectNegative so the driver will reject e.g. -Wno-invalid-noreturn=explicit. Jason best regards, Julian On Sat, Jun 1, 2024 at 4:57 AM Jason Merrill wrote: On 5/29/24 09:58, Julian Waters wrote: Currently, gcc warns about noreturn marked func

Re: [PATCH v7 4/9] C++: Support clang compatible [[musttail]] (PR83324)

On 6/3/24 15:35, Andi Kleen wrote: On Mon, Jun 03, 2024 at 12:29:28PM -0400, Jason Merrill wrote: On 6/3/24 11:44, Jakub Jelinek wrote: On Mon, Jun 03, 2024 at 08:33:52AM -0700, Andi Kleen wrote: On Mon, Jun 03, 2024 at 10:42:20AM -0400, Jason Merrill wrote: @@ -30316,7 +30348,7

Re: [PATCH] Fix PR c++/111106: missing ; causes internal compiler error

On 6/4/24 05:47, Simon Martin wrote: Hi Jason, Thanks for the review. On 31 May 2024, at 22:45, Jason Merrill wrote: On 5/30/24 07:31, Simon Martin wrote: We currently fail upon the following because an assert in dependent_type_p fails for f's parameter === cut here === consteval i

Re: [PATCH v2] gcc, libcpp: Add warning switch for "#pragma once in main file" [PR89808]

On 3/14/24 04:01, Ken Matsui wrote: On Sat, Mar 2, 2024 at 5:04 AM Ken Matsui wrote: This patch adds a warning switch for "#pragma once in main file". The warning option name is Wpragma-once-outside-header, which is the same as Clang. Ping. PR preprocessor/89808 gcc/c-family/Ch

Re: [PATCH] PR c++/103338 - Add testcase for issue fixed by recent commit

On 6/4/24 11:54, Simon Martin wrote: The case in that PR used to ICE until commit f04dc89. Interesting, I don't remember expecting that patch to change behavior at all. BTW, it looks like your recent commits and emails have had non-conventional subject lines; see https://gcc.gnu.org/contri

Re: [PATCH v2] c++/modules: Handle instantiating qualified template friend classes [PR115801]

On 8/7/24 7:45 PM, Nathaniel Shead wrote: On Wed, Aug 07, 2024 at 01:44:31PM -0400, Jason Merrill wrote: On 8/6/24 2:35 AM, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? Another potential approach would be to go searching for this unexported type and

Re: [PATCH] c++/modules: Fix merging of GM entities in partitions [PR114950]

On 8/7/24 7:22 PM, Nathaniel Shead wrote: On Wed, Aug 07, 2024 at 04:18:47PM -0400, Jason Merrill wrote: On 8/5/24 9:16 AM, Nathaniel Shead wrote: Bootstrapped and regtested (so far just modules.exp) on x86_64-pc-linux-gnu, OK for trunk if full regtest passes? OK. @@ -11316,6 +11319,7

Re: [PATCH] c++: improve diagnostic of 'return's in coroutines

On 8/7/24 7:31 PM, Arsen Arsenović wrote: Enlargening the function-specific data block is not great. Indeed, I think it would be better to search DECL_SAVED_TREE for a RETURN_STMT once we've decided to give an error. I've considered changing the location of RETURN_STMT expressions to cover

Re: [PATCH] c++/modules: Clarify error message in read_enum_def

On 8/7/24 7:08 PM, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? OK. -- >8 -- This error message reads to me the wrong way around, particularly in the context of other errors. Updated so that the ellipsis connect. gcc/cp/ChangeLog: * modul

Re: [PATCH v3] c++/modules: Handle instantiating already tsubsted template friend classes [PR115801]

On 8/7/24 10:00 PM, Nathaniel Shead wrote: On Wed, Aug 07, 2024 at 09:12:13PM -0400, Patrick Palka wrote: On Wed, 7 Aug 2024, Patrick Palka wrote: On Thu, 8 Aug 2024, Nathaniel Shead wrote: On Wed, Aug 07, 2024 at 01:44:31PM -0400, Jason Merrill wrote: On 8/6/24 2:35 AM, Nathaniel Shead

Re: [PATCH] c++: improve diagnostic of 'return's in coroutines

On 8/7/24 9:00 PM, Arsen Arsenović wrote: Jason Merrill writes: On 8/7/24 7:31 PM, Arsen Arsenović wrote: Enlargening the function-specific data block is not great. Indeed, I think it would be better to search DECL_SAVED_TREE for a RETURN_STMT once we've decided to give an error.

Re: [PATCH] c++/modules: Assume header bindings are global module

On 8/8/24 8:06 AM, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? OK. -- >8 -- While stepping through some code I noticed that we do some extra work (finding the originating module decl, stripping the template, and inspecting the attached-ness) for ev

Re: [PATCH] c++: Propagate TREE_ADDRESSABLE in fixup_type_variants [PR115062]

On 8/8/24 7:59 AM, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? OK. The change to 'finish_struct_bits' is not required for this PR but I felt it was a nice cleanup; happy to commit without it though if preferred. -- >8 -- This has caused issues wit

Re: [PATCH v2] c++: improve diagnostic of 'return's in coroutines

On 8/8/24 4:29 PM, Arsen Arsenović wrote: Tested on x86_64-pc-linux-gnu. I have blinking tsan test results again, but I think they're bogus (I'll re-test on physical hardware before pushing if needed). I'm somewhat curious of we should do a similar change WRT RETURN_EXPRs in the C FE (currently

Re: [PATCH 13 backport] c++: local class memfn synth from uneval context [PR113063]

On 8/8/24 2:38 PM, Patrick Palka wrote: Bootstrap and regtest in progress, does this look OK for the 13 branch if successful? OK. -- >8 -- This is essentially a narrow backport of r14-6724-gfced59166f95e9 that uses cp_evaluated instead of maybe_push_to_top_level to clear cp_unevaluated_opera

Re: [PATCH 1/5] cp: Ensure ANNOTATE_EXPRs remain outermost expressions in conditions [PR116140]

On 8/9/24 5:26 AM, Alex Coplan wrote: For the testcase added with this patch, we would end up losing the: #pragma GCC unroll 4 and emitting "warning: ignoring loop annotation". That warning comes from tree-cfg.cc:replace_loop_annotate, and means that we failed to process the ANNOTATE_EXPR i

Re: [PATCH] c++: Don't accept multiple enum definitions within template class [PR115806]

On 8/9/24 4:19 AM, Simon Martin wrote: We have been accepting the following invalid code since revision 557831a91df === cut here === template struct S { enum E { a }; enum E { b }; }; S s; === cut here === The problem is that start_enum will set OPAQUE_ENUM_P to true even if it retrieves

Re: [PATCH] c++: ICE with NSDMIs and fn arguments [PR116015]

On 8/8/24 1:37 PM, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- The problem in this PR is that we ended up with {.rows=(&)->n, .outer_stride=(&)->rows} that is, two PLACEHOLDER_EXPRs for different types on the same level in one { }. That sh

Re: [PATCH] c++: inherited CTAD fixes [PR116276]

On 8/8/24 1:00 PM, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/14? -- >8 -- This implements the inherited vs non-inherited guide tiebreaker specified by P2582R1. In order to track inherited-ness of a guide it seems natural to reuse the la

Re: [PATCH] c++: clean up cp_identifier_kind checks

On 8/8/24 11:31 AM, Patrick Palka wrote: The predicates for checking an IDENTIFIER node's cp_identifier_kind currently directly test the three flag bits that encode the kind. This patch instead makes the checks first reconstruct the cp_identifier_kind in its entirety and then compare that. OK.

Re: [PATCH] c++: DECL_UNINSTANTIATED_TEMPLATE_FRIEND_P cleanups

On 8/8/24 11:30 AM, Patrick Palka wrote: DECL_UNINSTANTIATED_TEMPLATE_FRIEND_P templates can only appear as part of a template friend declaration, and in turn get partially instantiated only from tsubst_friend_function or tsubst_friend_class. So rather than having tsubst_template_decl clear the

Re: [PATCH] c++: inherited CTAD fixes [PR116276]

On 8/9/24 2:32 PM, Patrick Palka wrote: On Fri, 9 Aug 2024, Patrick Palka wrote: On Fri, 9 Aug 2024, Jason Merrill wrote: On 8/8/24 1:00 PM, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/14? -- >8 -- This implements the inherited

Re: [PATCH] c++: ICE with NSDMIs and fn arguments [PR116015]

On 8/9/24 4:21 PM, Marek Polacek wrote: On Fri, Aug 09, 2024 at 12:58:34PM -0400, Jason Merrill wrote: On 8/8/24 1:37 PM, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- The problem in this PR is that we ended up with {.rows=(&a

Re: [PATCH] c++: inherited CTAD fixes [PR116276]

On 8/9/24 3:30 PM, Patrick Palka wrote: On Fri, 9 Aug 2024, Jason Merrill wrote: On 8/9/24 2:32 PM, Patrick Palka wrote: On Fri, 9 Aug 2024, Patrick Palka wrote: On Fri, 9 Aug 2024, Jason Merrill wrote: On 8/8/24 1:00 PM, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux

Re: [PATCH v2] c++: ICE with NSDMIs and fn arguments [PR116015]

On 8/12/24 7:21 PM, Marek Polacek wrote: On Fri, Aug 09, 2024 at 05:15:05PM -0400, Jason Merrill wrote: On 8/9/24 4:21 PM, Marek Polacek wrote: On Fri, Aug 09, 2024 at 12:58:34PM -0400, Jason Merrill wrote: On 8/8/24 1:37 PM, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu

Re: [PATCH] c++/coroutines: fix passing *this to promise type, again [PR116327]

On 8/12/24 10:01 PM, Patrick Palka wrote: Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14? -- >8 -- In r15-2210 we got rid of the unnecessary cast to lvalue reference when passing *this to the promise type ctor, and as a drive-by change we also simplified the code to use cp_build_

Re: [PATCH] c++/coroutines: fix passing *this to promise type, again [PR116327]

On 8/13/24 7:52 PM, Patrick Palka wrote: On Tue, 13 Aug 2024, Jason Merrill wrote: On 8/12/24 10:01 PM, Patrick Palka wrote: Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14? -- >8 -- In r15-2210 we got rid of the unnecessary cast to lvalue reference when passing *this to

Re: [PATCH] c++/coroutines: fix passing *this to promise type, again [PR116327]

On 8/14/24 9:47 AM, Patrick Palka wrote: On Tue, 13 Aug 2024, Jason Merrill wrote: On 8/13/24 7:52 PM, Patrick Palka wrote: On Tue, 13 Aug 2024, Jason Merrill wrote: On 8/12/24 10:01 PM, Patrick Palka wrote: Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14? -- >8 -- In

Re: [PATCH] c++: c->B::m access resolved through current inst [PR116320]

On 8/14/24 10:50 AM, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk and later backports? Yes. -- >8 -- Here when checking the access of (the injected-class-name) B in c->B::m at parse time, we notice its scope B (now the type) is a base of

Re: [PATCH v2] c++: Ensure ANNOTATE_EXPRs remain outermost expressions in conditions [PR116140]

On 8/12/24 1:55 PM, Alex Coplan wrote: Hi! This is a v2 patch of: https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659968.html that addresses Jakub's feedback. FWIW, I tried to contrive a testcase where convert_from_reference kicks in and we get called with an ANNOTATE_EXPR in maybe_conver

Re: [PATCH] c++: Pedwarn on [[]]; at class scope [PR110345]

On 8/15/24 4:58 PM, Jakub Jelinek wrote: Hi! For C++ 26 P2552R3 I went through all the spots (except modules) where attribute-specifier-seq appears in the grammar and tried to construct a testcase in all those spots, for now for [[deprecated]] attribute. The fourth issue is that we just emit (w

Re: [PATCH v3] Improve bad error message with stray semicolon in initializer (and related) [PR101232]

On 8/19/24 6:01 AM, Jonathan Wakely wrote: On 05/08/24 09:32 +0200, Franciszek Witt wrote: Author: Franciszek Witt Date:   Mon Aug 5 09:00:35 2024 +0200    c++: [PR101232] The line above should be the first line of your Git commit message, which should be in the form "component: Summary of c

Re: [PATCH v3] Improve bad error message with stray semicolon in initializer (and related) [PR101232]

On 8/19/24 12:01 PM, Jason Merrill wrote: On 8/19/24 6:01 AM, Jonathan Wakely wrote: On 05/08/24 09:32 +0200, Franciszek Witt wrote: Author: Franciszek Witt Date:   Mon Aug 5 09:00:35 2024 +0200    c++: [PR101232] The line above should be the first line of your Git commit message, which

Re: [PATCH v10 1/3] gcc/: Rename array_type_nelts() => array_type_nelts_minus_one()

On 8/19/24 6:58 AM, Alejandro Colomar wrote: The old name was misleading. While at it, also rename some temporary variables that are used with this function, for consistency. Link: https://inbox.sourceware.org/gcc-patches/9fffd80-dca-2c7e-14b-6c9b509a7...@redhat.com/T/#m2f661c67c8f7b2c405c8c7f

Re: [PATCH] c++/modules: Slightly clean up error for referencing TU-local entity

On 8/18/24 8:11 AM, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? Or should we even just remove the warning entirely? I'm not sure it really adds all that much, since it's usual AFAICT for errors to prevent the intended outputs from being generated. A

Re: [PATCH] c++/modules: Handle transitive reachability for deduction guides [PR116403]

On 8/17/24 9:45 PM, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? OK. -- >8 -- Currently we implement [temp.deduct.guide] p1 by forcing all deduction guides to be considered as exported. However this is not sufficient: for transitive non-exported im

Re: [PATCH] c++/modules: Disable streaming definitions of non-vague-linkage GMF decls [PR115020]

On 8/17/24 8:51 AM, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? -- >8 -- The error in the linked PR is caused because 'DECL_THIS_STATIC' is true for the static member function, causing the streaming code to assume that this is an internal linkage GM e

Re: [PATCH] c++: fix ICE in convert_nontype_argument [PR116384]

On 8/16/24 4:07 PM, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? OK for trunk and 14. -- >8 -- Here we ICE since r14-8291 in C++11/C++14 modes. Fortunately this is an easy one. The important bit of r14-8291 is this: @@ -20056,9 +20071,12 @@ tsubst_expr

Re: [PATCH] c++: default targ eligibility refinement [PR101463]

On 8/16/24 12:00 PM, Patrick Palka wrote: Here during default template argument substitution we wrongly consider the (substituted) default arguments v and vt as value-dependent[1] which ultimately leads to deduction failure for the calls. The bogus value_dependent_expression_p result aside, I no

Re: [PATCH] c++: ICE with enum and conversion fn in template [PR115657]

On 8/16/24 9:44 AM, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? OK. -- >8 -- Here we initialize an enumerator with a class prvalue with a conversion function. When we fold it in build_enumerator, we create a TARGET_EXPR for the object, and subsequently c

Re: [PATCH v2] c++: Ensure ANNOTATE_EXPRs remain outermost expressions in conditions [PR116140]

On 8/16/24 7:20 AM, Alex Coplan wrote: On 16/08/2024 12:47, Jakub Jelinek wrote: On Fri, Aug 16, 2024 at 11:38:03AM +0100, Alex Coplan wrote: Looking at the calls to build3 (ANNOTATE_EXPR, ...) in cp/semantics.cc, it looks like the other two operands of ANNOTATE_EXPRs are only ever INTEGER_CSTs

Re: [PATCH] c++/modules: Avoid rechecking initializers when streaming NTTPs [PR116382]

On 8/16/24 2:55 AM, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? Maybe also skip the unshare_constructor when !check_init? OK either way. -- >8 -- When reading an NTTP we call get_template_parm_object which delegates setting of DECL_INITIAL to the

Re: [RFC PATCH] c++: Disallow [[deprecated]] on types other than class/enum definitions [PR110345]

On 8/15/24 5:13 PM, Jakub Jelinek wrote: Hi! For C++ 26 P2552R3 I went through all the spots (except modules) where attribute-specifier-seq appears in the grammar and tried to construct a testcase in all those spots, for now for [[deprecated]] attribute. The patch below contains that testcase.

Re: [PATCH] c++: Parse and ignore attributes on base specifiers [PR110345]

On 8/15/24 4:53 PM, Jakub Jelinek wrote: Hi! For C++ 26 P2552R3 I went through all the spots (except modules) where attribute-specifier-seq appears in the grammar and tried to construct a testcase in all those spots, for now for [[deprecated]] attribute. This is the third issue I found. https:

Re: [PATCH] c++: Allow standard attributes after closing square bracket in new-type-id [PR110345]

On 8/15/24 4:53 PM, Jakub Jelinek wrote: Hi! For C++ 26 P2552R3 I went through all the spots (except modules) where attribute-specifier-seq appears in the grammar and tried to construct a testcase in all those spots, for now for [[deprecated]] attribute. The first thing I found is that we aren'

Re: [PATCH] c++: Appertain standard attributes after array closing square bracket to array type rather than declarator [PR110345]

On 8/15/24 4:53 PM, Jakub Jelinek wrote: Hi! For C++ 26 P2552R3 I went through all the spots (except modules) where attribute-specifier-seq appears in the grammar and tried to construct a testcase in all those spots, for now for [[deprecated]] attribute. This is the second issue I found. The c

Re: [PATCH] c++/modules: Fix type lookup in DECL_TEMPLATE_INSTANTIATIONS [PR116364]

On 8/15/24 7:55 AM, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? OK. -- >8 -- We need to use the DECL_TEMPLATE_INSTANTIATIONS property to find reachable specialisations from a template to ensure that any GM specialisations are properly marked as rea

Re: [PATCH v4] Improve bad error message with stray semicolon in initializer (and related) [PR101232]

On 8/20/24 9:11 AM, Franciszek Witt wrote: Thanks for the feedback. I am attatching fixed patch as a file. Pushed, thanks. Regards Franciszek On Mon, 19 Aug 2024, 18:32 Jason Merrill, <mailto:ja...@redhat.com>> wrote: On 8/19/24 12:01 PM, Jason Merrill wrote: > On 8/1

Re: [PATCH v2] c++/modules: Remove unnecessary errors when not writing compiled module

On 8/20/24 3:02 AM, Nathaniel Shead wrote: On Mon, Aug 19, 2024 at 12:55:22PM -0400, Jason Merrill wrote: On 8/18/24 8:11 AM, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? Or should we even just remove the warning entirely? I'm not sure it r

Re: [PATCH] c++: Partially implement CWG 2867 - Order of initialization for structured bindings [PR115769]

On 8/14/24 3:41 AM, Jakub Jelinek wrote: Hi! The following patch partially implements CWG 2867 - Order of initialization for structured bindings. The DR requires that initialization of e is sequenced before r_i and that r_i initialization is sequenced before r_j for j > i, we already do it that

Re: [PATCH v3 1/2] c++: improve location of parsed RETURN_EXPRs

On 8/21/24 1:52 PM, Arsen Arsenović wrote: For clarity, here's the entire split-up patch I intend to push, if it looks OK. Tested on x86_64-pc-linux-gnu. I've renamed the field we've discussed and also a few parameters that refer to 'kw' to be less specific. The code is functionally identical.

Re: [PATCH v3 1/2] c++: improve location of parsed RETURN_EXPRs

On 8/21/24 3:34 PM, Arsen Arsenović wrote: Jason Merrill writes: On 8/21/24 1:52 PM, Arsen Arsenović wrote: For clarity, here's the entire split-up patch I intend to push, if it looks OK. Tested on x86_64-pc-linux-gnu. I've renamed the field we've discussed and also a few

Re: [PATCH v3 2/2] c++: improve diagnostic of 'return's in coroutines

On 8/21/24 1:52 PM, Arsen Arsenović wrote: We now point out why a function is a coroutine, and where (the first return) is in the function. OK. gcc/cp/ChangeLog: * coroutines.cc (struct coroutine_info): Rename first_coro_keyword -> first_coro_expr. The former name is no

Re: [PATCH] warn-access: ignore template parameters when matching operator new/delete [PR109224]

On 8/2/24 4:36 PM, Arsen Arsenović wrote: I'm not 100% clear on what the semantics of the matching here are meant to be - AFAICT, an operator new/delete pair matches (after falling through the other cases) if all their components (besides the actual operator name, of course) match, and the pair o

Re: [PATCH] coroutines: diagnose usage of alloca in coroutines

On 8/7/24 9:15 AM, Arsen Arsenović wrote: Tested on x86_64-pc-linux-gnu. OK for trunk? -- >8 -- We do not support it currently, and the resulting memory can only be used inside a single resumption, so best not confuse the user with it. PR c++/115858 - Incompatibility of coroutin

Re: [PATCH] c++, coroutines: Tidy up awaiter variable checks.

On 8/21/24 4:34 AM, Iain Sandoe wrote: Tested on x86_64-darwin, powerpc64le-linux, and against cppcoro and folly coroutines testsuites, OK for trunk? thanks Iain --- 8< --- When we build an await expression, we might need to materialise the awaiter if it is a prvalue. This re-implements this u

Re: [pushed] c++, coroutines: Check for malformed functions before splitting.

On 8/21/24 4:28 AM, Iain Sandoe wrote: tested on x86_64-darwin, powerpc64-linux and against cppcoro and folly coroutines tests, pushed to trunk as obvious, thanks, Iain --- 8< --- This performs the same basic check that is done by finish_function to catch cases where the function is so badly ma

Re: [PATCH 1/9] c++, coroutines: Split the ramp build into a separate function.

On 8/21/24 3:09 PM, Iain Sandoe wrote: This is primarily preparation to partition the functionality of the coroutine transform into analysis, ramp generation and then (later) synthesis of the coroutine body. The patch does fix one latent issue in the ordering of DTORs for frame parameter copies

Re: [PATCH 2/9] c++, coroutines: Separate the analysis, ramp and outlined function synthesis.

On 8/21/24 3:09 PM, Iain Sandoe wrote: This change is preparation for fixes to the ramp and codegen to follow. The primary motivation is that we have thee activities; analysis, ramp synthesis and outlined coroutine body synthesis. These are currently carried out in sequence in the 'morph_fn_to_

<    5   6   7   8   9   10   11   12   13   14   >