Re: [PATCH] c++: Fix OpenMP support with C++20 modules [PR119864]

On 4/22/25 4:48 PM, Jason Merrill wrote: On 4/22/25 1:21 PM, Tobias Burnus wrote: Jason Merrill wrote: On 4/22/25 11:04 AM, Tobias Burnus wrote: The question is why does this code trigger at all, given that there is OpenMP but no offload code at all? And how to fix it in case there is offload

[pushed] c++: attribute duplication [PR116954]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- As a followup to the previous patch for 116954, there's no reason to do anything in remove_contract_attributes if contracts aren't enabled. PR c++/116954 gcc/cp/ChangeLog: * contracts.cc (remove_contract_attributes): Retur

Re: [PATCH] c++: Fix OpenMP support with C++20 modules [PR119864]

On 4/22/25 1:21 PM, Tobias Burnus wrote: Jason Merrill wrote: On 4/22/25 11:04 AM, Tobias Burnus wrote: The question is why does this code trigger at all, given that there is OpenMP but no offload code at all? And how to fix it in case there is offload code and modules are used. This seems

Re: [PATCH] c++: Fix OpenMP support with C++20 modules [PR119864]

On 4/22/25 11:04 AM, Tobias Burnus wrote: Jason Merrill wrote: This is OK with a FIXME; presumably if we want to support running static constructors on the offload target we will eventually want to support that in modules as well. Well, the code that added support for static constructors

Re: Mark const parameters passed by invisible reference as readonly in the function body

On Mon, Apr 14, 2025 at 5:21 PM Jason Merrill wrote: > > On 3/30/25 6:12 PM, Jan Hubicka wrote: > > Hi, > > I noticed that this patch got forgotten and I think it may be useful to > > solve this next stage 1. > > > >> cp_apply_type_quals_to_decl drops

Re: [PATCH] c++: Fix OpenMP support with C++20 modules [PR119864]

On 4/21/25 6:46 AM, Nathaniel Shead wrote: I don't really know how OpenMP works, hopefully this makes sense. Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? And for 15 (I guess after release)? This is OK with a FIXME; presumably if we want to support running static constructor

Re: [pushed] c++: ill-formed constexpr function [PR113360]

On 4/17/25 10:06 AM, Patrick Palka wrote: On Wed, 16 Apr 2025, Jason Merrill wrote: If we already gave an error while parsing a function, we don't also need to try to explain what's wrong with it when we later try to use it in a constant-expression. In the ne

[pushed 2/3] c++: new size folding [PR118775]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- r15-7893 added a workaround for a case where we weren't registering (long)&a as invalid in a constant-expression, because build_new_1 had folded away the CONVERT_EXPR that we rely on to diagnose that problem. In general we want to defer mos

[PATCH RFA (fold)] c++: remove TREE_STATIC from constexpr heap vars [PR119162]

Tested x86_64-pc-linux-gnu, OK for trunk? -- 8< -- While working on PR119162 it occurred to me that it would be simpler to detect the problem of a value referring to a heap allocation if we stopped setting TREE_STATIC on them so they naturally are not considered to have a constant address. With

[pushed 1/3] c++: static constexpr strictness [PR99456]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- r11-7740 limited constexpr rejection of conversion from pointer to integer to manifestly constant-evaluated contexts; it should instead check whether we're in strict mode. The comment for that commit noted that making this change regressed

[pushed 3/3] c++: reorder constexpr checks

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- My coming proposed change to stop setting TREE_STATIC on constexpr heap pseudo-variables led to a diagnostic regression because we would get the generic "not constant" diagnostic before the "allocated storage" diagnostic. So let's move the g

Re: [PATCH 2/2] c++/modules: Remove unnecessary lazy_load_pendings

On 4/21/25 6:22 AM, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? OK. -- >8 -- This call is not necessary, as we don't access the bodies of any classes that we instantiate here. gcc/cp/ChangeLog: * name-lookup.cc (lookup_imported_hidden_fri

Re: [PATCH 1/2] c++/modules: Find non-exported reachable decls when instantiating friend classes [PR119863]

On 4/21/25 6:21 AM, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? And 15 (I guess after the release has been made)? OK, yes. -- >8 -- In r15-9029-geb26b667518c95, we started checking for conflicting declarations with any reachable decl attached to th

