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
On Wed, 28 Feb 2024, Jason Merrill wrote:
> On 2/27/24 15:48, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > OK for trunk and perhaps 13?
> >
> > -- >8 --
> >
> > In r12-6773-g09845ad7569bac we gave CTAD
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk and perhaps 13?
-- >8 --
In r12-6773-g09845ad7569bac we gave CTAD placeholders a level of 0 and
ensured we never replaced them via tsubst. It turns out that autos
representing an explicit cast need the same treatment
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 modules implementation is merging of a
> streamed-in local class with the cor
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?
> >
> > -- >8 --
> >
> > One would expect consecutive calls to bytes_in/
On Thu, 15 Feb 2024, Patrick Palka wrote:
> On Thu, 15 Feb 2024, Jason Merrill wrote:
>
> > On 2/15/24 16:10, Patrick Palka wrote:
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > > OK for trunk?
> > >
> > > -- >
On Fri, 16 Feb 2024, Nathaniel Shead wrote:
> On Tue, Feb 13, 2024 at 07:52:01PM -0500, Jason Merrill wrote:
> > On 2/10/24 17:57, Nathaniel Shead wrote:
> > > The fix for PR107398 weakened the restrictions that lambdas must belong
> > > to namespace scope. However this was not sufficient: we
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this approach
look reasonable?
-- >8 --
One known missing piece in the modules implementation is merging of a
streamed-in local class with the corresponding in-TU version of the
local class. This missing piece turns out to cause a
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
Here during stream-in of the non-exported constexpr var 'a' we call
maybe_register_incomplete_var, which ends up taking the second branch
and pushing {a, NULL_TREE} onto incomplete_vars. We later ICE from
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
Here the TEMPLATE_DECL representing the template friend declaration for
B has class scope since B has class scope, but get_merge_kind assumes
all DECL_UNINSTANTIATED_TEMPLATE_FRIEND_P TEMPLATE_DECL have
t because
that doesn't get set until later from do_decl_instantiation.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2024-02-19 Jakub Jelinek
> Patrick Palka
>
> PR c++/113976
> * decl.cc (grokdeclarator): Don't call
On Wed, 21 Feb 2024, Nathaniel Shead wrote:
> My earlier patch appears to have caused some regressions. I've taken a
> quick look to see if there are obvious workarounds, but given the time
> frame and the fact that I still don't really understand all the details
> of how and when symbols get
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
When partially substituting a requires-expr, we don't want to perform
any additional checks beyond the substitution itself, so as to minimize
checking requirements out of order. So when partially
On Fri, 16 Feb 2024, Marek Polacek wrote:
> On Fri, Feb 16, 2024 at 03:58:02PM -0500, Jason Merrill wrote:
> > On 2/15/24 17:17, Marek Polacek wrote:
> > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > >
> > > By the ??? below I mean that maybe_instantiate_noexcept could
Fixed by the PR113612 fix r14-8960-g19ac327de421fe.
PR c++/111682
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/var-templ86.C: New test.
---
gcc/testsuite/g++.dg/cpp1y/var-templ86.C | 23 +++
1 file changed, 23 insertions(+)
create mode 100644
On Thu, 15 Feb 2024, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> OK for trunk?
>
> -- >8 --
>
> One would expect consecutive calls to bytes_in/out::b for streaming
> adjacent bits, as we do for tree flag streaming, to
On Thu, 15 Feb 2024, Jason Merrill wrote:
> On 2/15/24 16:10, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > OK for trunk?
> >
> > -- >8 --
> >
> > Issuing a hard error when the GMF doesn't contain pr
On Thu, 15 Feb 2024, Ken Matsui wrote:
> This patch implements built-in trait for std::rank.
>
> gcc/cp/ChangeLog:
>
> * cp-trait.def: Define __rank.
> * semantics.cc (trait_expr_value): Handle CPTK_RANK.
> (finish_trait_expr): Likewise.
>
> gcc/testsuite/ChangeLog:
>
>
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
gcc/cp/ChangeLog:
* module.cc (trees_out::core_bools): Stream TREE_UNAVAILABLE.
(trees_in::core_bools): Likewise.
(trees_out::core_vals): Stream LAMBDA_EXPR_REGEN_INFO.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
Issuing a hard error when the GMF doesn't contain preprocessing
directives is inconvenient for automated testcase reduction via cvise.
This patch relaxes this diagnostic into a pedwarn.
gcc/cp/ChangeLog:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
One would expect consecutive calls to bytes_in/out::b for streaming
adjacent bits, as we do for tree flag streaming, to at least be
optimized by the compiler into individual bit operations using
statically
On Wed, 14 Feb 2024, Ken Matsui wrote:
> This patch optimizes the compilation performance of std::remove_extent
> by dispatching to the new __remove_extent built-in trait.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/type_traits (remove_extent): Use __remove_extent
> built-in
On Wed, 14 Feb 2024, Ken Matsui wrote:
> This patch implements built-in trait for std::remove_extent.
>
> gcc/cp/ChangeLog:
>
> * cp-trait.def: Define __remove_extent.
> * semantics.cc (finish_trait_type): Handle CPTK_REMOVE_EXTENT.
>
> gcc/testsuite/ChangeLog:
>
> *
On Wed, 14 Feb 2024, Ken Matsui wrote:
> This patch optimizes the compilation performance of std::add_pointer
> by dispatching to the new __add_pointer built-in trait.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/type_traits (add_pointer): Use __add_pointer
> built-in trait.
LGTM
On Wed, 14 Feb 2024, Ken Matsui wrote:
> This patch implements built-in trait for std::add_pointer.
>
> gcc/cp/ChangeLog:
>
> * cp-trait.def: Define __add_pointer.
> * semantics.cc (finish_trait_type): Handle CPTK_ADD_POINTER.
>
> gcc/testsuite/ChangeLog:
>
> *
On Tue, 13 Feb 2024, Jason Merrill wrote:
> On 2/13/24 11:49, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, are one of
> > both of these fixes OK for trunk?
> >
> > -- >8 --
> >
> > Here during ahead of time checking of th
Bootstrapped and regtested on x86_64-pc-linux-gnu, are one of
both of these fixes OK for trunk?
-- >8 --
Here during ahead of time checking of the non-dependent new-expr we
synthesize B's copy constructor, which should be defined as deleted
due to A's inaccessible copy constructor. But
On Mon, 12 Feb 2024, Paul Keir wrote:
> A call to `basic_string::clear()` in the std::string move assignment operator
> leads to a constexpr error from an access of inactive union member
> `_M_local_buf` in the added test (`test_move()`). Changing
> `__str._M_local_buf` to
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk?
-- >8 --
The current implementation of bytes::calc_crc computes the checksum one
byte at a time, and turns out to be quite slow, taking 5% and 15% of
time compiling and streaming in the std module respectively. We
On Sat, 10 Feb 2024, Jason Merrill wrote:
> On 2/9/24 17:11, Patrick Palka wrote:
> > On Fri, 9 Feb 2024, Patrick Palka wrote:
> >
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > > OK for trunk?
> > >
> >
On Fri, 9 Feb 2024, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> OK for trunk?
>
> I'll try to reduce and add testcases overnight for these separate bugs
> before pushing.
>
> -- >8 --
>
> Building modular fmtlib tr
On Fri, 9 Feb 2024, Jason Merrill wrote:
> On 2/9/24 11:55, Patrick Palka wrote:
> > On Fri, 9 Feb 2024, Jason Merrill wrote:
> >
> > > On 2/9/24 10:51, Patrick Palka wrote:
> > > > It turns out that with modules we can call mangle_decl recursively,
> >
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
I'll try to reduce and add testcases overnight for these separate bugs
before pushing.
-- >8 --
Building modular fmtlib triggered two small modules bugs in C++23 and
C++26 mode respectively (due to libstdc++ header
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk
-- >8 --
It turns out that with modules we can call mangle_decl recursively,
which is a problem because the global mangling state isn't recursion
aware. The recursion happens from write_closure_type_name, which calls
On Fri, 9 Feb 2024, Jason Merrill wrote:
> On 2/9/24 10:51, Patrick Palka wrote:
> > It turns out that with modules we can call mangle_decl recursively,
> > which is a problem because the global mangling state isn't recursion
> > aware. The recursion happens from write_clo
On Thu, 8 Feb 2024, Ken Matsui wrote:
> Since is_same has a fallback native implementation, and
> _GLIBCXX_HAVE_BUILTIN_IS_SAME does not support toggling which
> implementation to use, we remove the _GLIBCXX_HAVE_BUILTIN_IS_SAME
> definition and use _GLIBCXX_USE_BUILTIN_TRAIT instead.
>
>
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
reasonable?
-- >8 --
It turns out that with modules we can call mangle_decl recursively,
which is a problem because the global mangling state isn't recursion
aware. The recursion happens from write_closure_type_name, which calls
On Thu, 1 Feb 2024, Patrick Palka wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
Ping. FWIW this fixes the remaining reported xtreme-header FAILs on
x86_64-linux with -mx32 (not totally sure why the fails don't happen
without -mx32).
>
> -- >8 --
>
> H
On Wed, 7 Feb 2024, Marek Polacek wrote:
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
>
> -- >8 --
> Here the problem is that we give hard errors while substituting
> template parameters during overload resolution of is_throwable
> which has an invalid throw in decltype.
>
>
101 - 200 of 2236 matches
Mail list logo
