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

2024-05-25 Thread Patrick Palka
Bootstrap and regtest on x86_64-pc-linux-gnu in progress, does this look OK for trunk if successful? -- >8 -- When propagating structural equality in build_cp_fntype_variant, we should consider structural equality of the exception-less variant, not of the given type which might use structural

Re: [PATCH v2] libstdc++: Fix std::ranges::iota not included in numeric [PR108760]

2024-05-23 Thread Patrick Palka
On Fri, 17 May 2024, Michael Levine (BLOOMBERG/ 731 LEX) wrote: > This is the revised version of my patch incorporating the provided feedback > from Patrick Palka and Jonathan Wakely. > This patch fixes GCC Bug 108760: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1087

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

2024-05-23 Thread Patrick Palka
t. > * g++.dg/modules/tpl-friend-13_b.C: New test. > * g++.dg/modules/tpl-friend-13_c.C: New test. > * g++.dg/modules/tpl-friend-13_d.C: New test. > * g++.dg/modules/tpl-friend-13_e.C: New test. > * g++.dg/modules/tpl-friend-13_f.C: New test. > *

Re: [PATCH v26 01/13] libstdc++: Optimize std::is_const compilation performance

2024-05-23 Thread Patrick Palka
On Sat, 11 May 2024, Ken Matsui wrote: > This patch optimizes the compilation performance of std::is_const > by dispatching to the new __is_const built-in trait. This patch series LGTM > > libstdc++-v3/ChangeLog: > > * include/std/type_traits (is_const): Use __is_const built-in >

Re: [PATCH] libstdc++: Implement ranges::concat_view from P2542R7

2024-05-23 Thread Patrick Palka
On Mon, 29 Apr 2024, Jonathan Wakely wrote: > On Mon, 22 Apr 2024 at 22:43, Patrick Palka wrote: > > > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk? More tests > > are needed but I figured I'd submit this now for possible consideration into > > GCC 1

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

2024-05-23 Thread Patrick Palka
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

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

2024-05-23 Thread Patrick Palka
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 guide since DECL_NAME is still __dguide_C

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

2024-05-22 Thread Patrick Palka
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 you'll need to either do that or

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

2024-05-22 Thread Patrick Palka
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: > > > >

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

2024-05-21 Thread Patrick Palka
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,

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

2024-05-21 Thread Patrick Palka
On Tue, 21 May 2024, 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? > > > > > > Alterna

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

2024-05-21 Thread Patrick Palka
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 > > comparin

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

2024-05-21 Thread Patrick Palka
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 identity depends on whether

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

2024-05-17 Thread Patrick Palka
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/14? -- >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 exit early when substituting the CONST_DECLs for e1 and e2

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

2024-05-16 Thread Patrick Palka
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps 14? -- >8 -- We're accidentally ignoring base classes during parenthesized aggregate CTAD because the TYPE_FIELDS of a template type doesn't contain bases, so we need to consider them separately.

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

2024-05-15 Thread Patrick Palka
Bootstrapped and regtested on x86_64-pc-linu-xgnu, does this look OK for trunk? -- >8 -- Non-dependent compound assignment expressions are currently represented as CALL_EXPR to the selected operator@= overload. Non-dependent simple assignments on the other hand are still represented as

Re: [PATCH v3] c++: Fix auto deduction for template specialization scopes [PR114915]

2024-05-15 Thread Patrick Palka
On Wed, 15 May 2024, Patrick Palka wrote: > > On Fri, 10 May 2024, Seyed Sajad Kahani wrote: > > > This patch resolves PR114915 by replacing the logic that fills in the > > missing levels in do_auto_deduction in cp/pt.cc. > > The new approach now trims targs if t

Re: [PATCH v3] c++: Fix auto deduction for template specialization scopes [PR114915]

