Re: [PATCH] c++: decltype of by-ref capture proxy of ref [PR115504]

On 6/25/24 11:45, Patrick Palka wrote: On Tue, 25 Jun 2024, Jason Merrill wrote: On 6/25/24 11:03, Patrick Palka wrote: On Mon, 24 Jun 2024, Jason Merrill wrote: On 6/24/24 21:00, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/14? -- &g

Re: [PATCH][c++ frontend]: check for missing condition for novector [PR115623]

On 6/25/24 12:52, Tamar Christina wrote: The 06/25/2024 17:10, Jason Merrill wrote: On 6/25/24 04:01, Tamar Christina wrote: Hi All, It looks like I forgot to check in the C++ frontend if a condition exist for the loop being adorned with novector. This causes a segfault because cond isn't

Re: [PATCH] c++: ICE with __has_unique_object_representations [PR115476]

On 6/25/24 15:07, Marek Polacek wrote: On Tue, Jun 25, 2024 at 06:22:56PM +0100, Jonathan Wakely wrote: On Tue, 25 Jun 2024 at 16:17, Jason Merrill wrote: On 6/25/24 07:15, Jonathan Wakely wrote: On Tue, 25 Jun 2024 at 03:12, Jason Merrill wrote: On 6/18/24 10:31, Marek Polacek wrote

Re: [PATCH][c++ frontend]: check for missing condition for novector [PR115623]

On 6/25/24 04:01, Tamar Christina wrote: Hi All, It looks like I forgot to check in the C++ frontend if a condition exist for the loop being adorned with novector. This causes a segfault because cond isn't expected to be null. This fixes it by issuing the same kind of diagnostics we issue for

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

On 6/13/24 13:00, Patrick Palka wrote: On Thu, 13 Jun 2024, Jason Merrill wrote: On 6/13/24 11:05, Patrick Palka wrote: On Thu, 23 May 2024, Jason Merrill wrote: 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

Re: [PATCH] c++: decltype of by-ref capture proxy of ref [PR115504]

On 6/25/24 11:03, Patrick Palka wrote: On Mon, 24 Jun 2024, Jason Merrill wrote: On 6/24/24 21:00, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/14? -- >8 -- The capture proxy handling in finish_decltype_type added in r14-5

Re: [PATCH] c++: ICE with __has_unique_object_representations [PR115476]

On 6/25/24 07:15, Jonathan Wakely wrote: On Tue, 25 Jun 2024 at 03:12, Jason Merrill wrote: On 6/18/24 10:31, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14/13? Makes sense to me, though probably the [meta.unary.prop] table should be adjusted

Re: [PATCH] c++: ICE with generic lambda and pack expansion [PR115425]

On 6/17/24 14:17, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? OK. -- >8 -- In r13-272 we hardened the *_PACK_EXPANSION and *_ARGUMENT_PACK macros. That trips up here because make_pack_expansion returns error_mark_node and we access that with

Re: [PATCH] c++: ICE with __has_unique_object_representations [PR115476]

On 6/18/24 10:31, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14/13? Makes sense to me, though probably the [meta.unary.prop] table should be adjusted in the same way. Jonathan, what do you think? -- >8 -- Here we started to ICE with r13-25: in

Re: [PATCH] c++: ICE with __dynamic_cast redecl [PR115501]

On 6/18/24 10:58, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? OK. -- >8 -- Since r13-3299, build_dynamic_cast_1 calls pushdecl which calls duplicate_decls and that in this testcase emits the "conflicting declaration" error and returns error_mark_node, so

Re: [PATCH] c++: decltype of by-ref capture proxy of ref [PR115504]

On 6/24/24 21:00, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/14? -- >8 -- The capture proxy handling in finish_decltype_type added in r14-5330 was stripping the reference type of a capture proxy's captured variable, which is desirable

Re: [PATCH] c++: using non-dep array variable of unknown bound [PR115358]

On 6/24/24 21:00, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? This fixes PR115358 whose testcase used a constexpr static array variable, but it seems the general issue is not specific to constexpr as illustrated by the below testcase.

[pushed] c++/modules: export using across namespace [PR114683]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Currently we represent a non-function using-declaration by inserting the named declaration into the target scope. In general this works fine, but in the case of an exported using-declaration we have nowhere to mark the using-declaration as

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

