Re: [PATCH] c++: Mostly concepts related formatting fixes

On 7/24/24 1:33 PM, Jakub Jelinek wrote: Hi! When playing with P2963R3, while reading and/or modifying code I've fixed various comment or code formatting issues (and in 3 spots also comment wording), but including that in the WIP P2963R3 patch made that patch totally unreadable because these cha

Re: [PATCH 1/2] cp/coroutines: do not rewrite parameters in unevaluated contexts

On 7/23/24 7:41 PM, Arsen Arsenović wrote: It is possible to use parameters of a parent function of a lambda in unevaluated contexts without capturing them. By not capturing them, we work around the usual mechanism we use to prevent rewriting captured parameters. Prevent this by simply skipping

Re: [PATCH 2/2] cp+coroutines: teach convert_to_void to diagnose discarded co_awaits

On 7/23/24 7:41 PM, Arsen Arsenović wrote: co_await expressions are nearly calls to Awaitable::await_resume, and, as such, should inherit its nodiscard. A discarded co_await expression should, hence, act as if its call to await_resume was discarded. CO_AWAIT_EXPR trees do conveniently contain t

Re: [PATCH 2/2] cp+coroutines: teach convert_to_void to diagnose discarded co_awaits

On 7/24/24 4:20 PM, Arsen Arsenović wrote: Hi Jason, Thanks for the review. Jason Merrill writes: On 7/23/24 7:41 PM, Arsen Arsenović wrote: co_await expressions are nearly calls to Awaitable::await_resume, and, as such, should inherit its nodiscard. A discarded co_await expression should

[pushed] c++: parse error with -std=c++14 -fconcepts [PR116071]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- cp_parser_simple_type_specifier tries a variety of different things that might qualify as a user-defined type: an actual type-name, a constrained auto, a CTAD placeholder. In a context where a type-specifier is optional, this is all tentati

Re: [PATCH 2/2] cp+coroutines: teach convert_to_void to diagnose discarded co_awaits

On 7/24/24 4:52 PM, Arsen Arsenović wrote: Jason Merrill writes: Ah, of course, I was overlooking the assignment. The patch is OK. Thanks. Here's a range diff with a few changes to the commits, chiefly in the commit messages. If you agree, I can push with these changes applied:

Re: [PATCH] c++: Implement C++26 P2558R2 - Add @, $, and ` to the basic character set [PR110343]

On 7/17/24 6:04 PM, Jakub Jelinek wrote: Hi! The following patch implements the easy parts of the paper. When @$` are added to the basic character set, it means that R"@$`()@$`" should now be valid (here I've noticed most of the raw string tests were tested solely with -std=c++11 or -std=gnu++11

Re: [PATCH] c++: structured bindings and lookup of tuple_size/tuple_element [PR115605]

On 6/25/24 1:00 AM, Andrew Pinski wrote: The problem here is even though we pass std namespace to lookup_template_class as the context, it will look at the current scope for the name too. The fix is to lookup the qualified name first and then use that for lookup_template_class. If lookup_templa

Re: [PATCH] c++: alias of alias tmpl with dependent attrs [PR115897]

On 7/25/24 2:17 PM, Patrick Palka wrote: On Mon, 22 Jul 2024, Jason Merrill wrote: On 7/19/24 10:30 AM, Patrick Palka wrote: On Thu, 18 Jul 2024, Jason Merrill wrote: On 7/18/24 12:45 PM, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does thi look OK for trunk/14

[pushed] c++: #pragma target and deferred instantiation [PR115403]

Tested x86_64-pc-linux-gnu, applying to trunk. Also built highway to check. -- 8< -- My patch for 109753 applies the current #pragma target/optimize to a function when we compile it, which was a problem for a template instantiation deferred until EOF, where different #pragmas are active. So let

Re: [PATCH] c++: Implement C++26 P2558R2 - Add @, $, and ` to the basic character set [PR110343]

On 7/17/24 6:04 PM, Jakub Jelinek wrote: Hi! The following patch implements the easy parts of the paper. When @$` are added to the basic character set, it means that R"@$`()@$`" should now be valid (here I've noticed most of the raw string tests were tested solely with -std=c++11 or -std=gnu++11

Re: [PATCH] c++/modules: Ensure deduction guides are always reachable [PR115231]

On 7/26/24 12:52 AM, Nathaniel Shead wrote: On Tue, Jul 23, 2024 at 04:17:22PM -0400, Jason Merrill wrote: On 6/15/24 10:29 PM, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? This probably isn't the most efficient approach, since we need to do

Re: [PATCH] c++: Implement C++26 P2558R2 - Add @, $, and ` to the basic character set [PR110343]

On 7/26/24 11:55 AM, Jakub Jelinek wrote: On Fri, Jul 26, 2024 at 11:43:13AM -0400, Jason Merrill wrote: I'm now seeing a -std=c++26 failure on g++.dg/cpp/ucn-1.C. I don't remember seeing it when I wrote the patch, but today I see it as well. The following patch seems to fix that,

[pushed] c++: trait as typename scope [PR116052]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- The stdexec library currently wrongly ends up using __decay as the scope of a typename, which leads to a crash. Let's give an error instead. PR c++/116052 gcc/cp/ChangeLog: * mangle.cc (write_prefix): Handle TRAIT_EXPR.

[pushed] c++: improve C++ testsuite default versions

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- I wanted to add more cases to the setting of std_list in g++-dg.exp, but didn't want to do a full scan through the file for each case. So this patch improves that in two ways: first, by extracting all interesting lines on a single pass; sec

[pushed] c++: ICE with concept, local class, and lambda [PR115561]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Here when we want to synthesize methods for foo()::B maybe_push_to_top_level calls push_function_context, which sets cfun to a dummy value; later finish_call_expr tries to set something in cp_function_chain (i.e. cfun->language), which isn't

[pushed] c++: consteval propagation and templates [PR115986]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Here the call to e() makes us decide to check d() for escalation at EOF, but while checking it we try to fold_immediate 0_c, and get confused by the template trees. Let's not mess with escalation for function templates. PR c++/1159

[pushed] c++: if consteval and consteval propagation [PR115583]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- During speculative constant folding of an if consteval, we take the false branch, but the true branch is an immediate function context, so we don't want to to cp_fold_immediate it. So we could check IF_STMT_CONSTEVAL_P here. But beyond tha

Re: [PATCH] c++: generic lambda as default template argument [PR88313]

On 7/29/24 11:38 AM, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps 14.3? It should only make a differenc for C++20 code where lambdas are permitted as template arguments. OK for both. -- >8 -- Here we're rejecting the generic

Re: [PATCH] c++: make BUILTIN_SOURCE_LOCATION follow DECL_RAMP_FN

I don't know what all-caps BUILTIN_SOURCE_LOCATION refers to specifically (it doesn't match CP_BUILT_IN_SOURCE_LOCATION, for instance); let's just refer to source_location. On 7/29/24 8:20 AM, Arsen Arsenović wrote: This fixes the value of current_function in compiler generated coroutine code.

Re: [PATCH 1/2] c++: fix ICE on FUNCTION_DECLs inside coroutines [PR115906]

On 7/29/24 8:18 AM, Arsen Arsenović wrote: When register_local_var_uses iterates a BIND_EXPRs BIND_EXPR_VARS, it fails to account for the fact that FUNCTION_DECLs might be present, and later passes it to DECL_HAS_VALUE_EXPR_P. This leads to a tree check failure in DECL_HAS_VALUE_EXPR_P: tree

Re: [PATCH 2/2] c++: diagnose usage of co_await and co_yield in default args [PR115906]

On 7/29/24 8:18 AM, Arsen Arsenović wrote: This is a partial fix for PR115906. Per [expr.await] 2s3, "An await-expression shall not appear in a default argument ([dcl.fct.default])". This patch introduces the diagnostic in that case, and in the case of a co_yield (as co_yield is defined in term

Re: [PATCH] c++: array new with value-initialization, again [PR115645]

On 7/29/24 4:18 PM, Marek Polacek wrote: On Tue, Jul 23, 2024 at 05:18:52PM -0400, Jason Merrill wrote: On 7/17/24 5:33 PM, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? Hmm, I thought I had replied to this already. -- >8 -- Unfortunately, my r15-1

Re: [PATCH v2] c++: array new with value-initialization, again [PR115645]

On 7/30/24 4:59 PM, Marek Polacek wrote: On Mon, Jul 29, 2024 at 06:34:40PM -0400, Jason Merrill wrote: On 7/29/24 4:18 PM, Marek Polacek wrote: On Tue, Jul 23, 2024 at 05:18:52PM -0400, Jason Merrill wrote: On 7/17/24 5:33 PM, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux

Re: [PATCH v3] c++: array new with value-initialization, again [PR115645]

On 7/30/24 5:56 PM, Marek Polacek wrote: On Tue, Jul 30, 2024 at 05:38:37PM -0400, Jason Merrill wrote: On 7/30/24 4:59 PM, Marek Polacek wrote: On Mon, Jul 29, 2024 at 06:34:40PM -0400, Jason Merrill wrote: On 7/29/24 4:18 PM, Marek Polacek wrote: On Tue, Jul 23, 2024 at 05:18:52PM -0400

Re: [RFH PATCH] c++: Implement C++26 P2963R3 - Ordering of constraints involving fold expressions [PR115746]

On 7/29/24 5:32 PM, Patrick Palka wrote: On Mon, 29 Jul 2024, Jakub Jelinek wrote: On Fri, Jul 26, 2024 at 06:00:12PM -0400, Patrick Palka wrote: On Fri, 26 Jul 2024, Jakub Jelinek wrote: On Fri, Jul 26, 2024 at 04:42:36PM -0400, Patrick Palka wrote: // P2963R3 - Ordering of constraints inv

Re: [PATCH] c++/coroutines: only defer expanding co_{await,return,yield} if dependent [PR112341]

On 7/31/24 6:54 AM, Arsen Arsenović wrote: Tested on x86_64-pc-linux-gnu. OK for trunk? TIA, have a lovely day. -- >8 -- By doing so, we can get diagnostics in template decls when we know we can. For instance, in the following: awaitable g(); template task f() {

Re: [PATCH v2] c++/coroutines: only defer expanding co_{await,return,yield} if dependent [PR112341]

On 7/31/24 3:56 PM, Arsen Arsenović wrote: Okay, I've reworked it, and it built and passed coroutine tests. Regstrapping overnight. Is the following OK with you? OK. -- >8 -- By doing so, we can get diagnostics in template decls when we know we can. For instance, in the foll

Re: [PATCH] c++: Fix up error recovery of invalid structured bindings used in conditions [PR116113]

On 7/29/24 3:42 AM, Jakub Jelinek wrote: Hi! The following testcase ICEs, because for structured binding error recovery DECL_DECOMP_BASE is kept NULL and the newly added code to pick up saved value from the base assumes that on structured binding bases the TARGET_EXPR will be always there (that

Re: [PATCH] c++/coroutines: fix actor cases not being added to the current switch [PR109867]

On 8/1/24 12:48 PM, Arsen Arsenović wrote: Tested on x86_64-pc-linux-gnu, no regression. OK for trunk? TIA, have a lovely day. -- >8 -- Previously, we were building and inserting case_labels manually, which lead to them not being added into the currently running switch via "le

Re: [PATCH] c++/coroutines: check for members we use in handle_types [PR105475]

On 8/1/24 12:34 PM, Arsen Arsenović wrote: Tested on x86_64-pc-linux-gnu. OK for trunk? TIA, have a lovely day. -- >8 -- Currently, it is possible to ICE GCC by giving it sufficiently broken code, where sufficiently broken means a std::coroutine_handle missing a default on the p

Re: [PATCH] c++: Move -Wdangling-reference to -Wextra

On 8/1/24 4:20 PM, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Despite a number of mitigations (don't warn for std::span-like classes, lambdas, adding [[gnu::no_dangling]], etc.), the warning still seems to cause some grief. Let's move the warning

Re: [PATCH] c++: DR882, main cannot be deleted [PR116169]

On 8/1/24 4:20 PM, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? OK. -- >8 -- This DR clarifies that "int main() = delete;" is ill-formed. PR c++/116169 gcc/cp/ChangeLog: * decl.cc (cp_finish_decl): Disallow deleting ::main. gcc/testsuit

Re: [PATCH] c++: fix -Wdangling-reference false positive [PR115987]

On 8/1/24 4:19 PM, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- This fixes another false positive. When a function is taking a temporary of scalar type that couldn't be bound to the return type of the function, don't warn, such a program would be il

Re: [PATCH] c++, coroutines: Simplify separation of the user function body and ramp.

On 8/2/24 6:50 AM, Iain Sandoe wrote: This fixes a (so far unreported) bug where we would handle noexcept ramps correctly, but omit exception specs - take this opportunity to simplify. Tested on x86_64-darwin, OK for trunk? thanks Iain --- 8< --- We need to separate the original user-authored f

Re: [PATCH] c++: permit errors inside uninstantiated templates [PR116064]

On 8/1/24 2:52 PM, Patrick Palka wrote: In recent versions of GCC we've been diagnosing more and more kinds of errors inside a template ahead of time. This is a largely good thing because it catches bugs, typos, dead code etc sooner. But if the template never gets instantiated then such errors

Re: [PATCH v2] c++/coroutines: check for members we use in handle_types [PR105475]

On 8/2/24 10:50 AM, Arsen Arsenović wrote: Jason Merrill writes: I don't think these names need to mention "baselink", but I'm not strongly against it. It doesn't fit with the rest of the codebase either, so I'll rename them. A few other tweaks below:

Re: [PATCH] c++: Add unsequenced C++ testcase

On 8/1/24 2:43 PM, Jakub Jelinek wrote: Hi! This is the testcase I wrote originally and which on top of the https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659154.html patch didn't behave the way I wanted (no warning and no optimizations of [[unsequenced]] function templates which don't ha

Re: [PATCH v2] c++, coroutines: Simplify separation of the user function body and ramp.

On 8/3/24 11:40 AM, Iain Sandoe wrote: On 2 Aug 2024, at 15:19, Jason Merrill wrote: On 8/2/24 6:50 AM, Iain Sandoe wrote: This version simplifies the process by extrating the second case directly typo thanks, fixed. +static bool +use_eh_spec_block (tree fn) +{ + return

Re: [PATCH] c++: permit errors inside uninstantiated templates [PR116064]

On 8/2/24 4:18 PM, Patrick Palka wrote: On Fri, 2 Aug 2024, Patrick Palka wrote: On Fri, 2 Aug 2024, Jason Merrill wrote: On 8/1/24 2:52 PM, Patrick Palka wrote: In recent versions of GCC we've been diagnosing more and more kinds of errors inside a template ahead of time. This is a la

Re: [PATCH v2] c++: fix -Wdangling-reference false positive [PR115987]

On 8/2/24 3:22 PM, Marek Polacek wrote: On Thu, Aug 01, 2024 at 05:20:43PM -0400, Jason Merrill wrote: On 8/1/24 4:19 PM, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- This fixes another false positive. When a function is taking a temporary

Re: [PATCH] c++: remove function/var concepts code

On 8/2/24 2:12 PM, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu. Comments? -- >8 -- This patch removes vestigial Concepts TS code as discussed in . In particular, it removes code related to function/variable

Re: [PATCH] c++: permit errors inside uninstantiated templates [PR116064]

On 8/5/24 1:14 PM, Patrick Palka wrote: On Mon, 5 Aug 2024, Jason Merrill wrote: On 8/2/24 4:18 PM, Patrick Palka wrote: On Fri, 2 Aug 2024, Patrick Palka wrote: On Fri, 2 Aug 2024, Jason Merrill wrote: On 8/1/24 2:52 PM, Patrick Palka wrote: In recent versions of GCC we've

Re: [PATCH] Explicitly document that the "counted_by" attribute is only supported in C

On 8/5/24 9:53 AM, Jakub Jelinek wrote: On Mon, Aug 05, 2024 at 01:33:01PM +, Qing Zhao wrote: As discussed in PR116016:https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016#c48 We should explicitly document this limitation and issue error messages for C++. The "counted_by" attribute current

Re: [PATCH] c++: remove function/var concepts code

On 8/5/24 2:44 PM, Marek Polacek wrote: On Mon, Aug 05, 2024 at 12:00:04PM -0400, Jason Merrill wrote: I think we also want to adjust the 'concept bool' handling in cp_parser_decl_specifier_seq: /* Warn for concept as a decl-specifier. We'll rewrite these as conce

Re: [PATCH] c++: remove function/var concepts code

On 8/5/24 4:00 PM, Marek Polacek wrote: On Mon, Aug 05, 2024 at 02:52:32PM -0400, Jason Merrill wrote: On 8/5/24 2:44 PM, Marek Polacek wrote: On Mon, Aug 05, 2024 at 12:00:04PM -0400, Jason Merrill wrote: I think we also want to adjust the 'concept bool' h

Re: [PATCH] c++: permit errors inside uninstantiated templates [PR116064]

On 8/5/24 3:47 PM, Patrick Palka wrote: On Mon, 5 Aug 2024, Jason Merrill wrote: On 8/5/24 1:14 PM, Patrick Palka wrote: On Mon, 5 Aug 2024, Jason Merrill wrote: On 8/2/24 4:18 PM, Patrick Palka wrote: On Fri, 2 Aug 2024, Patrick Palka wrote: On Fri, 2 Aug 2024, Jason Merrill wrote: On

Re: [PATCH] c++: fold calls to std::forward_like [PR96780]

On 8/6/24 10:01 AM, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? I might add it after std::forward instead of at the bottom? OK either way. -- >8 -- This extends our folding of cast-like standard library functions to also include C++2

[pushed] c++: zero-init and class nttp [PR94568]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- A zero-initializer should not reflect the constness of what it's initializing, as it does not for initializers with different syntax. This does have mangling implications for rare C++20 code, but it seems infeasable to make the mangling dep

[PATCH 1/2] c++: alias and non-type template parm [PR116223]

Tested x86_64-pc-linux-gnu, applying to trunk and 14. -- 8< -- My r14-8291 for PR112632 introduced IMPLICIT_CONV_EXPR_FORCED to express conversions to the type of an alias template parameter. In this example, that broke deduction of X in the call to foo, so let's teach deduction to look through

[PATCH 2/2] c++: more non-type template parms [PR116223]

Tested x86_64-pc-linux-gnu, applying to trunk (not 14). -- 8< -- Building on the last patch, deduction should probably look through all IMPLICIT_CONV_EXPR like we do other conversions. One resulting regression turned out to be due to PR94568, fixed separately. The one other regression was for a

Re: [PATCH] c++: further concept_check_p clean-up

On 8/6/24 12:09 PM, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? OK. -- >8 -- Patrick noticed a few more concept_check_p checks that can be removed now. gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_call_expression): Remove concept_check_p check.

Re: [PATCH] c++: Improve fixits for incorrect explicit instantiations

On 8/6/24 5:55 AM, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? OK. -- >8 -- When forgetting the '<>' on an explicit specialisation, the suggested fixit hint suggests to add 'template <>', but naively applying will cause nonsense results like 'templ

Re: [PATCH] c++: permit errors inside uninstantiated templates [PR116064]

On 8/5/24 6:09 PM, Patrick Palka wrote: On Mon, 5 Aug 2024, Jason Merrill wrote: On 8/5/24 3:47 PM, Patrick Palka wrote: On Mon, 5 Aug 2024, Jason Merrill wrote: On 8/5/24 1:14 PM, Patrick Palka wrote: On Mon, 5 Aug 2024, Jason Merrill wrote: On 8/2/24 4:18 PM, Patrick Palka wrote: On

Re: [PATCH] c++: permit errors inside uninstantiated templates [PR116064]

On 8/6/24 2:00 PM, Patrick Palka wrote: On Tue, 6 Aug 2024, Jason Merrill wrote: On 8/5/24 6:09 PM, Patrick Palka wrote: On Mon, 5 Aug 2024, Jason Merrill wrote: On 8/5/24 3:47 PM, Patrick Palka wrote: On Mon, 5 Aug 2024, Jason Merrill wrote: On 8/5/24 1:14 PM, Patrick Palka wrote: On

Re: [PATCH v2] c++/modules: Ensure deduction guides are always reachable [PR115231]

On 8/6/24 8:03 AM, Nathaniel Shead wrote: On Fri, Jul 26, 2024 at 01:17:57PM -0400, Jason Merrill wrote: On 7/26/24 12:52 AM, Nathaniel Shead wrote: On Tue, Jul 23, 2024 at 04:17:22PM -0400, Jason Merrill wrote: On 6/15/24 10:29 PM, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64

Re: [PATCH] c++: Fix up handling of dependent (late) attributes on function/method types [PR116175]

On 8/1/24 2:39 PM, Jakub Jelinek wrote: Hi! When working on unsequenced/reproducible attributes, I've noticed that on templates for some attributes decl_attributes isn't called at all, so they are kept in TYPE_ATTRIBUTES without any verification/transformations and also without argument substitu

Re: [PATCH] c++: permit errors inside uninstantiated templates [PR116064]

On 8/6/24 5:47 PM, Patrick Palka wrote: On Tue, 6 Aug 2024, Jason Merrill wrote: On 8/6/24 2:00 PM, Patrick Palka wrote: On Tue, 6 Aug 2024, Jason Merrill wrote: On 8/5/24 6:09 PM, Patrick Palka wrote: On Mon, 5 Aug 2024, Jason Merrill wrote: On 8/5/24 3:47 PM, Patrick Palka wrote: On

Re: [PATCH] c++: erroneous partial spec vs primary tmpl [PR116064]

On 8/7/24 11:09 AM, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? OK. -- >8 -- When a partial specialization is deemed erroneous at parse time, we currently flag the primary template as erroneous instead. Later at instantiation time we

Re: [PATCH] c++: Implement CWG2387 - Linkage of const-qualified variable template [PR109126]

On 8/7/24 10:40 AM, Jakub Jelinek wrote: Hi! The following patch attempts to implement DR2387 by making variable templates including their specialization TREE_PUBLIC when at file scope and they don't have static storage class. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

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

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 load it, either with a new LOOK_want::ANY_REACHABLE flag or by expanding on the lookup_imported_temploid_fri

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

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. -- >8 -- Currently name lookup generally seems to assume that all entities declared within a named module (partition) are attached t

Re: [PATCH] c++, libstdc++: Implement C++26 P2747R2 - constexpr placement new [PR115744]

On 7/3/24 10:37 AM, Jakub Jelinek wrote: Hi! With the PR115754 fix in, constexpr placement new mostly just works, so this patch just adds constexpr keyword to the placement new operators in , adds FTMs and testsuite coverage. There is one accepts-invalid though, the new (p + 1) int[]{2, 3};

Re: [PATCH] c++/modules: local class merging [PR99426]

On 4/12/24 10:35, Patrick Palka wrote: On Wed, 10 Apr 2024, Jason Merrill wrote: On 4/10/24 14:48, Patrick Palka wrote: On Tue, 9 Apr 2024, Jason Merrill wrote: On 3/5/24 10:31, Patrick Palka wrote: On Tue, 27 Feb 2024, Patrick Palka wrote: Subject: [PATCH] c++/modules: local type merging

Re: [PATCH] c++: templated substitution into lambda-expr, cont [PR114393]

On 4/12/24 09:47, Patrick Palka wrote: The original PR114393 testcase is unfortunately still not accepted after r14-9938-g081c1e93d56d35 due to return type deduction confusion when a lambda-expr is used as a default template argument. The below reduced testcase demonstrates the bug. Here, when

Re: [PATCH] c++: Diagnose or avoid constexpr dtors in classes with virtual bases [PR114426]

On 4/12/24 09:12, Jakub Jelinek wrote: Hi! I had another look at this P1 PR today. You said in the "c++: fix in-charge parm in constexpr" mail back in December (as well as in the r14-6507 commit message): "Since a class with vbases can't have constexpr 'tors there isn't actually a need for an in

Re: [PATCH 1/3] c++/modules: Only emit exported GMF usings [PR114600]

On 4/11/24 20:40, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? OK. -- >8 -- A typo in r14-6978 made us emit too many things. This ensures that we don't emit using-declarations from the GMF that we don't need to. PR c++/114600 gcc/cp/Change

Re: [PATCH 2/3] c++/modules: Propagate using decls from partitions

On 4/11/24 20:40, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? -- >8 -- The modules code currently neglects to set OVL_USING_P on the dependency created for a using-decl, which causes it not to remember that the OVL_EXPORT_P flag had been set on it whe

Re: [PATCH 3/3] c++/modules: Propagate hidden flag on decls from partitions

On 4/11/24 20:41, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? OK. -- >8 -- While working on some other fixes I noticed that the partition handling code used the wrong flag to propagate OVL_HIDDEN_P on exported bindings from partitions. This patch f

Re: [PATCH] c++/modules: local class merging [PR99426]

On 4/12/24 13:48, Patrick Palka wrote: On Fri, 12 Apr 2024, Jason Merrill wrote: On 4/12/24 10:35, Patrick Palka wrote: On Wed, 10 Apr 2024, Jason Merrill wrote: On 4/10/24 14:48, Patrick Palka wrote: On Tue, 9 Apr 2024, Jason Merrill wrote: On 3/5/24 10:31, Patrick Palka wrote: On Tue

Re: [PATCH] c++: Fix bogus warnings about ignored annotations [PR114409]

On 3/22/24 04:08, Jakub Jelinek wrote: Hi! The middle-end warns about the ANNOTATE_EXPR added for while/for loops if they declare a var inside of the loop condition. This is because the assumption is that ANNOTATE_EXPR argument is used immediately in a COND_EXPR (later GIMPLE_COND), but simplify

Re: [PATCH] c++: Fix constexpr evaluation of parameters passed by invisible reference [PR111284]

On 3/8/24 03:56, Jakub Jelinek wrote: Hi! My r9-6136 changes to make a copy of constexpr function bodies before genericization modifies it broke the constant evaluation of non-POD arguments passed by value. In the callers such arguments are passed as reference to usually a TARGET_EXPR, but on th

Re: [PATCH] c++/modules: local class merging [PR99426]

On 4/12/24 14:39, Patrick Palka wrote: On Fri, 12 Apr 2024, Jason Merrill wrote: On 4/12/24 13:48, Patrick Palka wrote: On Fri, 12 Apr 2024, Jason Merrill wrote: On 4/12/24 10:35, Patrick Palka wrote: On Wed, 10 Apr 2024, Jason Merrill wrote: On 4/10/24 14:48, Patrick Palka wrote: On

[pushed] c++: reference list-init, conversion fn [PR113141]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- The original testcase in PR113141 is an instance of CWG1996; the standard fails to consider conversion functions when initializing a reference directly from an initializer-list of one element, but then does consider them when initializing a

[pushed] c++: reference cast, conversion fn [PR113141]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- The second testcase in 113141 is a separate issue: we first decide that the conversion is ill-formed, but then when recalculating the special c_cast_p handling makes us think it's OK. We don't want that, it should continue to fall back to t

Re: [PATCH] c++: problematic assert in reference_binding [PR113141]

On 3/26/24 09:44, Patrick Palka wrote: On Thu, 7 Mar 2024, Jason Merrill wrote: On 1/29/24 17:42, Patrick Palka wrote: On Mon, 29 Jan 2024, Patrick Palka wrote: On Fri, 26 Jan 2024, Jason Merrill wrote: On 1/26/24 17:11, Jason Merrill wrote: On 1/26/24 16:52, Jason Merrill wrote: On 1

Re: [PATCH] c++/modules: Setup aliases imported from modules [PR106820]

On 3/26/24 09:24, Nathaniel Shead wrote: I wonder if more generally we need to be doing more work when importing definitions from header units especially to handle all the work that 'make_rtl_for_nonlocal_decl' and 'rest_of_decl_compilation' would have been performing. Can we just call those

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

On 3/14/24 17:26, Marek Polacek wrote: In the following patch, I'm taking a different tack. I believe we ought to use TARGET_EXPR_ELIDING_P. The gimplify_arg bit I'm talking about below is this: /* Also strip a TARGET_EXPR that would force an extra copy. */ if (TREE_CODE (*arg_

Re: [PATCH] c++: constexpr union member access folding [PR114709]

On 4/22/24 15:18, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/13/12? OK with a rationale comment. -- >8 -- The object/offset canonicalization performed in cxx_fold_indirect_ref is undesirable for union member accesses because it loses i

Re: [PATCH] c++: Copy over DECL_DISREGARD_INLINE_LIMITS flag to inheriting ctors [PR114784]

On 4/22/24 08:54, Jakub Jelinek wrote: Hi! The following testcase is rejected with error: inlining failed in call to 'always_inline' '...': call is unlikely and code size would grow errors. The problem is that starting with the r14-2149 change we try to copy most of the attributes from the inh

Re: [PATCH] c++, v2: Retry the aliasing of base/complete cdtor optimization at import_export_decl time [PR113208]

On 4/22/24 08:42, Jakub Jelinek wrote: On Wed, Apr 17, 2024 at 09:42:47AM +0200, Jakub Jelinek wrote: When expand_or_defer_fn is called at_eof time, it calls import_export_decl and then maybe_clone_body, which uses DECL_ONE_ONLY and comdat name in a couple of places to try to optimize cdtors whi

Re: [PATCH] c++: Check if allocation functions are xobj members [PR114078]

On 4/21/24 19:59, Patrick Palka wrote: On Sat, 20 Apr 2024, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? -- >8 -- A class allocation member function is implicitly 'static' by [class.free] p3, so cannot have an explicit object parameter. PR c

Re: [PATCH] c++: Fix ICE with xobj parms and maybe incomplete decl-specifiers

On 4/21/24 19:59, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? -- >8 -- This fixes a null dereference issue when decl_specifiers.type is not yet provided. gcc/cp/ChangeLog: * parser.cc (cp_parser_parameter_declaration): Check if decl_sp

Re: [PATCH] c++/modules: deduced return type merging [PR114795]

On 4/23/24 09:41, Patrick Palka wrote: Tested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- When merging an imported function template specialization with an existing one, if the existing one has an undeduced return type and the imported one's is already deduced, we need to prop

Re: [PATCH] c++/modules testsuite: avoid expensive ggc-min-expand=0

On 4/23/24 11:28, Patrick Palka wrote: Tested on x86_64-pc-linux-gnu, does this look OK for trunk? Is the test being run for multiple standard levels? I'd rather restrict it to one and keep fully testing GC-safety. -- >8 -- The below testcase uses --param=ggc-min-expand=0 which forces a f

Re: [PATCH] c++/modules testsuite: avoid expensive ggc-min-expand=0

On 4/24/24 05:49, Patrick Palka wrote: On Tue, 23 Apr 2024, Jason Merrill wrote: On 4/23/24 11:28, Patrick Palka wrote: Tested on x86_64-pc-linux-gnu, does this look OK for trunk? Is the test being run for multiple standard levels? I'd rather restrict it to one and keep fully testi

Re: [PATCH] c++: fix source printing for "required from here" message

On 4/24/24 13:22, Patrick Palka wrote: Tested on x86_64-pc-linux-gnu, full bootstrap+regtest in progress, does this look OK if successful? -- >8 -- It seems the diagnostic machinery's source line printing respects the pretty printer prefix, but this is undesirable for the call to diagnostic_sho

Re: [PATCH] c++, v3: Retry the aliasing of base/complete cdtor optimization at import_export_decl time [PR113208]

On 4/24/24 09:16, Jakub Jelinek wrote: On Wed, Apr 24, 2024 at 10:16:05AM +0100, Jonathan Wakely wrote: That fixes the testcases too, but seems to regress +FAIL: libstdc++-abi/abi_check There are explicit instantiation definitions that should instantiate those types: src/c++17/fs_dir.cc:temp

Re: [PATCH] c++, v3: Retry the aliasing of base/complete cdtor optimization at import_export_decl time [PR113208]

On 4/24/24 15:47, Jakub Jelinek wrote: On Wed, Apr 24, 2024 at 06:39:33PM -0400, Jason Merrill wrote: --- gcc/cp/decl2.cc.jj 2024-04-23 14:49:41.933186265 +0200 +++ gcc/cp/decl2.cc 2024-04-24 15:17:09.043625729 +0200 @@ -3314,7 +3314,16 @@ tentative_decl_linkage (tree decl) to

Re: [PATCH] c++, v4: Retry the aliasing of base/complete cdtor optimization at import_export_decl time [PR113208]

On 4/25/24 07:22, Jakub Jelinek wrote: On Thu, Apr 25, 2024 at 02:02:32PM +0200, Jakub Jelinek wrote: I've tried the following patch, but unfortunately that lead to large number of regressions: +FAIL: g++.dg/cpp0x/initlist25.C -std=c++17 (test for excess errors) So the reduced testcase for th

Re: [PATCH] c++, v2: Fix constexpr evaluation of parameters passed by invisible reference [PR111284]

On 4/23/24 08:52, Jakub Jelinek wrote: On Mon, Apr 15, 2024 at 02:19:36PM +0200, Jakub Jelinek wrote: They weren't the same, one was trying to evaluate the convert_from_reference with vc_glvalue, the other evaluates it without that and with vc_prvalue. Now, I guess the + /* Undo convert_for_

Re: [PATCH v2 1/2] c++: Standardise errors for module_may_redeclare

On 4/19/24 09:18, Nathaniel Shead wrote: On Mon, Apr 15, 2024 at 02:49:35PM +1000, Nathaniel Shead wrote: I took another look at this patch and have split it into two, one (this one) to standardise the error messages used and prepare 'module_may_redeclare' for use with temploid friends, and anot

Re: [PATCH v3 2/2] c++: Fix instantiation of imported temploid friends [PR114275]

On 4/19/24 09:29, Nathaniel Shead wrote: On Fri, Apr 19, 2024 at 12:14:06PM +1000, Nathaniel Shead wrote: On Wed, Apr 17, 2024 at 02:02:21PM -0400, Patrick Palka wrote: On Mon, 15 Apr 2024, Nathaniel Shead wrote: I'm not a huge fan of always streaming 'imported_temploid_friends' for all decls

Re: [PATCH] c++: ICE with templated sizeof(E1) / sizeof(E2) [PR114888]

On 4/29/24 07:52, Marek Polacek wrote: On Mon, Apr 29, 2024 at 10:28:19AM -0400, Patrick Palka wrote: Lightly tested on x86_64-pc-linux-gnu so far, does this look OK for trunk/14.1 after bootstrap+regtest finishes? LGTM. Yes, OK. -- >8 -- We're missing a dependence check for the second op

Re: [PATCH] c++/modules: imported spec befriending class tmpl [PR114889]

On 4/29/24 06:50, Patrick Palka wrote: Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps 14 (I guess after 14.1 is released)? OK for both. -- >8 -- We need to look through TEMPLATE_DECL like make_friend_class does when adding to CLASSTYPE_BEFRIENDING_CLASSES. Otherwise

Re: [PATCH v4 2/2] c++: Fix instantiation of imported temploid friends [PR114275]

On 4/29/24 02:34, Nathaniel Shead wrote: On Fri, Apr 26, 2024 at 09:16:40PM -0400, Jason Merrill wrote: On 4/19/24 09:29, Nathaniel Shead wrote: On Fri, Apr 19, 2024 at 12:14:06PM +1000, Nathaniel Shead wrote: On Wed, Apr 17, 2024 at 02:02:21PM -0400, Patrick Palka wrote: On Mon, 15 Apr 2024

Re: [PATCH] c++: Implement C++26 P0609R3 - Attributes for Structured Bindings [PR114456]

On 4/29/24 00:11, Jakub Jelinek wrote: Hi! The following patch implements the P0609R3 paper; we build the VAR_DECLs for the structured binding identifiers early, so all we need IMHO is just to parse the attributed identifier list and pass the attributes to the VAR_DECL creation. The paper menti

Re: [PATCH 2/3] c++/modules: Propagate using decls from partitions

On 4/30/24 00:59, Nathaniel Shead wrote: On Sun, Apr 14, 2024 at 01:40:18AM +1000, Nathaniel Shead wrote: On Fri, Apr 12, 2024 at 01:50:47PM -0400, Jason Merrill wrote: On 4/11/24 20:40, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? -- >8 --

Re: [PATCH] c++/modules: Implement P2615 'Meaningful Exports' [PR107688]

On 3/4/24 06:18, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu. This should probably wait for GCC 15 I suppose, but sending it in now in case there are any comments. OK for trunk. -- >8 -- This clarifies which kinds of declarations may and may not be exported in va

Re: [PATCH] c++/c-common: Fix convert_vector_to_array_for_subscript for qualified vector types [PR89224]

On 2/20/24 19:06, Andrew Pinski wrote: After r7-987-gf17a223de829cb, the access for the elements of a vector type would lose the qualifiers. So if we had `constvector[0]`, the type of the element of the array would not have const on it. This was due to a missing build_qualified_type for the inn

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