[pushed] c++: minor EXPR_STMT cleanup

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- I think it was around PR118574 that I noticed a few cases where we were unnecessarily wrapping a statement tree in a further EXPR_STMT. Let's avoid that and also use finish_expr_stmt in a few places in the coroutines code that were building

[PATCH RFC] c++: bad pending_template recursion

limit_bad_template_recursion currently avoids immediate instantiation of templates from uses in an already ill-formed instantiation, but we still can get unnecessary recursive instantiation in pending_templates if the instantiation was queued before the error. Currently this regresses several libs

PATCH RFC: -fdump-lang-tinst and -fdump-lang-constexpr

98e5cd5030: OK From 79fee55e07795ba57dd0788fd6bc29907b3a3608 Mon Sep 17 00:00:00 2001 From: Jason Merrill Date: Thu, 17 Apr 2025 16:29:49 -0400 Subject: [PATCH 1/4] c++: add cxx_dump_pretty_printer To: gcc-patches@gcc.gnu.org A class to simplify implementation of -fdump-lang-foo with support for

[pushed] c++: vec_safe_reserve usage tweaks

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- A couple of cleanups from noticing that the semantics of std::vector::reserve() (request the new minimum allocation) differ from the GCC vec<...>::reserve() (request a minimum number of slots available). In preserve_state, we were tripling

[pushed] c++: constexpr new diagnostic location

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Presenting the allocation location as the location of the outermost expression we're trying to evaluate is inaccurate; let's provide both locations. gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_outermost_constant_expr): Give both

