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
https://gcc.gnu.org/g:b262b17636e47ae969a74f16e86ccb00678d5e88
commit r14-9916-gb262b17636e47ae969a74f16e86ccb00678d5e88
Author: Patrick Palka
Date: Thu Apr 11 10:16:41 2024 -0400
c++: build_extra_args recapturing local specs [PR114303]
r13-6452-g341e6cd8d603a3 made
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,
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:
> > > > >
> > > &
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
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
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
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
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
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
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?
> > >
> &
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
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>>;
> >
https://gcc.gnu.org/g:0e64bbb8823f7b3757befc878ed177dfb59943d1
commit r14-9756-g0e64bbb8823f7b3757befc878ed177dfb59943d1
Author: Patrick Palka
Date: Tue Apr 2 13:07:07 2024 -0400
libstdc++: Allow adjacent __maybe_present_t fields to overlap
Currently __maybe_present_t maps
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
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
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
> *
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
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
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?
> > >
> > &
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?
> > >
> &
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
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 +-
1 - 100 of 2214 matches
Mail list logo
