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 +-
https://gcc.gnu.org/g:2f47ca046eecf8f2fcae23df3ccee44d943ef512
commit r14-9673-g2f47ca046eecf8f2fcae23df3ccee44d943ef512
Author: Patrick Palka
Date: Tue Mar 26 10:21:53 2024 -0400
c++/modules testsuite: fix a couple of dg-module-do directives
gcc/testsuite/ChangeLog
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
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
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
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?
> > >
> > >
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
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?
> > >
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
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
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
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
>
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
>
On Wed, 28 Feb 2024, Ken Matsui wrote:
> This patch implements built-in trait for std::is_invocable.
>
> gcc/cp/ChangeLog:
>
> * cp-trait.def: Define __is_invocable.
> * constraint.cc (diagnose_trait_expr): Handle CPTK_IS_INVOCABLE.
> * semantics.cc (trait_expr_value):
On Wed, 28 Feb 2024, Ken Matsui wrote:
> This patch implements a --num-commits (-n) flag for shorthand for
> the range of hash~N..hash commits.
>
> contrib/ChangeLog:
>
> * gcc-changelog/git_check_commit.py: Implement --num-commits.
LGTM
>
> Signed-off-by: Ken Matsui
> ---
>
Hi Ken,
This patch series LGTM, thanks for these documentation improvements.
On Fri, 1 Mar 2024, Ken Matsui wrote:
> This patch sorts built-in traits alphabetically for better codebase
> consistency and easier future integration of changes.
>
> gcc/ChangeLog:
>
> * doc/extend.texi (Type
https://gcc.gnu.org/g:f5c1224708a0cf9cc2770c44bbbe7d0c883942be
commit r14-9374-gf5c1224708a0cf9cc2770c44bbbe7d0c883942be
Author: Patrick Palka
Date: Thu Mar 7 16:39:20 2024 -0500
c++/modules: member alias tmpl partial inst [PR103994]
Alias templates are weird
https://gcc.gnu.org/g:0552560f6d2eaa1ae6df5c80660b489de1d5c772
commit r14-9372-g0552560f6d2eaa1ae6df5c80660b489de1d5c772
Author: Patrick Palka
Date: Thu Mar 7 16:23:22 2024 -0500
c++/modules: inline namespace abi_tag streaming [PR110730]
The unreduced testcase from PR110730
On Mon, 29 Jan 2024, Patrick Palka wrote:
> On Mon, 29 Jan 2024, Patrick Palka wrote:
>
> > On Fri, 26 Jan 2024, Jason Merrill wrote:
> >
> > > On 1/26/24 17:11, Jason Merrill wrote:
> > > > On 1/26/24 16:52, Jason Merrill wrote:
> >
On Thu, 7 Mar 2024, Jason Merrill wrote:
> On 3/7/24 14:41, Patrick Palka wrote:
> > On Thu, 7 Mar 2024, Patrick Palka wrote:
> >
> > > On Wed, 6 Mar 2024, Jason Merrill wrote:
> > >
> > > > On 3/4/24 17:26, Patrick Palka wrote:
> > > >
On Thu, 7 Mar 2024, Patrick Palka wrote:
> On Wed, 6 Mar 2024, Jason Merrill wrote:
>
> > On 3/4/24 17:26, Patrick Palka wrote:
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > > OK for trunk?
> > >
> > >
On Wed, 6 Mar 2024, Jason Merrill wrote:
> On 3/4/24 17:26, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > OK for trunk?
> >
> > -- >8 --
> >
> > Alias templates are weird in that their specializations c
On Wed, 6 Mar 2024, Jason Merrill wrote:
> On 3/6/24 14:10, Patrick Palka wrote:
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> >
> > -- >8 --
> >
> > The unreduced testcase from this PR crashes at runtime ultimately
> > because we do
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
The unreduced testcase from this PR crashes at runtime ultimately
because we don't stream the abi_tag attribute on inline namespaces and
so the filesystem::current_path() call resolves to the non-C++11 ABI
version even though
https://gcc.gnu.org/g:b0d11bb02a4a4c7d61e9b53411ccdc54610b1429
commit r14-9327-gb0d11bb02a4a4c7d61e9b53411ccdc54610b1429
Author: Patrick Palka
Date: Tue Mar 5 20:36:36 2024 -0500
c++/modules: befriending template from current class scope
Here the TEMPLATE_DECL representing
On Mon, 26 Feb 2024, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> OK for trunk?
Ping.
>
> -- >8 --
>
> Here the TEMPLATE_DECL representing the template friend declaration for
> B has class scope since B has class scope, bu
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?
> >
> > -- >8 --
> >
> > One known missing piece in the module
On Tue, 5 Mar 2024, Nathaniel Shead wrote:
> On Mon, Mar 04, 2024 at 10:07:33PM -0500, Patrick Palka wrote:
> > On Tue, 5 Mar 2024, Nathaniel Shead wrote:
> >
> > > On Mon, Mar 04, 2024 at 09:26:00PM -0500, Patrick Palka wrote:
> > > > On Tu
On Tue, 5 Mar 2024, Nathaniel Shead wrote:
> On Mon, Mar 04, 2024 at 09:26:00PM -0500, Patrick Palka wrote:
> > On Tue, 5 Mar 2024, Nathaniel Shead wrote:
> >
> > > On Mon, Mar 04, 2024 at 07:14:54PM -0500, Patrick Palka wrote:
> > > > On Sa
On Tue, 5 Mar 2024, Nathaniel Shead wrote:
> On Mon, Mar 04, 2024 at 07:14:54PM -0500, Patrick Palka wrote:
> > On Sat, 2 Mar 2024, Nathaniel Shead wrote:
> >
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> > >
> > > -- >
On Sat, 2 Mar 2024, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
>
> -- >8 --
>
> When streaming in a nested template-template parameter as in the
> attached testcase, we end up reaching the containing template-template
> parameter in
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
Alias templates are weird in that their specializations can appear in
both decl_specializations and type_specializations. They appear in the
latter only at parse time via finish_template_type. This should
On Fri, 1 Mar 2024, Jason Merrill wrote:
> On 3/1/24 14:24, Marek Polacek wrote:
> > On Fri, Mar 01, 2024 at 01:19:40PM -0500, Jason Merrill wrote:
> > > On 3/1/24 12:39, Marek Polacek wrote:
> > > >@option{-Wdangling-reference} also warns about code like
> > > >@smallexample
> > > > @@
On Fri, 1 Mar 2024, Jason Merrill wrote:
> On 3/1/24 13:28, Patrick Palka wrote:
> > On Fri, 1 Mar 2024, Jason Merrill wrote:
> >
> > > On 3/1/24 12:08, Patrick Palka wrote:
> > > > On Fri, 1 Mar 2024, Patrick Palka wrote:
> > > >
&
On Fri, 1 Mar 2024, Jason Merrill wrote:
> On 3/1/24 12:08, Patrick Palka wrote:
> > On Fri, 1 Mar 2024, Patrick Palka wrote:
> >
> > > On Fri, 1 Mar 2024, Jason Merrill wrote:
> > >
> > > > On 3/1/24 10:00, Patrick Palka wrote:
>
On Fri, 1 Mar 2024, Patrick Palka wrote:
> On Fri, 1 Mar 2024, Jason Merrill wrote:
>
> > On 3/1/24 10:00, Patrick Palka wrote:
> > > On Fri, 1 Mar 2024, Jason Merrill wrote:
> > >
> > > > On 2/29/24 15:56, Patrick Palka wrote:
> > > > >
On Fri, 1 Mar 2024, Jason Merrill wrote:
> On 3/1/24 10:32, Jason Merrill wrote:
> > On 3/1/24 10:00, Patrick Palka wrote:
> > > On Fri, 1 Mar 2024, Jason Merrill wrote:
> > >
> > > > On 2/29/24 15:56, Patrick Palka wrote:
> > > > > B
On Fri, 1 Mar 2024, Jason Merrill wrote:
> On 3/1/24 10:00, Patrick Palka wrote:
> > On Fri, 1 Mar 2024, Jason Merrill wrote:
> >
> > > On 2/29/24 15:56, Patrick Palka wrote:
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> >
On Fri, 1 Mar 2024, Jason Merrill wrote:
> On 2/29/24 14:17, Patrick Palka wrote:
> > On Wed, 28 Feb 2024, Jason Merrill wrote:
> > > I wonder about, rather than returning it directly, setting its level to 1
> > > for
> > > the substitution?
> >
>
On Fri, 1 Mar 2024, Jason Merrill wrote:
> On 2/29/24 15:56, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > OK for trunk?
> >
> > -- >8 --
> >
> > For local enums defined in a non-template function or a fu
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
For local enums defined in a non-template function or a function template
instantiation it seems we neglect to make the function depend on the enum
definition, which ultimately causes streaming to fail due
1 - 100 of 2174 matches
Mail list logo