2024-05-15 Thread Patrick Palka
On Fri, 10 May 2024, Seyed Sajad Kahani wrote: > This patch resolves PR114915 by replacing the logic that fills in the missing > levels in do_auto_deduction in cp/pt.cc. > The new approach now trims targs if the depth of targs is deeper than desired > (this will only happen in specific

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

2024-05-11 Thread Patrick Palka
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

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

2024-05-10 Thread Patrick Palka
On Thu, 9 May 2024, Patrick Palka wrote: > On Thu, 9 May 2024, 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

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

2024-05-09 Thread Patrick Palka
On Thu, 9 May 2024, 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 CALL_EXPR instead of > MODOP_EXPR for a non-dependent simpl

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

2024-05-09 Thread Patrick Palka
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 CALL_EXPR instead of MODOP_EXPR for a non-dependent simple assignment expression that resolved to an operator= overload. -- >8

Re: [PATCH] c++: nested aggregate/alias CTAD fixes

2024-05-08 Thread Patrick Palka
On Wed, 8 May 2024, Patrick Palka wrote: > Bootstrapped and regtested on x86-64-pc-linux-gnu, does this look > OK for trunk and perhaps 14? > > -- >8 -- > > During maybe_aggr_guide with a nested class template and paren init, > like with list init we need to consider t

[PATCH] c++: nested aggregate/alias CTAD fixes

2024-05-08 Thread Patrick Palka
Bootstrapped and regtested on x86-64-pc-linux-gnu, does this look OK for trunk and perhaps 14? -- >8 -- During maybe_aggr_guide with a nested class template and paren init, like with list init we need to consider the generic template type rather than the partially instantiated type since only

Re: [PATCH v3] c++/modules: Fix dangling pointer with imported_temploid_friends

2024-05-06 Thread Patrick Palka
rote: > > > > > On Wed, May 01, 2024 at 09:57:38AM -0400, Patrick Palka wrote: > > > > > > > > > > > > On Wed, 1 May 2024, Nathaniel Shead wrote: > > > > > > > > > > > > > Bootstrapped and regtested on x86_64-p

Re: [PATCH v2] Fix auto deduction for template specialization scopes [PR114915]

2024-05-06 Thread Patrick Palka
On Sat, 4 May 2024, Seyed Sajad Kahani wrote: > The limitations of the initial patch (checking specializiation template > usage), have been discussed. > > > I realized that for the case where we have a member function template > > of a class template, and a specialization of the enclosing class

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

2024-05-03 Thread Patrick Palka
Thanks for the patch! On Wed, 1 May 2024, Seyed Sajad Kahani wrote: > When deducing auto for `adc_return_type`, `adc_variable_type`, and > `adc_decomp_type` contexts (at the usage time), we try to resolve the > outermost template arguments to be used for satisfaction. This is done by one > of

[PATCH] c++: replace tf_norm with a local flag

2024-05-03 Thread Patrick Palka
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- The tf_norm flag controlling whether to build diagnostic information during constraint normalization doesn't need to be a global tsubst flag, and is confusingly named. This patch replaces it with a boolean

Re: [PATCH] c++: 'typename T::X' vs 'struct T::X' lookup [PR109420]

2024-05-03 Thread Patrick Palka
Hey Andrew, On Wed, 5 Apr 2023, Andrew Pinski wrote: > On Wed, Apr 5, 2023 at 10:32 AM Patrick Palka via Gcc-patches > wrote: > > > > On Wed, 5 Apr 2023, Patrick Palka wrote: > > > > > r13-6098-g46711ff8e60d64 made make_typename_type no longer ignore > >

Re: [PATCH 2/2] c++: remove lookup_template_class's entering_scope flag

2024-05-02 Thread Patrick Palka
On Wed, 1 May 2024, Jason Merrill wrote: > On 5/1/24 13:40, Patrick Palka wrote: > > On Wed, 1 May 2024, Jason Merrill wrote: > > > > > On 5/1/24 12:41, Patrick Palka wrote: > > > > On Fri, 2 Feb 2024, Patrick Palka wrote: > > > > > > >

Re: [PATCH v14 21/26] c++: Implement __rank built-in trait

2024-05-02 Thread Patrick Palka
On Tue, 30 Apr 2024, Jason Merrill wrote: > On 2/28/24 11:26, Ken Matsui wrote: > > This patch implements built-in trait for std::rank. > > __rank seems too short, maybe __array_rank? > > Actually, it occurs to me that perhaps we should have been adding __builtin to > all of these rather than

Re: [PATCH] c++/modules: Stream unmergeable temporaries by value again [PR114856]

2024-05-02 Thread Patrick Palka
On Thu, 2 May 2024, Nathaniel Shead wrote: > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/14.2? > > Another alternative would be to stream such !DECL_NAME temporaries with > a merge key of MK_unique rather than attempting to find the matching > (nonexistant) field of the class

Re: [PATCH v2] c++/modules: Fix dangling pointer with imported_temploid_friends

2024-05-02 Thread Patrick Palka
On Wed, May 1, 2024 at 9:35 PM Nathaniel Shead wrote: > > On Thu, May 02, 2024 at 12:15:44AM +1000, Nathaniel Shead wrote: > > On Wed, May 01, 2024 at 09:57:38AM -0400, Patrick Palka wrote: > > > > > > On Wed, 1 May 2024, Nathaniel Shead wrote: > > > >

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

2024-05-01 Thread Patrick Palka
On Wed, 1 May 2024, Patrick Palka wrote: > On Wed, 1 May 2024, Jason Merrill wrote: > > > On 4/12/24 13:22, Patrick Palka wrote: > > > On Fri, 12 Apr 2024, Jason Merrill wrote: > > > > > > > On 3/26/24 09:44, Patrick Palka wrote: > &g

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

2024-05-01 Thread Patrick Palka
On Wed, 1 May 2024, Jason Merrill wrote: > On 4/12/24 13:22, Patrick Palka wrote: > > On Fri, 12 Apr 2024, Jason Merrill wrote: > > > > > On 3/26/24 09:44, Patrick Palka wrote: > > > > On Thu, 7 Mar 2024, Jason Merrill wrote: > > > >

Re: [PATCH 2/2] c++: remove lookup_template_class's entering_scope flag

2024-05-01 Thread Patrick Palka
On Wed, 1 May 2024, Jason Merrill wrote: > On 5/1/24 12:41, Patrick Palka wrote: > > On Fri, 2 Feb 2024, Patrick Palka wrote: > > > > > Bootstrapped and regtested on x86_64-pc-linux, does this look like > > > an improvement? This is not a bugfix and barely re

Re: [PATCH 2/2] c++: remove lookup_template_class's entering_scope flag

2024-05-01 Thread Patrick Palka
On Fri, 2 Feb 2024, Patrick Palka wrote: > Bootstrapped and regtested on x86_64-pc-linux, does this look like > an improvement? This is not a bugfix and barely related to the previous > patch, but the previous patch's new use of entering_scope=true motivated > me to submit this

Re: [PATCH 2/4] c++/modules: Track module purview for deferred instantiations [PR114630]

2024-05-01 Thread Patrick Palka
On Wed, 1 May 2024, Jason Merrill wrote: > On 5/1/24 08:54, Patrick Palka wrote: > > On Thu, 2 May 2024, Nathaniel Shead wrote: > > > > > On Wed, May 01, 2024 at 10:11:20AM -0400, Patrick Palka wrote: > > > > On Wed, 1 May 2024, Nathaniel Shead wr

Re: [PATCH 2/4] c++/modules: Track module purview for deferred instantiations [PR114630]

2024-05-01 Thread Patrick Palka
On Thu, 2 May 2024, Nathaniel Shead wrote: > On Wed, May 01, 2024 at 10:11:20AM -0400, Patrick Palka wrote: > > On Wed, 1 May 2024, Nathaniel Shead wrote: > > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? > > > > &g

Re: [PATCH 3/4] c++/modules: Also track module purview from deferred vtable instantiation [PR114630]

2024-05-01 Thread Patrick Palka
On Wed, 1 May 2024, Nathaniel Shead wrote: > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? LGTM > > -- >8 -- > > Similarly to in the previous commit, templated virtual functions are > sometimes not instantiated until after parsing has completed. This > means that any new

Re: [PATCH 2/4] c++/modules: Track module purview for deferred instantiations [PR114630]

2024-05-01 Thread Patrick Palka
On Wed, 1 May 2024, Nathaniel Shead wrote: > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? > > -- >8 -- > > When calling instantiate_pending_templates at end of parsing, any new > functions that are instantiated from this point have their module > purview set based on the

Re: [PATCH] c++/modules: Fix dangling pointer with imported_temploid_friends

2024-05-01 Thread Patrick Palka
On Wed, 1 May 2024, Nathaniel Shead wrote: > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk (and > later 14.2)? I don't think making it a GTY root is necessary but I felt > perhaps better to be safe than sorry. > > Potentially another approach would be to use DECL_UID instead

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

2024-04-29 Thread Patrick Palka
Lightly tested on x86_64-pc-linux-gnu so far, does this look OK for trunk/14.1 after bootstrap+regtest finishes? -- >8 -- We're missing a dependence check for the second operand in the sizeof / sizeof handling. PR c++/114888 gcc/cp/ChangeLog: * typeck.cc (cp_build_binary_op) :

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

2024-04-29 Thread Patrick Palka
Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps 14 (I guess after 14.1 is released)? -- >8 -- We need to look through TEMPLATE_DECL like make_friend_class does when adding to CLASSTYPE_BEFRIENDING_CLASSES. Otherwise in the below testcase we won't add _Hashtable to

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

2024-04-26 Thread Patrick Palka
On Thu, 25 Apr 2024, David Malcolm wrote: > On Wed, 2024-04-24 at 17:05 -0400, Patrick Palka wrote: > > On Wed, 24 Apr 2024, Jason Merrill wrote: > > > > > On 4/24/24 13:22, Patrick Palka wrote: > > > > Tested on x86_64-pc-linux-gnu, full bootstrap+regte

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

2024-04-24 Thread Patrick Palka
On Wed, 24 Apr 2024, Jason Merrill wrote: > 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

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

2024-04-24 Thread Patrick Palka
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_show_locus in

Re: [PATCH] c++: print source code in print_instantiation_partial_context_line

2024-04-24 Thread Patrick Palka
On Wed, 24 Apr 2024, Patrick Palka wrote: > On Tue, 9 Apr 2024, Patrick Palka wrote: > > > On Thu, 19 Oct 2023, Patrick Palka wrote: > > > > > On Tue, 3 Oct 2023, David Malcolm wrote: > > > > > > > As mentioned in my Cauldron talk, this pa

Re: [PATCH] c++: print source code in print_instantiation_partial_context_line

2024-04-24 Thread Patrick Palka
On Tue, 9 Apr 2024, Patrick Palka wrote: > On Thu, 19 Oct 2023, Patrick Palka wrote: > > > On Tue, 3 Oct 2023, David Malcolm wrote: > > > > > As mentioned in my Cauldron talk, this patch adds a call to > > > diagnostic_show_locus

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

2024-04-24 Thread Patrick Palka
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 testing GC-safety. A

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

2024-04-23 Thread Patrick Palka
Tested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- The below testcase uses --param=ggc-min-expand=0 which forces a full GC during every collection point and in turn takes over two minutes to run and ends up being the main bottleneck of the modules.exp testsuite. This patch

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

2024-04-23 Thread Patrick Palka
On Tue, 23 Apr 2024, 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

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

2024-04-23 Thread Patrick Palka
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 propagate the deduced type since once we

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

2024-04-22 Thread Patrick Palka
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/13/12? -- >8 -- The object/offset canonicalization performed in cxx_fold_indirect_ref is undesirable for union member accesses because it loses information about the member being accessed which we may later need to

[PATCH] libstdc++: Implement ranges::concat_view from P2542R7

2024-04-22 Thread Patrick Palka
Tested on x86_64-pc-linux-gnu, does this look OK for trunk? More tests are needed but I figured I'd submit this now for possible consideration into GCC 14 since we're getting close to release.. All changes are confined to C++26. -- >8 -- libstdc++-v3/ChangeLog: *

Re: [pushed] c++/modules: make bits_in/out move-constructible

2024-04-22 Thread Patrick Palka
On Mon, 22 Apr 2024, Christophe Lyon wrote: > Hi Patrick, > > On Sat, 13 Apr 2024 at 22:12, Patrick Palka wrote: > > > > Pushed as obvious after verifying C++11 bootstrap is restored. > > I guess this also fixes the bootstrap_ubsan breakage on aarch64 > repo

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

2024-04-21 Thread Patrick Palka
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++/114078 > >

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

2024-04-21 Thread Patrick Palka
> 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_specifiers.type is null.

Re: [PATCH] libstdc++: Fix std::ranges::iota is not included in numeric [PR108760]

2024-04-18 Thread Patrick Palka
On Wed, 17 Apr 2024, Michael Levine (BLOOMBERG/ 919 3RD A) wrote: > This patch fixes GCC Bug 108760: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108760 > Before this patch, using std::ranges::iota required including > when it should have been sufficient to only include . > > When the patch

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

2024-04-17 Thread Patrick Palka
On Mon, 15 Apr 2024, Nathaniel Shead wrote: > I'm not a huge fan of always streaming 'imported_temploid_friends' for > all decls, but I don't think it adds much performance cost over adding a > new flag to categorise decls that might be marked as such. IIUC this value is going to be almost

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

2024-04-17 Thread Patrick Palka
On Mon, 15 Apr 2024, 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 another > followup patch to actually handle them correctly. >

[pushed] c++/modules: make bits_in/out move-constructible

2024-04-13 Thread Patrick Palka
Pushed as obvious after verifying C++11 bootstrap is restored. -- >8 -- gcc/cp/ChangeLog: * module.cc (struct bytes_in::bits_in): Define defaulted move ctor. (struct bytes_out::bits_out): Likewise. --- gcc/cp/module.cc | 2 ++ 1 file changed, 2 insertions(+) diff --git

Re: [PATCH] c++/modules: optimize tree flag streaming

2024-04-13 Thread Patrick Palka
On Sat, 13 Apr 2024, Iain Sandoe wrote: > Hi Patrick, > > > On 10 Apr 2024, at 17:33, Jason Merrill wrote: > > > > On 4/10/24 11:26, Patrick Palka wrote: > >> On Wed, 10 Apr 2024, Patrick Palka wrote: > >>> > >>> On Tue, 9 Apr 2024, Jas

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

2024-04-12 Thread Patrick Palka
On Fri, 12 Apr 2024, Jason Merrill wrote: > 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: > > > > &g

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

2024-04-12 Thread Patrick Palka
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: > > > >

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

2024-04-12 Thread Patrick Palka
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: > > > >

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

2024-04-12 Thread Patrick Palka
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: > > > > > >

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

2024-04-12 Thread Patrick Palka
On Wed, 10 Apr 2024, Jason Merrill wrote: > On 3/27/24 10:01, Patrick Palka wrote: > > On Mon, 25 Mar 2024, Patrick Palka wrote: > > > On Mon, 25 Mar 2024, Patrick Palka wrote: > > > > > > > > The below testcases use a lambda-expr as a template argumen

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

2024-04-12 Thread Patrick Palka
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- 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

Re: [PATCH] c++: recalculating local specs via build_extra_args [PR114303]

2024-04-10 Thread Patrick Palka
On Wed, 10 Apr 2024, Jason Merrill wrote: > On 4/10/24 17:39, Patrick Palka wrote: > > On Wed, 10 Apr 2024, Jason Merrill wrote: > > > > > On 3/12/24 10:51, Patrick Palka wrote: > > > > On Tue, 12 Mar 2024, Patrick Palka wrote: > > > > > On Tue,

Re: [PATCH] c++: recalculating local specs via build_extra_args [PR114303]

2024-04-10 Thread Patrick Palka
On Wed, 10 Apr 2024, Jason Merrill wrote: > On 3/12/24 10:51, Patrick Palka wrote: > > On Tue, 12 Mar 2024, Patrick Palka wrote: > > > On Tue, 12 Mar 2024, Jason Merrill wrote: > > > > On 3/11/24 12:53, Patrick Palka wrote: > > > > > > > > &

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

2024-04-10 Thread Patrick Palka
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 [PR99426] > > > > One known missing piece in the modules implementation is m

Re: [PATCH] c++/modules: optimize tree flag streaming

2024-04-10 Thread Patrick Palka
On Wed, 10 Apr 2024, Patrick Palka wrote: > > On Tue, 9 Apr 2024, Jason Merrill wrote: > > > On 2/16/24 10:06, Patrick Palka wrote: > > > On Thu, 15 Feb 2024, Patrick Palka wrote: > > > > > > > One would expect consecutive calls to bytes_in/out::b

Re: [PATCH] c++/modules: optimize tree flag streaming

2024-04-10 Thread Patrick Palka
On Tue, 9 Apr 2024, Jason Merrill wrote: > On 2/16/24 10:06, Patrick Palka wrote: > > On Thu, 15 Feb 2024, Patrick Palka wrote: > > > > > One would expect consecutive calls to bytes_in/out::b for streaming > > > adjacent bits, as we do for tree flag streamin

Re: [PATCH] c++/modules: optimize tree flag streaming

2024-04-09 Thread Patrick Palka
On Tue, 26 Mar 2024, Patrick Palka wrote: > On Tue, 27 Feb 2024, Patrick Palka wrote: > > > On Fri, 16 Feb 2024, Patrick Palka wrote: > > > > > On Thu, 15 Feb 2024, Patrick Palka wrote: > > > > > > > Bootstrapped and regtested on x86_64-p

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

2024-04-09 Thread Patrick Palka
On Tue, 26 Mar 2024, Patrick Palka wrote: > On Tue, 5 Mar 2024, Patrick Palka wrote: > > > On Tue, 27 Feb 2024, Patrick Palka wrote: > > > > > On Mon, 26 Feb 2024, Patrick Palka wrote: > > > > > > > Bootstrapped and regtested on x86_64-pc-linux

Re: [PATCH] c++: recalculating local specs via build_extra_args [PR114303]

2024-04-09 Thread Patrick Palka
On Tue, 26 Mar 2024, Patrick Palka wrote: > On Mon, 11 Mar 2024, Patrick Palka wrote: > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look > > OK for trunk and release branches? > > Ping. Ping. > > > > > -- >8 -- > > &g

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

2024-04-09 Thread Patrick Palka
On Wed, 27 Mar 2024, Patrick Palka wrote: > On Mon, 25 Mar 2024, Patrick Palka wrote: > > > On Mon, 25 Mar 2024, Patrick Palka wrote: > > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK > > > for trunk? > > > > &

Re: [PATCH] c++: print source code in print_instantiation_partial_context_line

2024-04-09 Thread Patrick Palka
On Thu, 19 Oct 2023, Patrick Palka wrote: > On Tue, 3 Oct 2023, David Malcolm wrote: > > > As mentioned in my Cauldron talk, this patch adds a call to > > diagnostic_show_locus to the "required from here" messages > > in print_instantiation_partial_context_l

Re: [PATCH] libstdc++: Allow adjacent __maybe_present_t to overlap

2024-04-02 Thread Patrick Palka
On Tue, 2 Apr 2024, Jonathan Wakely wrote: > On Tue, 2 Apr 2024 at 18:00, Pilar Latiesa wrote: > > > > Just out of curiosity: would this also work? > > > > template > > struct _Absent {}; > > > > template > > using __maybe_present_t = __conditional_t<_Present, _Tp, _Absent<_Tp, > > _Disc>>; > >

[PATCH] libstdc++: Allow adjacent __maybe_present_t to overlap

2024-04-01 Thread Patrick Palka
Tested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- Currently __maybe_present_t maps to the same empty class type independent of T. This is suboptimal because it means adjacent __maybe_present_t members with the [[no_unique_address]] attribute can't overlap even if the

Re: [PATCH] c++: Keep DECL_SAVED_TREE of destructor instantiations in modules [PR104040]

2024-03-29 Thread Patrick Palka
On Fri, 29 Mar 2024, Nathaniel Shead wrote: > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? LGTM > > -- >8 -- > > A template instantiation still needs to have its DECL_SAVED_TREE so that > its definition is emitted into the CMI. This way it can be emitted in > the object

Re: [PATCH] c++: fix alias CTAD [PR114377]

2024-03-27 Thread Patrick Palka
On Mon, 25 Mar 2024, centurion wrote: > From b34312d82b236601c348382d30e625558f37d40c Mon Sep 17 00:00:00 2001 > From: centurion > Date: Mon, 25 Mar 2024 01:57:21 +0400 > Subject: [PATCH] c++: fix alias CTAD [PR114377] > > PR c++/114377 > > gcc/cp/ChangeLog: > > PR c++/114377 > *

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

2024-03-27 Thread Patrick Palka
On Mon, 25 Mar 2024, Patrick Palka wrote: > On Mon, 25 Mar 2024, Patrick Palka wrote: > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK > > for trunk? > > > > -- >8 -- > > > > The below testcases use a lambda-expr as a

Re: [PATCH] libstdc++/ranges: Define _S_has_simple_call_op on newer adaptors

2024-03-27 Thread Patrick Palka
On Wed, 17 Jan 2024, Jonathan Wakely wrote: > > > On Wed, 17 Jan 2024, 02:37 Patrick Palka, wrote: > Tested on x86_64-pc-linux-gnu, does this look OK for trunk? > > > OK Thanks a lot. For the record I ended up not pushing this patch because all the range adaptors

Re: [PATCH] c++/modules: optimize tree flag streaming

2024-03-26 Thread Patrick Palka
On Tue, 27 Feb 2024, Patrick Palka wrote: > On Fri, 16 Feb 2024, Patrick Palka wrote: > > > On Thu, 15 Feb 2024, Patrick Palka wrote: > > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look > > > OK for trunk? > > > > > &

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

2024-03-26 Thread Patrick Palka
On Tue, 5 Mar 2024, Patrick Palka wrote: > On Tue, 27 Feb 2024, Patrick Palka wrote: > > > On Mon, 26 Feb 2024, Patrick Palka wrote: > > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this approach > > > look reasonable? > > > > &

Re: [PATCH] c++: recalculating local specs via build_extra_args [PR114303]

2024-03-26 Thread Patrick Palka
On Mon, 11 Mar 2024, Patrick Palka wrote: > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look > OK for trunk and release branches? Ping. > > -- >8 -- > > r13-6452-g341e6cd8d603a3 made build_extra_args walk evaluated contexts > first so that we p

[pushed] c++/modules testsuite: fix a couple of dg-module-do directives

2024-03-26 Thread Patrick Palka
Tested on x86_64-pc-linux-gnu, committed to trunk as obvious. -- >8 -- gcc/testsuite/ChangeLog: * g++.dg/modules/decltype-1_a.C: Add missing } to dg-module-do directive. * g++.dg/modules/lambda-5_a.C: Likewise. --- gcc/testsuite/g++.dg/modules/decltype-1_a.C | 2 +-

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