[pushed] c++: constexpr virtual base diagnostic

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- I thought this diagnostic could be clearer that the problem is the combination of virtual bases and constexpr constructor, not just complain that the class has virtual bases without context. gcc/cp/ChangeLog: * constexpr.cc (is_val

[pushed] c++: improve pack index diagnostics

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- While looking at pack-indexing16.C I thought it would be helpful to print the problematic type/value. gcc/cp/ChangeLog: * semantics.cc (finish_type_pack_element): Add more info to diagnostics. libstdc++-v3/ChangeLog:

[pushed] c++: add assert to cp_make_fname_decl

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- In the PR118629 testcase, pushdecl_outermost_localscope was failing and returning error_mark_node without ever actually giving an error; in addition to my earlier fix for the failure, make sure failures aren't silent. gcc/cp/ChangeLog:

[pushed] c++: 'requires' diagnostic before C++20

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- We were giving a generic "not declared" error for a requires-expression without concepts enabled; we can do better. gcc/cp/ChangeLog: * lex.cc (unqualified_name_lookup_error): Handle 'requires' better. --- gcc/cp/lex.cc | 3 +++ 1

[pushed] c++: ill-formed constexpr function [PR113360]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- If we already gave an error while parsing a function, we don't also need to try to explain what's wrong with it when we later try to use it in a constant-expression. In the new testcase explain_invalid_constexpr_fn couldn't find anything st

[pushed] c++: format attribute redeclaration [PR116954]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Here when merging the two decls, remove_contract_attributes loses ATTR_IS_DEPENDENT on the format attribute, so apply_late_template_attributes just returns, so the attribute doesn't get propagated to the type where the warning looks for it.

[pushed] c++: templates, attributes, #pragma target [PR114772]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Since r12-5426 apply_late_template_attributes suppresses various global state to avoid applying active pragmas to earlier declarations; we also need to override target_option_current_node. PR c++/114772 PR c++/101180 gcc/cp

[pushed] c++: constexpr, trivial, and non-alias target [PR111075]

Tested the testcase fix with a Darwin cross-compiler. Regression tested x86_64-pc-linux-gnu. Applying to trunk. -- 8< -- On Darwin and other targets with !can_alias_cdtor, we instead go to maybe_thunk_ctor, which builds a thunk function that calls the general constructor. And then cp_fold tries

Re: [PATCH] c++: Prune lambda captures from more places [PR119755]

On 4/15/25 2:56 AM, Nathaniel Shead wrote: On Mon, Apr 14, 2025 at 05:33:05PM -0400, Jason Merrill wrote: On 4/13/25 6:32 AM, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? -- >8 -- Currently, pruned lambda captures are still leftover in

Re: Mark const parameters passed by invisible reference as readonly in the function body

On 3/30/25 6:12 PM, Jan Hubicka wrote: Hi, I noticed that this patch got forgotten and I think it may be useful to solve this next stage 1. cp_apply_type_quals_to_decl drops 'const' if the type has mutable members. Unfortunately TREE_READONLY on the PARM_DECL isn't helpful in the case of an inv

Re: [PATCH] c++: wrong targs printed in hard satisfaction error [PR99214]

() [with U = int]' Would this be preferable? I'd be good with either. This approach certainly seems tidier; OK. Jason On Wed, 9 Apr 2025, Patrick Palka wrote: On Wed, 9 Apr 2025, Patrick Palka wrote: On Wed, 5 Mar 2025, Jason Merrill wrote: On 3/5/25 10:13 AM, Patrick Palka wrote:

Re: [PATCH] c++: Prune lambda captures from more places [PR119755]

On 4/15/25 9:39 AM, Nathaniel Shead wrote: On Tue, Apr 15, 2025 at 09:16:46AM -0400, Jason Merrill wrote: On 4/15/25 2:56 AM, Nathaniel Shead wrote: On Mon, Apr 14, 2025 at 05:33:05PM -0400, Jason Merrill wrote: On 4/13/25 6:32 AM, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64

Re: [PATCH] c++: prev declared hidden tmpl friend inst, cont [PR119807]

On 4/14/25 5:22 PM, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk and later 14? OK. -- >8 -- When remapping existing specializations of a hidden template friend from a previous declaration to the new definition, we must remap only those s

[pushed] c++: shortcut constexpr vector ctor [PR113835]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Since std::vector became usable in constant evaluation in C++20, a vector variable with static storage duration might be manifestly constant-evaluated, so we properly try to constant-evaluate its initializer. But it can never succeed since t

Re: [PATCH] c++: Prune lambda captures from more places [PR119755]

+.dg/modules/lambda-10_b.C @@ -0,0 +1,7 @@ +// PR c++/119755 +// { dg-additional-options "-fmodules" } + +import "lambda-10_a.H"; +int main() { + vformat(); +} From cd096d37ae49da23d6ee744405dcadf5000bbbcd Mon Sep 17 00:00:00 2001 From: Jason Merrill Date: Mon, 14 Apr 2025 12:18:

Re: [PATCH RFA (diagnostic)] c++: modules and #pragma diagnostic

On 1/9/25 10:00 PM, Jason Merrill wrote: Tested x86_64-pc-linux-gnu. Is the diagnostic.h change OK for trunk? Ping? -- 8< -- To respect the #pragma diagnostic lines in libstdc++ headers when compiling with module std, we need to represent them in the module. I think it's reaso

Re: [PATCH v2] c++/modules: More fixes for merging DECL_MAYBE_DELETED functions

On 4/10/25 5:35 PM, Nathaniel Shead wrote: On Thu, Apr 10, 2025 at 12:19:57PM -0400, Jason Merrill wrote: On 4/10/25 8:46 AM, Nathaniel Shead wrote: Regression raised with my by private correspondance. Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? -- >8 -- My change in

Re: [PATCH] c++: improve constexpr call caching [PR115639]

On 4/12/25 12:20 PM, Patrick Palka wrote: On Sat, 12 Apr 2025, Jason Merrill wrote: On 4/11/25 4:36 PM, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for GCC 15 perhaps? -- >8 -- Here checking static_assert(0 == big_calc()); takes twice

Re: [PATCH] c++: improve constexpr prvalue folding [PR116416]

On 4/11/25 4:36 PM, Patrick Palka wrote: Boostrapped and regtested on x86_64-pc-linux- gnu, does this look OK for GCC 15 perhaps? -- >8 -- This patch improves upon r15-6052-g12de1942a0a673 by performing prvalue folding with mce_false rather than mce_unknown when it's safe to do so (i.e. the cal

Re: [PATCH] c++: improve constexpr call caching [PR115639]

On 4/11/25 4:36 PM, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for GCC 15 perhaps? -- >8 -- Here checking static_assert(0 == big_calc()); takes twice as much time as constexpr int ret = big_calc(); static_assert(0 == ret); ultimately b

[pushed] c++: avoid ARM -Wunused-value [PR114970]

Tested by me on x86_64-pc-linux-gnu and Sam James on armv7a-unknown-linux-gnueabihf, applying to trunk. -- 8< -- Because of the __builtin_is_constant_evaluated, maybe_constant_init in expand_default_init fails, so the constexpr constructor isn't folded until cp_fold, which then calls cp_build_ini

[pushed] c++: constinit and value-initialization [PR119652]

Tested x86_64-pc-linux-gnu, applying to trunk and 14. -- 8< -- Value-initialization built an AGGR_INIT_EXPR to set AGGR_INIT_ZERO_FIRST on. Passing that AGGR_INIT_EXPR to maybe_constant_value returned a TARGET_EXPR, which potential_constant_expression_1 mistook for a temporary. We shouldn't add

Re: [PATCH] c++: Properly mangle CONST_DECL without a INTEGER_CST value [PR116511]

On 9/6/24 7:15 AM, Simon Martin wrote: We ICE upon the following *valid* code when mangling the requires clause === cut here === template struct s1 { enum { e1 = 1 }; }; template struct s2 { enum { e1 = s1::e1 }; s2() requires(0 != e1) {} }; s2<8> a; === cut here === The problem is t

[pushed] c++: nested lambda capture pack [PR119345]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- tsubst_stmt already registers a local capture proxy as a local_specialization of both an outer capture proxy and the captured variable; we also need to do that in add_extra_args. PR c++/119345 gcc/cp/ChangeLog: * pt.cc (ad

Re: [PATCH GCC 15] c++: ICE with nested default targ lambdas [PR119574]

On 4/10/25 12:34 PM, Jason Merrill wrote: On 4/8/25 10:29 AM, Patrick Palka wrote: The template arguments aren't dependent however -- they're just incomplete because when we deferred them we were in the middle deduction, and we consider a NULL_TREE template argument as dependent.

Re: [PATCH] c++: alias_ctad_tweaks ICE w/ inherited CTAD [PR119687]

On 4/9/25 11:11 AM, Patrick Palka wrote: Bootstrap and regtest running on x86_64-pc-linux-gnu, does this look OK for trunk/14 if successful? OK. On a similar note, as a small optimization in deduction_guides_for I think we can replace the lookup_add loop with a single call to lookup_add, but

Re: [PATCH GCC 15] c++: ICE with nested default targ lambdas [PR119574]

On 4/8/25 10:29 AM, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? OK. -- >8 -- Here we substitute into the inner lambda twice, first during default argument substitution for the outer template parameters, then during that for the inner t

Re: [PATCH] c++: Use G_ instead of _ around cp/errors.cc gcc-internal-format strings [PR119684]

On 4/9/25 3:16 PM, Jakub Jelinek wrote: Hi! These pp_printf/pp_verbatim format strings should be gcc-internal-format, they use the pretty-print.cc format specifier handling rather than libc *printf, but pp_printf/pp_verbatim are intentionally not handled through exgettext because not everything

Re: [PATCH] c++/modules: More fixes for merging DECL_MAYBE_DELETED functions

On 4/10/25 8:46 AM, Nathaniel Shead wrote: Regression raised with my by private correspondance. Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? -- >8 -- My change in r15-9216 broke the case where we imported an uninstantiated defaulted function over the top of one we had alread

[pushed] c++: lambda in constraint of lambda [PR119175]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Here when we went to mangle the constraints of from<0>, the outer lambda has no mangling scope, but the inner one was treated as having the outer one as its scope. And mangling the outer one means mangling its constraints, which include the

Re: [PATCH GCC 14] c++: ICE with nested default targ lambdas [PR119574]

On 4/8/25 10:29 AM, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for the 14 branch? OK. -- >8 -- In GCC 14 we fixed PR116567 in a more conservative way that doesn't distinguish between the two kinds of deferred substitutions, and we instead ICE fr

[pushed] c++: lambda in concept [PR118698]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- When normalizing is_foo for , we get to normalizing callable for , which means substituting into . Since r14-9938, because in_template_context is false we return the lambda unchanged, just with LAMBDA_EXPR_EXTRA_ARGS set, so the closure t

[pushed] c++: self-dependent alias template [PR117530]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Here, instantiating B means instantiating A, which means instantiating B. And then when we go to register the initial instantiation, it conflicts with the inner one. Fixed by checking after tsubst whether there's already something in the h

[pushed] c++: constexpr ref template arg [PR119194]

Tested x86_64-pc-linux-gnu, applying to trunk/14. -- 8< -- Here we were assuming that a constant variable appearing in a template argument is used for its value. We also need to handle seeing its address taken. PR c++/119194 gcc/cp/ChangeLog: * decl2.cc (min_vis_expr_r) [ADDR_

Re: [PATCH] c++: Rename -fmodules-ts to -fmodules in diagnostics

On 4/1/25 7:49 AM, Nathaniel Shead wrote: Tested on x86_64-pc-linux-gnu, OK for trunk if full bootstrap + regtest succeeds? OK. -- >8 -- This replaces some usages of the old -fmodules-ts flag with the new -fmodules flag made in r15-5112-gd9c3c3c85665b2. gcc/cp/ChangeLog: * parser.c

Re: [PATCH] c++: ICE w/ dependently scoped template friend [PR119378]

On 3/21/25 3:46 PM, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for 14/13/12 (since it was reported against GCC 12)? This old regression is already fixed on trunk by r15-123 which contains this change. OK. -- >8 -- Here we ICE during instantiati

Re: [PATCH] nvptx: In offloading compilation, special-case certain host-setup symbol aliases [PR101544]

On 3/20/25 11:35 AM, Thomas Schwinge wrote: Hi! Appears that I'm too dumb to implement : | We "simply" need to transform any symbol aliases into thunks calling the aliasee (or duplicate the bodies, if we must). ..., and implementing pro

Re: [PATCH 2/1] c++/modules: Handle gnu_inline, again [PR119154]

On 3/22/25 8:37 AM, Nathaniel Shead wrote: On Mon, Mar 17, 2025 at 09:42:13AM -0400, Jason Merrill wrote: On 3/14/25 9:28 AM, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? Alternatively, could still mark gnu_inline functions as non-vague, we just need

[pushed] c++: operator!= rewriting and arg-dep lookup

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- When considering an op== as a rewrite target, we need to disqualify it if there is a matching op!= in the same scope. But add_candidates was assuming that we could use the same set of op!= for all op==, which is wrong if arg-dep lookup find

[pushed] c++: lambda in function template signature [PR119401]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Here we instantiate the lambda three times in producing A<0>::f: 1) in tsubst_function_type, substituting the type of A<>::f 2) in tsubst_function_decl, substituting the parameters of A<>::f 3) in regenerate_decl_from_template when instantia

