https://gcc.gnu.org/g:58b8c87b7fb281e35a6817cc91a292096fdc02dc
commit r15-892-g58b8c87b7fb281e35a6817cc91a292096fdc02dc
Author: Patrick Palka
Date: Wed May 29 04:49:37 2024 -0400
c++: canonicity of fn types w/ instantiated eh specs [PR115223]
When propagating structural equality
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
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
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.
> *
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
>
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
https://gcc.gnu.org/g:66d2a76dcf625f8dbe43d3c512e9c43f588fdc25
commit r15-809-g66d2a76dcf625f8dbe43d3c512e9c43f588fdc25
Author: Patrick Palka
Date: Thu May 23 18:03:56 2024 -0400
libstdc++: Implement ranges::concat_view from P2542R7
libstdc++-v3/ChangeLog
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
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
https://gcc.gnu.org/g:3c98d06a9016a0fa3a806879bd168f13b8a606f8
commit r15-779-g3c98d06a9016a0fa3a806879bd168f13b8a606f8
Author: Patrick Palka
Date: Wed May 22 17:45:04 2024 -0400
c++: canonicity of fn types w/ complex eh specs [PR115159]
Here the member functions QList::g
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
On Tue, 21 May 2024, Jason Merrill wrote:
> On 5/21/24 21:55, Patrick Palka wrote:
> > On Tue, 21 May 2024, Jason Merrill wrote:
> >
> > > On 5/21/24 17:27, Patrick Palka wrote:
> > > > On Tue, 21 May 2024, Jason Merrill wrote:
> > > >
On 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,
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
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
https://gcc.gnu.org/g:caf43cc9e5c0b3265b55e5a0dc77fc55e9618c77
commit r14-10226-gcaf43cc9e5c0b3265b55e5a0dc77fc55e9618c77
Author: Patrick Palka
Date: Tue May 21 15:54:10 2024 -0400
c++: folding non-dep enumerator from current inst [PR115139]
After the tsubst_copy removal r14-4796
https://gcc.gnu.org/g:f0c0bced62b9c728ed1e672747aa234d918da22c
commit r15-759-gf0c0bced62b9c728ed1e672747aa234d918da22c
Author: Patrick Palka
Date: Tue May 21 15:54:10 2024 -0400
c++: folding non-dep enumerator from current inst [PR115139]
After the tsubst_copy removal r14-4796
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
https://gcc.gnu.org/g:a9837934203d41c96b5cf05e34f68c0d3311c973
commit r14-10221-ga9837934203d41c96b5cf05e34f68c0d3311c973
Author: Patrick Palka
Date: Fri May 17 09:02:52 2024 -0400
c++: aggregate CTAD w/ paren init and bases [PR115114]
During aggregate CTAD with paren init, we're
https://gcc.gnu.org/g:b3399b445ba7495b0479d43f2389e64d48de870e
commit r14-10220-gb3399b445ba7495b0479d43f2389e64d48de870e
Author: Patrick Palka
Date: Tue May 14 22:55:16 2024 -0400
c++: lvalueness of non-dependent assignment expr [PR114994]
r14-4111-g6e92a6a2a72d3b made us check
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
https://gcc.gnu.org/g:5aaf47cb1987bbc5508c4b9b7dad5ea7d69af2c2
commit r15-630-g5aaf47cb1987bbc5508c4b9b7dad5ea7d69af2c2
Author: Patrick Palka
Date: Fri May 17 09:02:52 2024 -0400
c++: aggregate CTAD w/ paren init and bases [PR115114]
During aggregate CTAD with paren init, we're
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.
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
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
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
https://gcc.gnu.org/g:c6cc6d4741a880109c4e0e64d5a189687fb526f6
commit r15-498-gc6cc6d4741a880109c4e0e64d5a189687fb526f6
Author: Patrick Palka
Date: Tue May 14 22:55:16 2024 -0400
c++: lvalueness of non-dependent assignment expr [PR114994]
r14-4111-g6e92a6a2a72d3b made us check
https://gcc.gnu.org/g:47cac09307874ff1d640392e3d986453f34f7bcb
commit r13-8767-g47cac09307874ff1d640392e3d986453f34f7bcb
Author: Patrick Palka
Date: Thu Apr 11 10:16:41 2024 -0400
c++: build_extra_args recapturing local specs [PR114303]
r13-6452-g341e6cd8d603a3 made
https://gcc.gnu.org/g:67476ba8adb432033993f429b1aa4ee5689fa046
commit r15-438-g67476ba8adb432033993f429b1aa4ee5689fa046
Author: Patrick Palka
Date: Mon May 13 15:46:55 2024 -0400
c++: replace tf_norm with a local flag
The tf_norm flag controlling whether to build diagnostic
https://gcc.gnu.org/g:d3659e2dfcc6db83391cd2c6d70097cba35eb4b9
commit r13-8765-gd3659e2dfcc6db83391cd2c6d70097cba35eb4b9
Author: Patrick Palka
Date: Wed Apr 24 17:49:56 2024 -0400
c++: constexpr union member access folding [PR114709]
The object/offset canonicalization performed
https://gcc.gnu.org/g:57cd8665fea4c339369a43be017583621aa82fed
commit r14-10201-g57cd8665fea4c339369a43be017583621aa82fed
Author: Patrick Palka
Date: Mon May 13 09:53:40 2024 -0400
c++: nested aggregate/alias CTAD fixes [PR114974, PR114901, PR114903]
During maybe_aggr_guide
https://gcc.gnu.org/g:6d31a370e26eeb950c326332633b3e8e84b6630b
commit r15-434-g6d31a370e26eeb950c326332633b3e8e84b6630b
Author: Patrick Palka
Date: Mon May 13 09:53:40 2024 -0400
c++: nested aggregate/alias CTAD fixes [PR114974, PR114901, PR114903]
During maybe_aggr_guide
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
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
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
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
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
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
https://gcc.gnu.org/g:390bd23fd9c98dc40856beef05364f5d1c7b9d04
commit r14-10176-g390bd23fd9c98dc40856beef05364f5d1c7b9d04
Author: Patrick Palka
Date: Mon Apr 29 21:27:59 2024 -0400
c++/modules: imported spec befriending class tmpl [PR114889]
When adding
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
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
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
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
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
> >
https://gcc.gnu.org/g:f04dc89a991ddc6c08ac92c8ad29c6915c4ecafa
commit r15-123-gf04dc89a991ddc6c08ac92c8ad29c6915c4ecafa
Author: Patrick Palka
Date: Thu May 2 21:14:30 2024 -0400
c++: remove lookup_template_class's entering_scope flag
lookup_template_class's entering_scope flag
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:
> > > >
> > >
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
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
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:
> > >
>
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
https://gcc.gnu.org/g:c70abea054fe0021b7b2c2e07996afaadc17a07b
commit r13-8670-gc70abea054fe0021b7b2c2e07996afaadc17a07b
Author: Patrick Palka
Date: Wed May 1 18:16:08 2024 -0400
c++: problematic assert in reference_binding [PR113141]
r14-9946 / r14-9947 fixed this PR properly
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:
> > > >
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
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
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
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
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
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
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
https://gcc.gnu.org/g:22b20ac6c6aead2d3f36c413a77dd0b80adfec39
commit r15-57-g22b20ac6c6aead2d3f36c413a77dd0b80adfec39
Author: Patrick Palka
Date: Mon Apr 29 21:27:59 2024 -0400
c++/modules: imported spec befriending class tmpl [PR114889]
When adding
https://gcc.gnu.org/g:3c925ac349b03ae9439c632fb1c042cdc8d78f40
commit r14-10149-g3c925ac349b03ae9439c632fb1c042cdc8d78f40
Author: Patrick Palka
Date: Mon Apr 29 21:14:18 2024 -0400
c++: ICE with templated sizeof(E1) / sizeof(E2) [PR114888]
In the sizeof / sizeof operator
https://gcc.gnu.org/g:3900e944b0ac9db77380c5bb8635977dfd3b0691
commit r15-56-g3900e944b0ac9db77380c5bb8635977dfd3b0691
Author: Patrick Palka
Date: Mon Apr 29 21:14:18 2024 -0400
c++: ICE with templated sizeof(E1) / sizeof(E2) [PR114888]
In the sizeof / sizeof operator expression
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) :
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
https://gcc.gnu.org/g:c014cfd8853240827feb3a4cef92403e83cd4265
commit r14-10140-gc014cfd8853240827feb3a4cef92403e83cd4265
Author: Patrick Palka
Date: Fri Apr 26 07:44:25 2024 -0400
c++: fix source printing for "required from here" message
It seems the diagnostic m
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
https://gcc.gnu.org/g:7d5479a2ecf6309281de10b747a7423169a2ff95
commit r15-4-g7d5479a2ecf6309281de10b747a7423169a2ff95
Author: Patrick Palka
Date: Fri Apr 26 07:44:25 2024 -0400
c++: fix source printing for "required from here" message
It seems the diagnostic machiner
https://gcc.gnu.org/g:26a3edbe2357cf975f345ad1b59b9f9a3444316e
commit r14-10111-g26a3edbe2357cf975f345ad1b59b9f9a3444316e
Author: Patrick Palka
Date: Wed Apr 24 17:51:54 2024 -0400
c++/modules testsuite: restrict expensive pr99023 test
The pr99023 testcase uses --param=ggc-min
https://gcc.gnu.org/g:0844170e9ef60a8b2f6fba6786672f30ce1c2749
commit r14-10110-g0844170e9ef60a8b2f6fba6786672f30ce1c2749
Author: Patrick Palka
Date: Wed Apr 24 17:49:56 2024 -0400
c++: constexpr union member access folding [PR114709]
The object/offset canonicalization performed
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
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
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
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
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
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
https://gcc.gnu.org/g:4f9401d1a802325e5dfa2db841945e1a9c59a980
commit r14-10096-g4f9401d1a802325e5dfa2db841945e1a9c59a980
Author: Patrick Palka
Date: Tue Apr 23 14:01:22 2024 -0400
c++/modules: deduced return type merging [PR114795]
When merging an imported function template
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
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
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
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:
*
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
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
>
>
> 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.
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
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
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.
>
https://gcc.gnu.org/g:38c2679ff9330d3ac1d5d86459294446733a435a
commit r13-8608-g38c2679ff9330d3ac1d5d86459294446733a435a
Author: Patrick Palka
Date: Fri Feb 2 19:07:08 2024 -0500
c++: requires-exprs and partial constraint subst [PR110006]
In r11-3261-gb28b621ac67bee we made
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
https://gcc.gnu.org/g:da375baf54944298303f13c375a5756c6131d672
commit r14-9956-gda375baf54944298303f13c375a5756c6131d672
Author: Patrick Palka
Date: Sat Apr 13 16:06:28 2024 -0400
c++/modules: make bits_in/out move-constructible
gcc/cp/ChangeLog:
* module.cc
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
https://gcc.gnu.org/g:436ab7e8e8b16866d8a807af242560ad4fdff0d6
commit r14-9955-g436ab7e8e8b16866d8a807af242560ad4fdff0d6
Author: Patrick Palka
Date: Sat Apr 13 10:52:32 2024 -0400
c++/modules: optimize tree flag streaming
One would expect consecutive calls to bytes_in/out::b
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
https://gcc.gnu.org/g:716af95fd454871473c4b118b8412b6a68459b75
commit r14-9948-g716af95fd454871473c4b118b8412b6a68459b75
Author: Patrick Palka
Date: Fri Apr 12 15:50:04 2024 -0400
c++/modules: local type merging [PR99426]
One known missing piece in the modules implementation
https://gcc.gnu.org/g:d74fe10b13336b9de2e025ced4af00a25ff1d3e7
commit r14-9943-gd74fe10b13336b9de2e025ced4af00a25ff1d3e7
Author: Patrick Palka
Date: Fri Apr 12 14:52:31 2024 -0400
c++: templated substitution into lambda-expr, cont [PR114393]
The original PR114393 testcase
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 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 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:
> > > >
> >
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
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
https://gcc.gnu.org/g:081c1e93d56d35c7314ed68e6d87628b430de917
commit r14-9938-g081c1e93d56d35c7314ed68e6d87628b430de917
Author: Patrick Palka
Date: Fri Apr 12 08:59:27 2024 -0400
c++: templated substitution into lambda-expr [PR114393]
The below testcases use a lambda-expr
1 - 100 of 2236 matches
Mail list logo