On 6/13/24 10:31, 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. PR preprocessor/89808 gcc/c-family/ChangeLog: * c.opt (Wpragma_once_outside_header):

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

On 6/13/24 11:05, Patrick Palka wrote: On Thu, 23 May 2024, Jason Merrill wrote: 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? -- &g

Re: [pushed] c++: module std and exception_ptr

On 6/13/24 11:16, Patrick Palka wrote: On Wed, 12 Jun 2024, Jason Merrill wrote: exception_ptr.h contains namespace __exception_ptr { class exception_ptr; } using __exception_ptr::exception_ptr; so when module std tries to 'export using std::exception_ptr', it names another

[pushed] c++/modules: multiple usings of the same decl [PR115194]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- add_binding_entity creates an OVERLOAD to represent a using-declaration in module purview of a declaration in the global module, even for non-functions, and we were failing to merge that with the original declaration in name lookup. It's

Re: [PATCH 1/3] Remove const char * support for asm constexpr

On 6/12/24 13:20, Andi Kleen wrote: asm constexpr now only accepts the same string types as C++26 assert, e.g. string_view and string. Adjust test suite and documentation. This patchset is all OK, thanks. gcc/cp/ChangeLog: * parser.cc (cp_parser_asm_string_expression): Remove

Re: [PATCH] c++: ICE w/ ambig and non-strictly-viable cands [PR115239]

On 6/12/24 13:56, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/14? -- >8 -- Here during overload resolution we have two strictly viable ambiguous candidates #1 and #2, and two non-strictly viable candidates #3 and #4 which we hold on to

Re: [PATCH] c++: undeclared identifier in requires-clause [PR99678]

On 6/12/24 14:22, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/14? OK. -- >8 -- Since the terms of a requires-clause are grammatically primary-expressions rather than e.g. postfix-expressions, it seems we need to explicitly handle and

[pushed] c++: repeated export using

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- A sample implementation of module std was breaking because the exports included 'using std::operator&' twice. Since Nathaniel's r15-964 for PR114867, the first using added an extra instance of each function that was revealed/exported by

[pushed] c++: module std and exception_ptr

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- exception_ptr.h contains namespace __exception_ptr { class exception_ptr; } using __exception_ptr::exception_ptr; so when module std tries to 'export using std::exception_ptr', it names another using-directive rather than the

[pushed] c++: fix testcase diagnostics

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- The r15-1180 adjustments to this testcase broke a couple of tests in C++26 mode. gcc/testsuite/ChangeLog: * g++.dg/cpp26/static_assert1.C: Fix diagnostic typos. --- gcc/testsuite/g++.dg/cpp26/static_assert1.C | 4 ++-- 1 file

Re: [PATCH] c++: visibility wrt concept-id as targ [PR115283]

On 6/12/24 14:49, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? OK for trunk and 14, I'd say. -- >8 -- It seems we don't maintain visibility flags for concepts either, so min_vis_expr_r should ignore them for now, otherwise after

Re: [PATCH] Move cexpr_stree tree string build into utility function

On 6/12/24 10:02, Andi Kleen wrote: No semantics changes. gcc/cp/ChangeLog: * cp-tree.h (extract): Add new overload to return tree. * parser.cc (cp_parser_asm_string_expression): Use tree extract. * semantics.cc (cexpr_str::extract): Add new overload to return

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

On 6/11/24 23:53, Andi Kleen wrote: Sorry I must have misunderstood you. I thought the patch was already approved earlier and I did commit. I can revert or do additional changes. I only meant to approve the refactoring patch, but no worries. On Tue, Jun 11, 2024 at 04:31:30PM -0400, Jason

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

On 6/5/24 00: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

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

