Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk and 15?
-- >8 --
When we push an existing namespace within the module purview for the
first time, we also need to mark any parent inline namespaces as purview
to not confuse the streaming logic.
PR c++/121724
gcc/cp/ChangeL
On 9/1/25 7:31 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk and 15?
OK.
-- >8 --
When we push an existing namespace within the module purview for the
first time, we also need to mark any parent inline namespaces as purview
to not confuse the stre
On 8/31/25 9:21 AM, Nathaniel Shead wrote:
On Fri, Aug 29, 2025 at 12:33:23PM +0200, Jason Merrill wrote:
On 8/24/25 9:04 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
On looking again at [basic.lookup.argdep] p4, I believe GCC hasn't ful
Note: the tests in this patch depend on
https://gcc.gnu.org/pipermail/gcc-patches/2025-August/693810.html.
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
[basic.lookup.argdep] p4 says that ADL also finds declarations of
functions or function templates from a point of l
On Fri, Aug 29, 2025 at 12:33:23PM +0200, Jason Merrill wrote:
> On 8/24/25 9:04 AM, Nathaniel Shead wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> >
> > -- >8 --
> >
> > On looking again at [basic.lookup.argdep] p4, I believe GCC hasn't fully
> > implemented the wo
On 8/24/25 9:04 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
On looking again at [basic.lookup.argdep] p4, I believe GCC hasn't fully
implemented the wording here for ADL. This patch fixes two issues.
First, 4.3 indicates that a function
On 8/28/25 7:26 AM, Nathaniel Shead wrote:
On Wed, Aug 27, 2025 at 04:43:57PM +0200, Jason Merrill wrote:
On 8/27/25 8:29 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
While playing around again quickly before submitting I noticed that this
On Wed, Aug 27, 2025 at 04:43:57PM +0200, Jason Merrill wrote:
> On 8/27/25 8:29 AM, Nathaniel Shead wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
>
> OK.
>
While playing around again quickly before submitting I noticed that this
missed some cases with handling thin
On 8/27/25 8:29 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
The confusion in the PR arose because the definition of 'User' in a
separate named module did not provide an implementation for the
forward-declaration in the global modul
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
The confusion in the PR arose because the definition of 'User' in a
separate named module did not provide an implementation for the
forward-declaration in the global module. This seems likely to be a
common mistake while p
On 8/24/25 9:05 AM, Nathaniel Shead wrote:
On Sat, Aug 23, 2025 at 01:18:19PM -0400, Patrick Palka wrote:
On Fri, 22 Aug 2025, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
In the PR, we're getting a linker error from _Vector_impl's destruct
On Sat, Aug 23, 2025 at 01:18:19PM -0400, Patrick Palka wrote:
> On Fri, 22 Aug 2025, Nathaniel Shead wrote:
>
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> >
> > -- >8 --
> >
> > In the PR, we're getting a linker error from _Vector_impl's destructor
> > never getting em
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
On looking again at [basic.lookup.argdep] p4, I believe GCC hasn't fully
implemented the wording here for ADL. This patch fixes two issues.
First, 4.3 indicates that a function exported from a named module should
be visib
On Fri, 22 Aug 2025, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
>
> -- >8 --
>
> In the PR, we're getting a linker error from _Vector_impl's destructor
> never getting emitted. This is because of a combination of factors:
>
> 1. in imp-member-4_a,
On 8/22/25 2:02 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
In the PR, we're getting a linker error from _Vector_impl's destructor
never getting emitted. This is because of a combination of factors:
1. in imp-member-4_a, the dest
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
In the PR, we're getting a linker error from _Vector_impl's destructor
never getting emitted. This is because of a combination of factors:
1. in imp-member-4_a, the destructor is not used and so there is no
definition
On 8/16/25 11:06 PM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
We have logic to adjust a function decl if it gets re-declared as a
using-decl with different purviewness, but we also need to do the same
if it gets redeclared with diff
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
We have logic to adjust a function decl if it gets re-declared as a
using-decl with different purviewness, but we also need to do the same
if it gets redeclared with different exportedness.
PR c++/120195
gcc/cp/Ch
On 7/30/25 7:37 PM, Patrick Palka wrote:
On Thu, 31 Jul 2025, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
And maybe 15?
Good catch re the invisiref handling! This LGTM, Jason what do you
think?
OK for trunk and 15.
-- >8 --
When we merge a fu
On 7/31/25 10:34 AM, Jason Merrill wrote:
On 7/29/25 8:10 AM, Nathaniel Shead wrote:
Thoughts? Another suggestion raised on the PR was to just make this a
warning or some other non-fatal diagnostic (I suppose not attached to
any particular warning option?) and continue translation; I'm not
part
On 7/29/25 8:10 AM, Nathaniel Shead wrote:
Thoughts? Another suggestion raised on the PR was to just make this a
warning or some other non-fatal diagnostic (I suppose not attached to
any particular warning option?) and continue translation; I'm not
particularly fussed either way.
An unconditio
On Thu, 31 Jul 2025, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> And maybe 15?
Good catch re the invisiref handling! This LGTM, Jason what do you
think?
>
> -- >8 --
>
> When we merge a function definition, if there already exists a forward
> de
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
And maybe 15?
-- >8 --
When we merge a function definition, if there already exists a forward
declaration in the importing TU we use the PARM_DECLs belonging to that
decl. This usually works fine, except as noted in the linked PR t
On Tue, Jul 29, 2025 at 02:04:52PM +0200, Jakub Jelinek wrote:
> On Tue, Jul 29, 2025 at 09:57:19PM +1000, Nathaniel Shead wrote:
> > @@ -7114,8 +7121,10 @@ trees_in::core_vals (tree t)
> > }
> >
> > RT (t->function_decl.personality);
> > - RT (t->function_decl.function_specific_targe
On Tue, Jul 29, 2025 at 09:57:19PM +1000, Nathaniel Shead wrote:
> @@ -7114,8 +7121,10 @@ trees_in::core_vals (tree t)
> }
>
> RT (t->function_decl.personality);
> - RT (t->function_decl.function_specific_target);
> - RT (t->function_decl.function_specific_optimization);
> +
Thoughts? Another suggestion raised on the PR was to just make this a
warning or some other non-fatal diagnostic (I suppose not attached to
any particular warning option?) and continue translation; I'm not
particularly fussed either way.
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for t
On Mon, Jul 28, 2025 at 10:08:34AM +0200, Rainer Orth wrote:
> Patrick Palka writes:
>
> > On Sat, 26 Jul 2025, Nathaniel Shead wrote:
> >
> >> On Fri, Jul 25, 2025 at 08:58:47AM -0400, Patrick Palka wrote:
> >> > On Fri, 25 Jul 2025, Nathaniel Shead wrote:
> >> >
> >> > > Bootstrapped and regte
Patrick Palka writes:
> On Sat, 26 Jul 2025, Nathaniel Shead wrote:
>
>> On Fri, Jul 25, 2025 at 08:58:47AM -0400, Patrick Palka wrote:
>> > On Fri, 25 Jul 2025, Nathaniel Shead wrote:
>> >
>> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
>> > >
>> > > -- >8 --
>> > >
>>
On Sat, 26 Jul 2025, Nathaniel Shead wrote:
> On Fri, Jul 25, 2025 at 08:58:47AM -0400, Patrick Palka wrote:
> > On Fri, 25 Jul 2025, Nathaniel Shead wrote:
> >
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> > >
> > > -- >8 --
> > >
> > > I noticed that C++26 trivial r
On Fri, Jul 25, 2025 at 08:58:47AM -0400, Patrick Palka wrote:
> On Fri, 25 Jul 2025, Nathaniel Shead wrote:
>
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> >
> > -- >8 --
> >
> > I noticed that C++26 trivial relocation didn't work in modules yet, and
> > there are a cou
On Fri, 25 Jul 2025, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
>
> -- >8 --
>
> I noticed that C++26 trivial relocation didn't work in modules yet, and
> there are a couple of other flags that seem potentially useful we
> weren't streaming. This s
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
I noticed that C++26 trivial relocation didn't work in modules yet, and
there are a couple of other flags that seem potentially useful we
weren't streaming. This streams those flags and adds a comment to
cp-tree.h to help
On 5/23/25 9:00 PM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/15?
-- >8 --
When emitting a primary module interface, we must re-stream any TU-local
entities that we saw in a partition. This patch adds the missing
members from core_vals.
As a drive-
including for partial
specs); this is what the following patch does.
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
Subject: [PATCH] c++/modules: Ensure type of partial spec VAR_DECL is
consistent with its template [PR120644]
We were erroring because the TEMP
type of the TEMPLATE_DECL
> > > > correct,
> > > > maybe we should always set it to NULL_TREE to make sure we only look at
> > > > the
> > > > inner type.
> > >
> > > FWIW cp_finish_decl can get at the TEMPLATE_DECL of a VAR_DEC
if (x > 0)
+ return x * 5;
+}
diff --git a/gcc/tree.cc b/gcc/tree.cc
index 98575a51f58..3b599d81d43 100644
--- a/gcc/tree.cc
+++ b/gcc/tree.cc
@@ -786,6 +786,57 @@ init_ttree (void)
}
+/* Mapping from prefix to label number. */
+
+struct identifier_hash : ggc_ptr_hash
+
On 5/21/25 10:15 PM, Nathaniel Shead wrote:
This type currently has a DECL_NAME of an IDENTIFIER_DECL. Although the
documentation indicates this is legal, this confuses modules streaming
which expects all RECORD_TYPEs to have a TYPE_DECL, which is used to
determine the context and merge key, etc
linux-gnu, OK for trunk?
-- >8 --
Subject: [PATCH] c++/modules: Ensure type of partial spec VAR_DECL is
consistent with its template [PR120644]
We were erroring because the TEMPLATE_DECL of the existing partial
specialisation has an undeduced return type, but the imported
declaration did not.
ECL
> corresponding to a partial specialization via
>
> TI_TEMPLATE (TI_PARTIAL_INFO (DECL_TEMPLATE_INFO (decl)))
>
> if we do want to end up keeping the two TREE_TYPEs in sync.
>
Thanks. On further reflection, maybe the safest approach is to just
ensure that the types are a
On Tue, 24 Jun 2025, Jason Merrill wrote:
> On 6/23/25 5:41 PM, Nathaniel Shead wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/15?
> >
> > -- >8 --
> >
> > We were erroring because the TEMPLATE_DECL of the existing partial
> > specialisation has an undeduced return ty
On 6/23/25 5:41 PM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/15?
-- >8 --
We were erroring because the TEMPLATE_DECL of the existing partial
specialisation has an undeduced return type, but the imported
declaration did not.
The root cause is simila
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/15?
-- >8 --
We were erroring because the TEMPLATE_DECL of the existing partial
specialisation has an undeduced return type, but the imported
declaration did not.
The root cause is similar to what was fixed in r13-2744-g4fac53d65221
Ping for this patch.
On Wed, May 28, 2025 at 02:19:11PM -0400, Patrick Palka wrote:
> On Sat, 24 May 2025, Nathaniel Shead wrote:
>
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/15?
>
> LGTM FWIW
>
> >
> > -- >8 --
> >
> > When emitting a primary module interface, we mus
Ping.
On Thu, May 22, 2025 at 12:15:34PM +1000, Nathaniel Shead wrote:
> This type currently has a DECL_NAME of an IDENTIFIER_DECL. Although the
> documentation indicates this is legal, this confuses modules streaming
> which expects all RECORD_TYPEs to have a TYPE_DECL, which is used to
> determ
le-1-aux.cc
> b/gcc/testsuite/g++.dg/ubsan/module-1-aux.cc
> new file mode 100644
> index 000..7930896140f
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/ubsan/module-1-aux.cc
> @@ -0,0 +1,12 @@
> +// PR c++/98735
> +
> +int g(int x) {
> + if (x > 0)
On Wed, 2025-06-11 at 11:57 -0400, Jason Merrill wrote:
> On 6/3/25 7:02 PM, David Malcolm wrote:
> > On Sat, 2025-05-31 at 23:25 -0400, Jason Merrill wrote:
> > > + if (kind == DK_POP)
> > > + opt += offset;
> >
> > I'm wondering why the offset is applied to "opt" here? That feels
> > wrong
f14486bf350 Mon Sep 17 00:00:00 2001
From: Jason Merrill
Date: Wed, 20 Nov 2024 16:20:52 +0100
Subject: [PATCH] c++: modules and #pragma diagnostic
To: gcc-patches@gcc.gnu.org
To respect the #pragma diagnostic lines in libstdc++ headers when compiling
with module std, we need to represent them in th
On 5/26/25 8:55 AM, Nathaniel Shead wrote:
On Fri, May 23, 2025 at 11:31:26AM -0400, Jason Merrill wrote:
On 5/21/25 10:15 PM, Nathaniel Shead wrote:
Another approach would be to fix 'write_class_def' to handle these
declarations better, but that ended up being more work and felt fragile.
It al
On Sat, 2025-05-31 at 23:25 -0400, Jason Merrill wrote:
> From f57505c7c6fa05a14e285c14a81021655a43ccbc Mon Sep 17 00:00:00
> 2001
> From: Jason Merrill
> Date: Wed, 20 Nov 2024 16:20:52 +0100
> Subject: [PATCH] c++: modules and #pragma diagnostic
> To: gcc-patches@gcc.gnu.org
&
BUTE_NORETURN;
OK, how about this?
From f57505c7c6fa05a14e285c14a81021655a43ccbc Mon Sep 17 00:00:00 2001
From: Jason Merrill
Date: Wed, 20 Nov 2024 16:20:52 +0100
Subject: [PATCH] c++: modules and #pragma diagnostic
To: gcc-patches@gcc.gnu.org
To respect the #pragma diagnostic lines in libstdc++ hea
On Thu, 2025-05-29 at 09:11 -0400, Jason Merrill wrote:
> On 5/27/25 5:12 PM, Jason Merrill wrote:
> > On 5/27/25 4:47 PM, Jason Merrill wrote:
> > > On 5/27/25 1:33 PM, David Malcolm wrote:
> > > > On Fri, 2025-05-23 at 16:58 -0400, Jason Merrill wrote:
> > > > > On 4/14/25 9:57 AM, Jason Merrill
On 5/27/25 5:12 PM, Jason Merrill wrote:
On 5/27/25 4:47 PM, Jason Merrill wrote:
On 5/27/25 1:33 PM, David Malcolm wrote:
On Fri, 2025-05-23 at 16:58 -0400, Jason Merrill wrote:
On 4/14/25 9:57 AM, Jason Merrill wrote:
On 1/9/25 10:00 PM, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu. Is
On Sat, 24 May 2025, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/15?
LGTM FWIW
>
> -- >8 --
>
> When emitting a primary module interface, we must re-stream any TU-local
> entities that we saw in a partition. This patch adds the missing
> members fr
On Wed, May 28, 2025 at 12:24:54AM -0400, Jason Merrill wrote:
> On 11/27/24 11:17 AM, Jason Merrill wrote:
> > On 11/27/24 1:43 AM, Nathaniel Shead wrote:
> > > On Wed, Nov 27, 2024 at 12:03:23AM -0500, Jason Merrill wrote:
> > > > Tested x86_64-pc-linux-gnu.
> > > >
> > > > Does this approach ma
to issues with circular directives.
That would mean we wouldn't need to do this in every lookup.
That was my first thought, but I had trouble figuring out how. Perhaps
I'll try again.
Done thus. Any thoughts on this version?From e4711055f683faa2ae747507dfe8b1d51fe26760 Mon Sep 17 00:00
On Tue, 2025-05-27 at 17:21 -0400, Patrick Palka wrote:
>
> On Tue, 27 May 2025, Patrick Palka wrote:
>
> > On Tue, 27 May 2025, David Malcolm wrote:
> >
> > > On Fri, 2025-05-23 at 16:58 -0400, Jason Merrill wrote:
> > > > On 4/14/25 9:57 AM, Jason Merrill wrote:
> > > > > On 1/9/25 10:00 PM, J
On Tue, 27 May 2025, Patrick Palka wrote:
> On Tue, 27 May 2025, David Malcolm wrote:
>
> > On Fri, 2025-05-23 at 16:58 -0400, Jason Merrill wrote:
> > > On 4/14/25 9:57 AM, Jason Merrill wrote:
> > > > On 1/9/25 10:00 PM, Jason Merrill wrote:
> > > > > Tested x86_64-pc-linux-gnu. Is the diagno
On 5/27/25 4:47 PM, Jason Merrill wrote:
On 5/27/25 1:33 PM, David Malcolm wrote:
On Fri, 2025-05-23 at 16:58 -0400, Jason Merrill wrote:
On 4/14/25 9:57 AM, Jason Merrill wrote:
On 1/9/25 10:00 PM, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu. Is the diagnostic.h change OK for
trunk?
P
On Tue, 27 May 2025, David Malcolm wrote:
> On Fri, 2025-05-23 at 16:58 -0400, Jason Merrill wrote:
> > On 4/14/25 9:57 AM, Jason Merrill wrote:
> > > On 1/9/25 10:00 PM, Jason Merrill wrote:
> > > > Tested x86_64-pc-linux-gnu. Is the diagnostic.h change OK for
> > > > trunk?
> > >
> > > Ping?
>
On 5/27/25 1:33 PM, David Malcolm wrote:
On Fri, 2025-05-23 at 16:58 -0400, Jason Merrill wrote:
On 4/14/25 9:57 AM, Jason Merrill wrote:
On 1/9/25 10:00 PM, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu. Is the diagnostic.h change OK for
trunk?
Ping?
Ping.
Sorry for the delay in resp
On Fri, 2025-05-23 at 16:58 -0400, Jason Merrill wrote:
> On 4/14/25 9:57 AM, Jason Merrill wrote:
> > On 1/9/25 10:00 PM, Jason Merrill wrote:
> > > Tested x86_64-pc-linux-gnu. Is the diagnostic.h change OK for
> > > trunk?
> >
> > Ping?
>
> Ping.
Sorry for the delay in responding; comments be
On Fri, May 23, 2025 at 11:31:26AM -0400, Jason Merrill wrote:
> On 5/21/25 10:15 PM, Nathaniel Shead wrote:
> > Another approach would be to fix 'write_class_def' to handle these
> > declarations better, but that ended up being more work and felt fragile.
> > It also meant streaming a lot more inf
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/15?
-- >8 --
When emitting a primary module interface, we must re-stream any TU-local
entities that we saw in a partition. This patch adds the missing
members from core_vals.
As a drive-by fix, in some cases we might have a typedef
On 4/14/25 9:57 AM, Jason Merrill wrote:
On 1/9/25 10:00 PM, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu. Is the diagnostic.h change OK for trunk?
Ping?
Ping.
-- 8< --
To respect the #pragma diagnostic lines in libstdc++ headers when
compiling
with module std, we need to represent
e, thanks. Updated below, and fixed thinko in commit title; testing
modules.exp passed successfully on x86_64-pc-linux-gnu.
OK for trunk/15 if full bootstrap+regtest succeeds?
OK.
-- >8 --
Subject: [PATCH] c++/modules: Fix merge of TLS init functions [PR120363]
The PR notes that we missed
On 5/23/25 10:59 AM, Nathaniel Shead wrote:
Tested on x86_64-pc-linux-gnu (so far just modules.exp), OK for trunk if
full bootstrap+regtest succeeds?
OK.
-- >8 --
When streaming in a reference to a data member, we have an oversight
where we did not consider USING_DECLs, despite otherwise han
On 5/21/25 10:15 PM, Nathaniel Shead wrote:
Another approach would be to fix 'write_class_def' to handle these
declarations better, but that ended up being more work and felt fragile.
It also meant streaming a lot more information that we don't need.
Long term I had been playing around with rewo
Tested on x86_64-pc-linux-gnu (so far just modules.exp), OK for trunk if
full bootstrap+regtest succeeds?
-- >8 --
When streaming in a reference to a data member, we have an oversight
where we did not consider USING_DECLs, despite otherwise handling them
here the same as fields. This patch corre
IC (var);
> > DECL_ARTIFICIAL (fn) = true;
> > + DECL_CONTEXT (fn) = global_namespace;
>
> Generally we do FROB_CONTEXT (global_namespace) so we never actually see
> global_namespace in DECL_CONTEXT. I'm not sure that's necessary in this
> particular case, bu
On 5/22/25 8:22 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/15?
(Also is renaming the old test OK/appropriate? Or should I keep it
before and just name the new tests as tls1/2, with a comment referring
to pr113292?)
-- >8 --
The PR notes that we m
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/15?
(Also is renaming the old test OK/appropriate? Or should I keep it
before and just name the new tests as tls1/2, with a comment referring
to pr113292?)
-- >8 --
The PR notes that we missed setting DECL_CONTEXT on the TLS init
fu
On Thu, May 22, 2025 at 12:15:02PM +1000, Nathaniel Shead wrote:
> Another approach would be to fix 'write_class_def' to handle these
> declarations better, but that ended up being more work and felt fragile.
> It also meant streaming a lot more information that we don't need.
>
> Long term I had
This type currently has a DECL_NAME of an IDENTIFIER_DECL. Although the
documentation indicates this is legal, this confuses modules streaming
which expects all RECORD_TYPEs to have a TYPE_DECL, which is used to
determine the context and merge key, etc.
PR c++/120040
gcc/cp/ChangeLog:
/tree.cc b/gcc/tree.cc
index 98575a51f58..3b599d81d43 100644
--- a/gcc/tree.cc
+++ b/gcc/tree.cc
@@ -786,6 +786,57 @@ init_ttree (void)
}
+/* Mapping from prefix to label number. */
+
+struct identifier_hash : ggc_ptr_hash
+{
+ static inline hashval_t hash (tree t)
+ {
+return IDENTIFIER_HASH_V
Another approach would be to fix 'write_class_def' to handle these
declarations better, but that ended up being more work and felt fragile.
It also meant streaming a lot more information that we don't need.
Long term I had been playing around with reworking ubsan.cc entirely to
have a fixed set of
On 5/19/25 11:11 PM, Nathaniel Shead wrote:
On Mon, May 19, 2025 at 04:56:38PM -0400, Jason Merrill wrote:
On 5/19/25 8:27 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
Alternatively could go back to always marking vtables as DECL_EXTERNAL
as well
On Mon, May 19, 2025 at 04:56:38PM -0400, Jason Merrill wrote:
> On 5/19/25 8:27 AM, Nathaniel Shead wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> >
> > Alternatively could go back to always marking vtables as DECL_EXTERNAL
> > as well but that doesn't seem to be ne
On 5/17/25 10:38 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/15?
OK.
-- >8 --
When we import a pending instantiation that matches an existing partial
specialisation, we don't find the slot in the entity map because for
partial specialisations we
On 5/19/25 8:27 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
Alternatively could go back to always marking vtables as DECL_EXTERNAL
as well but that doesn't seem to be necessary that I can tell.
DECL_NOT_REALLY_EXTERN doesn't make sense without DE
On 5/19/25 9:37 AM, Nathaniel Shead wrote:
Regtested on x86_64-pc-linux-gnu (so far just modules.exp), OK for
trunk if full bootstrap+regtest succeeds? And maybe 15?
OK for both.
-- >8 --
We need to mark type info decls as addressable if we take them by
reference; this is done by walking th
Regtested on x86_64-pc-linux-gnu (so far just modules.exp), OK for
trunk if full bootstrap+regtest succeeds? And maybe 15?
-- >8 --
We need to mark type info decls as addressable if we take them by
reference; this is done by walking the declaration during parsing and
marking the decl as needed.
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
Alternatively could go back to always marking vtables as DECL_EXTERNAL
as well but that doesn't seem to be necessary that I can tell.
-- >8 --
I missed a testcase in r16-688-gc875748cdc468e for whether a GM vtable
should be emitted
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/15?
-- >8 --
When we import a pending instantiation that matches an existing partial
specialisation, we don't find the slot in the entity map because for
partial specialisations we register the TEMPLATE_DECL but for normal
implicit i
On 5/16/25 9:14 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
This patch removes some no longer needed special casing in linkage
determination, and makes the distinction between "always_emit" and
"internal" for better future-proofing
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
This patch removes some no longer needed special casing in linkage
determination, and makes the distinction between "always_emit" and
"internal" for better future-proofing.
gcc/cp/ChangeLog:
* module.cc (importer_
On 5/14/25 6:26 AM, Nathaniel Shead wrote:
On Tue, May 13, 2025 at 12:40:30PM -0400, Jason Merrill wrote:
On 5/9/25 11:48 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/15?
One slight concern I have is why we end up in 'maybe_thunk_body' to
start wit
> >
> >
> > This bug also affects 14 after r14-11743-g6d5a6a26e28d15; a minimal fix
> > for the ICE that seems straight-forwardly correct is to just do the
> > optimize.cc hunk, and I think that might be more appropriate given we
> > didn't handle explicit
On 5/9/25 11:48 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/15?
One slight concern I have is why we end up in 'maybe_thunk_body' to
start with: the imported constructor isn't DECL_ONE_ONLY (as its
external) and so 'can_alias_cdtor' returns false.
On 5/9/25 11:33 AM, Nathaniel Shead wrote:
On Fri, May 09, 2025 at 08:18:58AM -0400, Jason Merrill wrote:
On 4/21/25 6:22 AM, Nathaniel Shead wrote:
This call is not necessary, as we don't access the bodies of any classes
that we instantiate here.
This turns out to break
20_util/function_obj
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/15?
One slight concern I have is why we end up in 'maybe_thunk_body' to
start with: the imported constructor isn't DECL_ONE_ONLY (as its
external) and so 'can_alias_cdtor' returns false. The change in
write_function_def (which I beli
On Fri, May 09, 2025 at 08:18:58AM -0400, Jason Merrill wrote:
> On 4/21/25 6:22 AM, Nathaniel Shead wrote:
> > This call is not necessary, as we don't access the bodies of any classes
> > that we instantiate here.
>
> This turns out to break
>
> 20_util/function_objects/mem_fn/constexpr.cc
> std
On 4/21/25 6:22 AM, Nathaniel Shead wrote:
This call is not necessary, as we don't access the bodies of any classes
that we instantiate here.
This turns out to break
20_util/function_objects/mem_fn/constexpr.cc
std/ranges/view.cc
when modified to use import std (as attached). For the former,
On Fri, May 09, 2025 at 08:18:58AM -0400, Jason Merrill wrote:
> On 4/21/25 6:22 AM, Nathaniel Shead wrote:
> > This call is not necessary, as we don't access the bodies of any classes
> > that we instantiate here.
>
> This turns out to break
>
> 20_util/function_objects/mem_fn/constexpr.cc
> std
On 4/30/25 9:40 AM, Nathaniel Shead wrote:
Tested on x86_64-pc-linux-gnu (so far just modules.exp), OK for trunk
and maybe 15 if full regtest+bootstrap succeeds?
OK.
-- >8 --
In the linked PR, because the deduction guides depend on an imported
type, we never walk the type and so never call a
On 4/25/25 8:56 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/15?
OK.
-- >8 --
When importing a CNTTP object, since r15-3031-g0b7904e274fbd6 we
shortcut the processing of the generated NTTP so that we don't attempt
to recursively load pendings. H
On 4/29/25 3:59 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu (so far just
modules.exp), OK for trunk and 15 if full regtest succeeds?
OK.
-- >8 --
In r15-9136-g0210bedf481a9f we started erroring for inline variables
that exposed TU-local entities in their defi
Tested on x86_64-pc-linux-gnu (so far just modules.exp), OK for trunk
and maybe 15 if full regtest+bootstrap succeeds?
-- >8 --
In the linked PR, because the deduction guides depend on an imported
type, we never walk the type and so never call add_deduction_guides.
This patch ensures that we make
Bootstrapped and regtested on x86_64-pc-linux-gnu (so far just
modules.exp), OK for trunk and 15 if full regtest succeeds?
-- >8 --
In r15-9136-g0210bedf481a9f we started erroring for inline variables
that exposed TU-local entities in their definition, as such variables
would need to have their d
On 4/25/25 10:30 AM, Nathaniel Shead wrote:
Tested so far on x86_64-pc-linux-gnu (just modules.exp), OK for trunk/15
if full bootstrap+regtest succeeds?
OK.
A potentially safer approach that would slightly bloat out the size of
the built modules would be to always stream this variable rather
Tested so far on x86_64-pc-linux-gnu (just modules.exp), OK for trunk/15
if full bootstrap+regtest succeeds?
A potentially safer approach that would slightly bloat out the size of
the built modules would be to always stream this variable rather than
having any conditions, but from what I can tell
1 - 100 of 777 matches
Mail list logo