Re: [PATCH] c++: structural equality and partially inst typedef [PR119379]

On 3/21/25 3:58 PM, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? OK. -- >8 -- Complex alias templates (and their dependent specializations) use structural equality because we want to treat them as transparent in some contexts but not ot

[pushed] c++: __FUNCTION__ in lambda return type [PR118629]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- In this testcase, the use of __FUNCTION__ is within a function parameter scope, the lambda's. And P1787 changed __func__ to live in the parameter scope. But [basic.scope.pdecl] says that the point of declaration of __func__ is immediately

Re: [pushed] c++: lambda in requires outside template [PR99546]

On 4/4/25 4:35 PM, Patrick Palka wrote: On Fri, 4 Apr 2025, Jason Merrill wrote: Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Since r10-7441 we set processing_template_decl in a requires-expression so that we can use tsubst_expr to evaluate the requirements, but that confu

Re: [PATCH] c++: harmless use of 'this' rejected despite P2280R4 [PR118249]

On 4/4/25 12:11 PM, Patrick Palka wrote: Here the implicit use of 'this' in inner.size() template argument was being rejected despite P2280R4 relaxations, due to the special *this handling in the INDIRECT_REF case of potential_constant_expression_1. This handling was originally added by r196737

[pushed] c++: lambda in requires outside template [PR99546]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Since r10-7441 we set processing_template_decl in a requires-expression so that we can use tsubst_expr to evaluate the requirements, but that confuses lambdas terribly; begin_lambda_type silently returns error_mark_node and we continue into