On 6/5/24 00:45, Andi Kleen wrote: The only semantics changes are slightly more vague error messages to generalize. Just a few nits: +/* Extracting strings from constexpr. */ + +class cexpr_str +{ +public: + cexpr_str (tree message) : message(message) {} Space before paren. ... +/* Get

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

different 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

Re: [PATCH] c++: remove Concepts TS code

On 6/10/24 11:13, Marek Polacek wrote: On Mon, Jun 10, 2024 at 10:22:11AM -0400, Patrick Palka wrote: On Fri, 7 Jun 2024, Marek Polacek wrote: @@ -3940,9 +3936,6 @@ find_parameter_packs_r (tree *tp, int *walk_subtrees, void* data) parameter pack (14.6.3), or the type-specifier-seq of

[pushed] c++: -include and header unit translation

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Within a source file, #include is translated to import if a suitable header unit is available, but this wasn't working with -include. This turned out to be because we suppressed the translation before the beginning of the main file.

Re: [PATCH] c++: Make *_cast<*> parsing more robust to errors [PR108438]

On 6/7/24 08:12, Simon Martin wrote: We ICE upon the following when trying to emit a -Wlogical-not-parentheses warning: === cut here === template T foo (T arg, T& ref, T* ptr) { int a = 1; return static_cast(a); } === cut here === This patch makes *_cast<*> parsing more robust by

Re: [PATCH] c++: Handle erroneous DECL_LOCAL_DECL_ALIAS in duplicate_decls [PR107575]

On 6/5/24 05:20, Simon Martin wrote: On 5 Jun 2024, at 10:34, Jakub Jelinek wrote: On Wed, Jun 05, 2024 at 08:13:14AM +, Simon Martin wrote: --- a/gcc/cp/decl.cc +++ b/gcc/cp/decl.cc @@ -2792,10 +2792,13 @@ duplicate_decls (tree newdecl, tree olddecl, bool hiding, bool was_hidden)

Re: [PATCH] c++: lambda in pack expansion [PR115378]

On 6/7/24 10:44, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/14? OK. -- >8 -- Here find_parameter_packs_r is incorrectly treating the 'auto' return type of a lambda as a parameter pack due to Concepts-TS specific logic added in

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

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

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 int id

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] c-family: Introduce the -Winvalid-noreturn flag from clang with extra tuneability

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 functions

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 see any

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

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:

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

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] 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] 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] 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) { } === cut here

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 understanding

[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.

[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

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

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

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] 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

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

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

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] 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

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++: 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

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 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 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][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

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/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

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 CTAD gu

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

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

[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

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

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

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 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 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

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 FSF, so

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.

[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

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

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/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? Alternatively, I considered fixing this by incrementing comparing_specializations around

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

On 5/21/24 15:36, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? Alternatively, I considered fixing this by incrementing comparing_specializations around the call to comp_except_specs in cp_check_qualified_type, but generally for types whose

Re: [PATCH] c++: folding non-dep enumerator from current inst [PR115139]

On 5/17/24 12:05, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/14? OK for both. -- >8 -- After the tsubst_copy removal r14-4796-g3e3d73ed5e85e7 GCC 14 ICEs during fold_non_dependent_expr for 'e1 | e2' ultimately because we no longer

Re: [PATCH] testsuite: Allow for non-SECTION_MERGE systems in gcc.dg/pr115066.c [PR115066]

On 5/21/24 07:36, Rainer Orth wrote: gcc.dg/pr115066.c currently FAILs on Solaris/SPARC with the native as: FAIL: gcc.dg/pr115066.c scan-assembler .bytet0xbt# Define macro strx Instead of the expected .byte 0xb ! Define macro strx the assembler output contains

Re: [PATCH v5 2/5] C++: Support clang compatible [[musttail]] (PR83324)

On 5/14/24 19:23, Andi Kleen wrote: You need a template testcase; I expect it doesn't work in templates with the current patch. It's probably enough to copy it in tsubst_expr where we currently propagate CALL_EXPR_OPERATOR_SYNTAX. I tried it with the appended test case, everything seems to

Re: [PATCH v2] c++: Strengthen checks on 'main'

On 5/17/24 02:47, Nathaniel Shead wrote: On Tue, May 14, 2024 at 06:25:29PM -0400, Jason Merrill wrote: On 5/11/24 08:32, Nathaniel Shead wrote: I wasn't entirely sure what to do with the 'abi/main.C' testcase here; is this OK, or should I e.g. lower the linkage error to a pedwarn

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

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-linux-gnu, OK for trunk? OK. I realised as I was looking over this again that I might have spoken too

Re: [PATCH] c++: paren aggr CTAD with base classes [PR115114]

On 5/16/24 11:32, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps 14? OK for both. -- >8 -- We're accidentally ignoring base classes during parenthesized aggregate CTAD because the TYPE_FIELDS of a template type doesn't contain

Re: [PATCH] c++: represent all class non-dep assignments as CALL_EXPR

On 5/15/24 13:55, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linu-xgnu, does this look OK for trunk? OK. -- >8 -- Non-dependent compound assignment expressions are currently represented as CALL_EXPR to the selected operator@= overload. Non-dependent simple assignments on

Re: [PATCH] c++: lvalueness of non-dependent assignment [PR114994]

On 5/11/24 20:46, Patrick Palka wrote: On Fri, 10 May 2024, Jason Merrill wrote: On 5/9/24 16:23, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/14? For trunk as a follow-up I can implement the mentionted representation change to use

Re: [PATCH] c++: Strengthen checks on 'main'

On 5/11/24 08:32, Nathaniel Shead wrote: I wasn't entirely sure what to do with the 'abi/main.C' testcase here; is this OK, or should I e.g. lower the linkage error to a pedwarn for the purposes of this test? I think it should be a pedwarn anyway, since it's harmless. The others can still be

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

On 5/12/24 22:58, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? OK. -- >8 -- This appears to be an oversight in the definition of module_has_cmi_p; this comes up transitively in other functions used for e.g. determining whether a name could

Re: [PATCH] c++: Optimize in maybe_clone_body aliases even when not at_eof [PR113208]

On 5/13/24 06:19, Jakub Jelinek wrote: On Fri, May 10, 2024 at 03:59:25PM -0400, Jason Merrill wrote: 2024-05-09 Jakub Jelinek Jason Merrill PR lto/113208 * cp-tree.h (maybe_optimize_cdtor): Remove. * decl2.cc (tentative_decl_linkage): Call

Re: [PATCH] testsuite: c++: Allow for std::printf in g++.dg/modules/stdio-1_a.H [PR98529]

On 5/13/24 08:10, Rainer Orth wrote: Hi Nathaniel, There are a couple of other tests that appear to potentially have a similar issue: global-2_a.C 21:// { dg-final { scan-lang-dump-not {Reachable GMF '::printf[^\n']*' added} module } } global-3_a.C 15:// { dg-final { scan-lang-dump-not

Re: [PATCH v2] c++: ICE with reference NSDMI [PR114854]

On 5/14/24 09:48, Marek Polacek wrote: On Thu, May 09, 2024 at 03:47:54PM -0400, Jason Merrill wrote: On 5/9/24 12:04, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Here we crash on a cp_gimplify_expr/TARGET_EXPR assert: /* A TARGET_E

Re: [PATCH v2] c++: DR 569, DR 1693: fun with semicolons [PR113760]

On 5/14/24 12:55, Marek Polacek wrote: On Thu, May 09, 2024 at 12:44:52PM -0400, Jason Merrill wrote: On 5/9/24 12:16, Marek Polacek wrote: +static void +maybe_warn_extra_semi (location_t loc, extra_semi_kind kind) +{ + /* -Wno-extra-semi suppresses all. */ + if (warn_extra_semi == 0

Re: [PATCH v5 2/5] C++: Support clang compatible [[musttail]] (PR83324)

On 5/14/24 13:24, Andi Kleen wrote: Hi Jason, On Mon, May 06, 2024 at 11:02:20PM -0400, Jason Merrill wrote: @@ -30189,7 +30207,7 @@ cp_parser_std_attribute (cp_parser *parser, tree attr_ns) /* Maybe we don't expect to see any arguments for this attribute. */ const

Re: [PATCH] c++: add test for DR 2855

On 5/14/24 13:54, Marek Polacek wrote: Tested x86_64-pc-linux-gnu, OK to add such a test? OK. -- >8 -- Let int8_t x = 127; This DR says that while x++; invokes UB, ++x; does not. The resolution was to make the first one valid. The following test verifies that we don't report

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

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 should also apply to implicitly-generated functi

Re: [PATCH v25 20/23] c++: Implement __is_invocable built-in trait

On 5/10/24 12:14, Ken Matsui wrote: Removed the redundant check and fixed the flow. Could you please review this again? Looks good! All the compiler trait patches are OK. -- >8 -- This patch implements built-in trait for std::is_invocable. gcc/cp/ChangeLog: * cp-trait.def:

  1   2   3   4   5   6   7   8   9   10   >