2024-03-26 Thread Patrick Palka
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: &g

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

2024-03-25 Thread Patrick Palka
On Mon, 25 Mar 2024, Patrick Palka wrote: > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK > for trunk? > > -- >8 -- > > The below testcases use a lambda-expr as a template argument and they > all trip over the below added tsubst_lambda_expr

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

2024-03-25 Thread Patrick Palka
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- The below testcases use a lambda-expr as a template argument and they all trip over the below added tsubst_lambda_expr sanity check ultimately because current_template_parms is empty, which causes

Re: [PATCH] c++: ICE with noexcept and local specialization [PR114114]

2024-03-15 Thread Patrick Palka
On Fri, 15 Mar 2024, Marek Polacek wrote: > On Fri, Mar 15, 2024 at 10:35:07AM -0400, Patrick Palka wrote: > > On Tue, 5 Mar 2024, Marek Polacek wrote: > > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > > >

Re: [PATCH] c++: ICE with noexcept and local specialization [PR114114]

2024-03-15 Thread Patrick Palka
On Tue, 5 Mar 2024, Marek Polacek wrote: > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > -- >8 -- > Here we ICE because we call register_local_specialization while > local_specializations is null, so > > local_specializations->put (); > > crashes on null this. It's null

Re: [PATCH] c++: recalculating local specs via build_extra_args [PR114303]