Re: [PATCH] c++: Fix GC with TU_LOCAL_ENTITY [PR119564]

On 4/3/25 9:28 PM, Nathaniel Shead wrote: Tested on x86_64-pc-linux-gnu (so far just modules.exp), OK for trunk if full bootstrap+regtest succeeds? OK. -- >8 -- When adding TU_LOCAL_ENTITY in r15-6379 I neglected to add it to cp_tree_node_structure, so garbage collection was crashing on it.

Re: [PATCH] c++, libcpp: Allow some left shifts in the preprocessor [PR119391]

On 3/21/25 8:33 PM, Jakub Jelinek wrote: Hi! The libcpp left shift handling implements (partially) the C99-C23 wording where shifts are UB if shift count is negative, or too large, or shifting left a negative value or shifting left non-negative value results in something not representable in the

Re: [PATCH] c++/modules: Fix divergence in streaming/non-streaming tree walks [PR119608]

On 4/3/25 9:09 PM, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? OK. -- >8 -- Modules streaming walks decls multiple times, first as a non-streaming walk to find dependencies, and then later to actually emit the decls. The first walk needs to be done

Re: [PATCH] c++/modules: Propagate bits to DECL_MAYBE_DELETED dups [PR119462]

On 4/4/25 4:14 AM, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? OK. -- >8 -- In the linked PR, we're importing over a DECL_MAYBE_DELETED decl with a decl that has already been instantiated. This patch ensures that the needed bits are propagated acr

