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
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/15?
-- >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. However, due to an oversight we do not
properly set T
On 4/21/25 6:22 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
This call is not necessary, as we don't access the bodies of any classes
that we instantiate here.
gcc/cp/ChangeLog:
* name-lookup.cc (lookup_imported_hidden_fri
On 4/21/25 6:21 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
And 15 (I guess after the release has been made)?
OK, yes.
-- >8 --
In r15-9029-geb26b667518c95, we started checking for conflicting
declarations with any reachable decl attached to th
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
This call is not necessary, as we don't access the bodies of any classes
that we instantiate here.
gcc/cp/ChangeLog:
* name-lookup.cc (lookup_imported_hidden_friend): Remove
unnecessary lazy_load_pendings.
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
And 15 (I guess after the release has been made)?
-- >8 --
In r15-9029-geb26b667518c95, we started checking for conflicting
declarations with any reachable decl attached to the same originating
module. This exposed the issue in the
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?
-- 8< --
To respect the #pragma diagnostic lines in libstdc++ headers when compiling
with module std, we need to represent them in the module.
I think it's reasonable to make
On 4/10/25 5:35 PM, Nathaniel Shead wrote:
On Thu, Apr 10, 2025 at 12:19:57PM -0400, Jason Merrill wrote:
On 4/10/25 8:46 AM, Nathaniel Shead wrote:
Regression raised with my by private correspondance.
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
My change in r15-
_ptr&) = default;
+};
+
+void enqueue() {
+ exception_ptr e;
+ e == e;
+}
+
+import "noexcept-4_a.H";
+
+int main() {
+ constexpr exception_ptr e;
+ static_assert(e == e);
+ static_assert(noexcept(e == e));
+}
--
2.47.0
>From 95a4827b96efa193eda2032e28ad8133373e884d Mon Sep 17
On 4/10/25 8:46 AM, Nathaniel Shead wrote:
Regression raised with my by private correspondance.
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
My change in r15-9216 broke the case where we imported an uninstantiated
defaulted function over the top of one we had alread
Regression raised with my by private correspondance.
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
My change in r15-9216 broke the case where we imported an uninstantiated
defaulted function over the top of one we had already finished. This
patch ensures that we don't
, always external, always emitted by importer) to handle header
units more naturally.
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
Subject: [PATCH] c++/modules: Fix explicit instantiations and gnu_inlines
[PR119154]
My change in r15-8012 for PR c++/119
On Fri, 4 Apr 2025, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
>
> -- >8 --
>
> Modules streaming walks decls multiple times, first as a non-streaming
> walk to find dependencies, and then later to actually emit the decls.
> The first walk needs to
On 4/3/25 9:09 PM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
Modules streaming walks decls multiple times, first as a non-streaming
walk to find dependencies, and then later to actually emit the decls.
The first walk needs to be done
On 4/4/25 4:14 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
In the linked PR, we're importing over a DECL_MAYBE_DELETED decl with a
decl that has already been instantiated. This patch ensures that the
needed bits are propagated acr
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
In the linked PR, we're importing over a DECL_MAYBE_DELETED decl with a
decl that has already been instantiated. This patch ensures that the
needed bits are propagated across and that DECL_MAYBE_DELETED is cleared
from the
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
Modules streaming walks decls multiple times, first as a non-streaming
walk to find dependencies, and then later to actually emit the decls.
The first walk needs to be done to note locations that will be emitted.
In the PR
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
std/format/string.cc and a few other libstdc++ tests were failing with
module std with undefined references to __failed_to_parse_format_spec. This
turned out to be because since r15-8012 we don't end up calling
note_vague_linkage_fn for fun
On 4/1/25 7:02 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
An inline variable has vague linkage, and needs to be conditionally
emitted in TUs that reference it. Unfortunately this clashes with
[basic.link] p14.2, which says that we ignor
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
An inline variable has vague linkage, and needs to be conditionally
emitted in TUs that reference it. Unfortunately this clashes with
[basic.link] p14.2, which says that we ignore the initialisers of all
variables (includi
On Sat, Mar 29, 2025 at 11:14:46AM -0400, Jason Merrill wrote:
> Tested x86_64-pc-linux-gnu, applying to trunk. Do you agree with my choice of
> how to adjust duplicate_decls?
Yes, that looks reasonable to me. The point of this block is just to
ensure that we export any entities declared in the
Tested x86_64-pc-linux-gnu, applying to trunk. Do you agree with my choice of
how to adjust duplicate_decls?
-- 8< --
Here we were failing to match the injected friend declaration to the
definition because the latter isn't exported. But the friend is attached to
the module, so we need to look f
On 3/28/25 8:54 AM, Nathaniel Shead wrote:
On Thu, Mar 27, 2025 at 10:38:02AM -0400, Jason Merrill wrote:
On 3/27/25 3:35 AM, Nathaniel Shead wrote:
Bootstrapped and regtested (so far just dg.exp and modules.exp) on
x86_64-pc-linux-gnu, OK for trunk if full regtest succeeds?
Rather than updati
On Thu, Mar 27, 2025 at 10:38:02AM -0400, Jason Merrill wrote:
> On 3/27/25 3:35 AM, Nathaniel Shead wrote:
> > Bootstrapped and regtested (so far just dg.exp and modules.exp) on
> > x86_64-pc-linux-gnu, OK for trunk if full regtest succeeds?
> >
> > Rather than updating copy_fndecl_with_name, we
On 3/27/25 3:35 AM, Nathaniel Shead wrote:
Bootstrapped and regtested (so far just dg.exp and modules.exp) on
x86_64-pc-linux-gnu, OK for trunk if full regtest succeeds?
Rather than updating copy_fndecl_with_name, we could also just fix
modules specifically by overwriting DECL_ABSTRACT_P before
On 3/27/25 8:05 AM, Nathaniel Shead wrote:
On Thu, Mar 27, 2025 at 08:02:20AM -0400, Jason Merrill wrote:
On 3/26/25 9:24 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
The ICE in the linked PR is caused because out_ptr_t inherits an ABI t
On 3/26/25 9:24 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
The ICE in the linked PR is caused because out_ptr_t inherits an ABI tag
in a module that it does not in the importing module. When we try to
build a qualified 'const out_ptr_t'
On Thu, Mar 27, 2025 at 08:02:20AM -0400, Jason Merrill wrote:
> On 3/26/25 9:24 AM, Nathaniel Shead wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> >
> > -- >8 --
> >
> > The ICE in the linked PR is caused because out_ptr_t inherits an ABI tag
> > in a module that i
Bootstrapped and regtested (so far just dg.exp and modules.exp) on
x86_64-pc-linux-gnu, OK for trunk if full regtest succeeds?
Rather than updating copy_fndecl_with_name, we could also just fix
modules specifically by overwriting DECL_ABSTRACT_P before calling
build_cdtor_clones in trees_in::decl_
On Wed, Mar 26, 2025 at 11:40:16PM -0400, Jason Merrill wrote:
> On 3/26/25 9:23 AM, Nathaniel Shead wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> >
> > -- >8 --
> >
> > When doing tsubst_friend_class, we need to first check if any imported
> > module has already c
niel Shead
Date: Thu, 27 Mar 2025 00:23:24 +1100
Subject: [PATCH] c++/modules: Fix tsubst of global module friend classes
[PR118920]
To: gcc-patches@gcc.gnu.org
When doing tsubst_friend_class, we need to first check if any imported
module has already created a (hidden) declaration for the cla
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
When doing tsubst_friend_class, we need to first check if any imported
module has already created a (hidden) declaration for the class so that
we don't end up with conflicting declarations. Currently we do this
using DECL_
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
The ICE in the linked PR is caused because out_ptr_t inherits an ABI tag
in a module that it does not in the importing module. When we try to
build a qualified 'const out_ptr_t' during stream-in, we find the
existing 'cons
1 - 100 of 745 matches
Mail list logo