2024-03-12 Thread Patrick Palka
On Tue, 12 Mar 2024, Patrick Palka wrote: > On Tue, 12 Mar 2024, Jason Merrill wrote: > > > On 3/11/24 12:53, Patrick Palka wrote: > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look > > > OK for trunk and release branches? > > >

Re: [PATCH] c++: recalculating local specs via build_extra_args [PR114303]

2024-03-12 Thread Patrick Palka
On Tue, 12 Mar 2024, Jason Merrill wrote: > On 3/11/24 12:53, Patrick Palka wrote: > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look > > OK for trunk and release branches? > > > > -- >8 -- > > > > r13-6452-g341e6cd8d603a3 mad

Re: [PATCH v2] c++: Support target-specific nodes with streaming [PR98645,PR111224]

2024-03-12 Thread Patrick Palka
On Tue, 12 Mar 2024, Nathaniel Shead wrote: > On Tue, Mar 12, 2024 at 11:11:40PM +1100, Nathaniel Shead wrote: > > On Mon, Mar 11, 2024 at 10:36:06AM -0400, Patrick Palka wrote: > > > On Sun, 10 Mar 2024, Nathaniel Shead wrote: > > > > > > > Bootstrapp

[PATCH] c++: recalculating local specs via build_extra_args [PR114303]

2024-03-11 Thread Patrick Palka
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk and release branches? -- >8 -- r13-6452-g341e6cd8d603a3 made build_extra_args walk evaluated contexts first so that we prefer processing a local specialization in an evaluated context even if its first use is in an

Re: [PATCH] c++/modules: Support target-specific nodes with streaming [PR111224]

2024-03-11 Thread Patrick Palka
On Sun, 10 Mar 2024, Nathaniel Shead wrote: > Bootstrapped and regtested on x86_64-pc-linux-gnu and > aarch64-unknown-linux-gnu, OK for trunk? > > It's worth noting that the AArch64 machines I had available to test with > didn't have a new enough glibc to reproduce the ICEs in the PR, but this >

Re: [PATCH v14 26/26] libstdc++: Optimize std::is_nothrow_invocable compilation performance

2024-03-08 Thread Patrick Palka
On Wed, 28 Feb 2024, Ken Matsui wrote: > This patch optimizes the compilation performance of > std::is_nothrow_invocable by dispatching to the new > __is_nothrow_invocable built-in trait. > > libstdc++-v3/ChangeLog: > > * include/std/type_traits (is_nothrow_invocable): Use >

  1   2   3   4   5   6   7   8   9   10   >