Re: [PATCH] c++: constraint variable used in evaluated context [PR117849]

On 4/4/25 9:25 AM, Patrick Palka wrote: On Fri, 4 Apr 2025, Patrick Palka wrote: On Thu, 3 Apr 2025, Jason Merrill wrote: On 4/2/25 2:28 PM, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/14? OK for 14. For 15, what happens if we

Re: [PATCH] c++: P2280R4 and speculative constexpr folding [PR119387]

On 4/2/25 3:07 PM, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux, does this look OK for trunk/14? OK. -- >8 -- The testcase in this PR uses 2.5x more memory and 6x more compile time ever since r14-5979 which implements P2280R4. This is because our speculative constexpr

[pushed] c++/modules: inline loaded at eof

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- std/format/string.cc and a few other libstdc++ tests were failing with module std with undefined references to __failed_to_parse_format_spec. This turned out to be because since r15-8012 we don't end up calling note_vague_linkage_fn for fun

Re: [PATCH] c++: constraint variable used in evaluated context [PR117849]

On 4/2/25 2:28 PM, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/14? OK for 14. For 15, what happens if we remove that error entirely? Do we still give other errors in that case? That seems to be the expectation of https://eel.is/c++dra

Re: [PATCH 2/2] c++: maybe_dependent_member_ref and typenames [PR118626]

