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
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
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
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.
>
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
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
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
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
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>>;
> >
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 +-
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
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
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:
>
>
1 - 100 of 2143 matches
Mail list logo