On 3/31/25 7:51 PM, Patrick Palka wrote: Here during maybe_dependent_member_ref for accepted_type<_Up>, we correctly don't strip the typedef because it's a complex one (its defaulted template parameter isn't used in its definition) and so we recurse to consider its corresponding TYPE_DECL. We th

Re: [PATCH 1/2] c++: maybe_dependent_member_ref and stripped alias [PR118626]

On 3/31/25 7:51 PM, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? This isn't a regression and potentially impacts C++17 code, but it also makes alias CTAD unusable for our std::variant currently. OK. -- >8 -- Here during maybe_dependent

Re: [PATCH] c++: Fix typo in RAW_DATA_CST build_list_conv subsubconv hanling [PR119563]

On 4/1/25 10:31 AM, Jakub Jelinek wrote: Hi! The following testcase ICEs (the embed one actually doesn't but dereferences random uninitialized pointer far after allocated memory) because of a typo. In the RAW_DATA_CST handling of list conversion where there are conversions to something other th

Re: [PATCH v2] c++: fix missing lifetime extension [PR119383]

On 3/31/25 4:59 PM, Marek Polacek wrote: On Thu, Mar 27, 2025 at 11:27:04AM -0400, Jason Merrill wrote: On 3/25/25 3:37 PM, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14? -- >8 -- Since r15-8011 cp_build_indirect_ref_1 won't do the *&

Re: [PATCH] c++/modules: Forbid exposures of TU-local entities in inline variables [PR119551]

On 4/1/25 7:02 AM, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? -- >8 -- An inline variable has vague linkage, and needs to be conditionally emitted in TUs that reference it. Unfortunately this clashes with [basic.link] p14.2, which says that we ignor

Re: [PATCH] c++: Honor noipa attribute for FE nothrow discovery [PR119518]

On 3/29/25 4:32 AM, Jakub Jelinek wrote: Hi! The following testcase has different code generation in bar depending on whether foo is defined or just declared. That is undesirable when it has noipa attribute, that attribute is documented to be a black box between caller and callee, so the caller

[pushed] c++/modules: unexported friend template

Tested x86_64-pc-linux-gnu, applying to trunk. Do you agree with my choice of how to adjust duplicate_decls? -- 8< -- Here we were failing to match the injected friend declaration to the definition because the latter isn't exported. But the friend is attached to the module, so we need to look f

[PATCH RFC] c++: optimize push_to_top_level [PR64500]

Tested x86_64-pc-linux-gnu, initially with extra checking to make sure that indeed nothing got saved from a namespace level. This isn't a regression, but a 20% speedup for a simple change is pretty attractive; what do people think about this change for GCC 15? -- 8< -- Profiling showed that the

Re: [PATCH v5] libcpp: Fix incorrect line numbers in large files [PR108900]

On 3/28/25 3:54 AM, yash.shi...@windriver.com wrote: From: Jeremy Bettis This patch addresses an issue in the C preprocessor where incorrect line number information is generated when processing files with a large number of lines. The problem arises from improper handling of location intervals i

Re: [PATCH v3] c++: fix reporting routines re-entered [PR119303]

On 3/28/25 12:46 PM, Marek Polacek wrote: On Fri, Mar 28, 2025 at 11:49:48AM -0400, Jason Merrill wrote: On 3/27/25 5:00 PM, Marek Polacek wrote: On Wed, Mar 19, 2025 at 12:00:00PM -0400, Jason Merrill wrote: On 3/17/25 6:55 PM, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux

Re: [PATCH v2] c++: fix reporting routines re-entered [PR119303]

On 3/27/25 5:00 PM, Marek Polacek wrote: On Wed, Mar 19, 2025 at 12:00:00PM -0400, Jason Merrill wrote: On 3/17/25 6:55 PM, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- We crash while we call warning_at ("inline function used but never

Re: [PATCH v2] c++/modules: Fix modules and LTO with header units [PR118961]

On 3/28/25 8:54 AM, Nathaniel Shead wrote: On Thu, Mar 27, 2025 at 10:38:02AM -0400, Jason Merrill wrote: On 3/27/25 3:35 AM, Nathaniel Shead wrote: Bootstrapped and regtested (so far just dg.exp and modules.exp) on x86_64-pc-linux-gnu, OK for trunk if full regtest succeeds? Rather than

Re: [PATCH] c++: fix missing lifetime extension [PR119383]

On 3/25/25 3:37 PM, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14? -- >8 -- Since r15-8011 cp_build_indirect_ref_1 won't do the *&TARGET_EXPR -> TARGET_EXPR folding not to change its value category. That fix is correct but it made us stop extending the life

Re: [PATCH] c++/modules: Fix modules and LTO with header units [PR118961]

On 3/27/25 3:35 AM, Nathaniel Shead wrote: Bootstrapped and regtested (so far just dg.exp and modules.exp) on x86_64-pc-linux-gnu, OK for trunk if full regtest succeeds? Rather than updating copy_fndecl_with_name, we could also just fix modules specifically by overwriting DECL_ABSTRACT_P before

Re: [PATCH 2/2] c++/modules: Handle conflicting ABI tags [PR118920]

On 3/27/25 8:05 AM, Nathaniel Shead wrote: On Thu, Mar 27, 2025 at 08:02:20AM -0400, Jason Merrill wrote: On 3/26/25 9:24 AM, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? -- >8 -- The ICE in the linked PR is caused because out_ptr_t inherits an

Re: [PATCH 2/2] c++/modules: Handle conflicting ABI tags [PR118920]

On 3/26/25 9:24 AM, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? -- >8 -- The ICE in the linked PR is caused because out_ptr_t inherits an ABI tag in a module that it does not in the importing module. When we try to build a qualified 'const out_ptr_t'

Re: [PATCH 1/2] c++/modules: Fix tsubst of global module friend classes [PR118920]

le.cc (get_originating_module): Rename for_mangle parm to global_m1. * error.cc (dump_module_suffix): Don't decorate global module decls. gcc/testsuite/ChangeLog: * g++.dg/modules/tpl-friend-17.h: New test. * g++.dg/modules/tpl-friend-17_a.C: New test. * g++.dg/modules/tpl-friend-17_b.C:

Re: [PATCH] c++: Fix FAIL: g++.dg/tree-ssa/initlist-opt1.C

On 3/26/25 6:14 AM, Jonathan Wakely wrote: My r15-8904-ge200f53a555651 changed the std::vector initializer-list constructor so that it calls a new _M_range_initialize_n function instead of _M_range_initialize. Change the scan-tree-dump pattern in this g++.dg test to match the new gimple output.

Re: [PATCH] c++: Properly fold .* [PR114525]

On 3/25/25 1:50 PM, Marek Polacek wrote: On Tue, Mar 25, 2025 at 05:18:23PM +, Simon Martin wrote: We've been miscompiling the following since r0-51314-gd6b4ea8592e338 (I did not go compile something that old, and identified this change via git blame, so might be wrong) === cut here === str

Re: [PATCH] tailc: Don't fail musttail calls if they use or could use local arguments, instead warn [PR119376]

On 3/25/25 3:34 AM, Jakub Jelinek wrote: Hi! As discussed here and in bugzilla, [[clang::musttail]] attribute in clang not just strongly asks for tail call or error, but changes behavior. To quote: https://clang.llvm.org/docs/AttributeReference.html#musttail "The lifetimes of all local variables

Re: [PATCH] c++: Fix ICE when template lambdas call with default parameters in unevaluated context

On 3/25/25 11:43 AM, yxj-github-437 wrote: This patch would like to avoid the ICE when template lambdas call with default parameters in unevaluated context. The bug is the same as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119385. For example as blow: 1 | template 2 | void foo

Re: [PATCH] c++: Properly fold .* [PR114525]

On 3/25/25 1:18 PM, Simon Martin wrote: We've been miscompiling the following since r0-51314-gd6b4ea8592e338 (I did not go compile something that old, and identified this change via git blame, so might be wrong) === cut here === struct Foo { int x; }; Foo& get (Foo &v) { return v; } void bar ()

Re: [PATCH] c++: Fix ICE when template lambdas call with default parameters in unevaluated context

On 3/25/25 10:17 AM, yxj-github-437 wrote: This patch would like to avoid the ICE when template lambdas call with default parameters in unevaluated context. For example as blow: 1 │ template 2 │ void foo(T x) { 3 │ sizeof [](T=x) { return 0; }(); 4 │ } 5

Re: C++: Adjust implicit '__cxa_bad_typeid' prototype to reality

On 3/25/25 9:17 AM, Thomas Schwinge wrote: Hi! On 2025-03-24T13:38:56-0400, Jason Merrill wrote: On 3/24/25 7:02 AM, Thomas Schwinge wrote: On 2025-03-21T15:46:01+0100, I wrote: On 2025-03-19T14:25:49+, Jonathan Wakely wrote: On Wed, 19 Mar 2025 at 14:21, Marek Polacek wrote: On Wed

Re: [PATCH] c++: Fix ICE when template lambdas call with default parameters in unevaluated context

On 3/22/25 4:38 PM, yxj-github-437 wrote: This patch would like to avoid the ICE when template lambdas call with default parameters in unevaluated context. For example as blow: 1 │ template 2 │ void foo(T x) { 3 │ sizeof [](T=x) { return 0; }(); 4 │ } 5 │

[pushed] c++: pack indexing and if consteval

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- The pack index is manifestly constant-evaluated, and the call to maybe_constant_value needs to reflect that or we wrongly complain about non-constant index if the evaluation uses if consteval. gcc/cp/ChangeLog: * semantics.cc (fini

Re: [WIP] C++: Adjust implicit '__cxa_bad_typeid' prototype to reality

eid1.C: In function 'int main()': [...]/g++.dg/rtti/typeid1.C:9:12: error: lvalue required as unary '&' operand I got lost in the C++ front end code trying to understand how to resolve this mismatch. Anyone able to advise, please? This addition seems to resolve it: F

[PATCH RFA] ipa: target clone and mangling alias [PR114992]

Tested x86_64-pc-linux-gnu. OK for trunk and backports? -- 8< -- Since the mangling of the second lambda changed (previously we counted all lambdas, now we only count lambdas with the same signature), we generate_mangling_alias for handler for backward compatibility. Since handler is COMDAT, res

Re: [PATCH] c++: Don't mix timevar_start and auto_cond_timevar for TV_NAME_LOOKUP [PR116681]

On 3/23/25 1:55 AM, Simon Martin wrote: Hi, On Sat Sep 14, 2024 at 10:00 AM CEST, Jason Merrill wrote: On 9/13/24 1:31 PM, Simon Martin wrote: We currently ICE upon the following testcase when using -ftime-report === cut here === template < int> using __conditional_t = int; te

  1   2   3   4   5   6   7   8   9   10   >