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
;
> Jason
>
I found the clearest way to go was to make the function a tristate
(vague, always external, always emitted by importer) to handle header
units more naturally.
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
Subject: [PATCH] c++/modules: Fix ex
On 3/14/25 9:28 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
Alternatively, could still mark gnu_inline functions as non-vague, we
just need to do so more aggressively; but given this is specifically to
solve a modules issue I felt may as well keep
On 3/7/25 6:45 AM, Nathaniel Shead wrote:
On Thu, Mar 06, 2025 at 11:00:46AM -0500, Jason Merrill wrote:
On 2/8/25 7:32 AM, Nathaniel Shead wrote:
On Fri, Feb 07, 2025 at 11:11:21AM -0500, Jason Merrill wrote:
On 2/7/25 9:28 AM, Nathaniel Shead wrote:
On Fri, Feb 07, 2025 at 08:14:23AM -0500,
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
Alternatively, could still mark gnu_inline functions as non-vague, we
just need to do so more aggressively; but given this is specifically to
solve a modules issue I felt may as well keep it confined to there given
your previous comm
gcc/cp/ChangeLog:
> >
> > * decl2.cc (vague_linkage_p): Explicit instantiations are not
> > vague linkage.
>
> This seems like a big hammer for fixing a modules-specific issue; let's
> address it in the modules code, not here.
Fair enough, like this
On 3/12/25 10:57 AM, Nathaniel Shead wrote:
On Mon, Mar 10, 2025 at 02:52:07PM -0400, Jason Merrill wrote:
On 3/10/25 9:52 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
Or should this wait for GCC16?
-- >8 --
While looking at PR c++/119154 I notic
On 3/12/25 10:43 AM, Nathaniel Shead wrote:
On Wed, Mar 12, 2025 at 08:52:19AM -0400, Jason Merrill wrote:
On 3/10/25 9:50 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
Alternatively, a more minimal fix for the PR would be to just special
case the
On Mon, Mar 10, 2025 at 02:52:07PM -0400, Jason Merrill wrote:
> On 3/10/25 9:52 AM, Nathaniel Shead wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> > Or should this wait for GCC16?
> >
> > -- >8 --
> >
> > While looking at PR c++/119154 I noticed some more propertie
On 3/7/25 6:00 AM, Nathaniel Shead wrote:
On Fri, Mar 07, 2025 at 09:48:27PM +1100, Nathaniel Shead wrote:
On Thu, Mar 06, 2025 at 11:20:59AM -0500, Jason Merrill wrote:
On 2/9/25 6:38 AM, Nathaniel Shead wrote:
On Sun, Feb 09, 2025 at 01:16:00AM +1100, Nathaniel Shead wrote:
Tested on x86_64
On Wed, Mar 12, 2025 at 08:52:19AM -0400, Jason Merrill wrote:
> On 3/10/25 9:50 AM, Nathaniel Shead wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> >
> > Alternatively, a more minimal fix for the PR would be to just special
> > case the note_vague_linkage_fn calls to
On 3/10/25 9:50 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
Alternatively, a more minimal fix for the PR would be to just special
case the note_vague_linkage_fn calls to not be performed for gnu_inline
functions, if that's a preferable fix this lat
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
Alternatively, a more minimal fix for the PR would be to just special
case the note_vague_linkage_fn calls to not be performed for gnu_inline
functions, if that's a preferable fix this late into stage 4.
-- >8 --
Currently, note_va
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
Or should this wait for GCC16?
-- >8 --
While looking at PR c++/119154 I noticed some more properties that we
don't stream or check properly. This patch adds the ones we were
missing, and adds checks that the values don't clash wit
On 3/10/25 9:52 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
Or should this wait for GCC16?
-- >8 --
While looking at PR c++/119154 I noticed some more properties that we
don't stream or check properly. This patch adds the ones we were
missing, an
s another couple of
testcases I tried as well that also passed with your change:
Thanks, I incorporated them in the patch I'm pushing:
From b360d4aafc1356386313c7392f7444b3fc356681 Mon Sep 17 00:00:00 2001
From: Jason Merrill
Date: Thu, 6 Mar 2025 12:39:36 -0500
Subject: [PATCH] c++/modules
On Thu, Mar 06, 2025 at 12:45:33PM -0500, Jason Merrill wrote:
> On 3/5/25 7:54 AM, Nathaniel Shead wrote:
> > On Wed, Feb 26, 2025 at 10:29:59AM -0500, Jason Merrill wrote:
> > > On 2/21/25 6:05 AM, Nathaniel Shead wrote:
> > > > After seeing PR c++/118964 I'm coming back around to this [1] patch
On Thu, Mar 06, 2025 at 11:00:46AM -0500, Jason Merrill wrote:
> On 2/8/25 7:32 AM, Nathaniel Shead wrote:
> > On Fri, Feb 07, 2025 at 11:11:21AM -0500, Jason Merrill wrote:
> > > On 2/7/25 9:28 AM, Nathaniel Shead wrote:
> > > > On Fri, Feb 07, 2025 at 08:14:23AM -0500, Jason Merrill wrote:
> > >
On Fri, Mar 07, 2025 at 09:48:27PM +1100, Nathaniel Shead wrote:
> On Thu, Mar 06, 2025 at 11:20:59AM -0500, Jason Merrill wrote:
> > On 2/9/25 6:38 AM, Nathaniel Shead wrote:
> > > On Sun, Feb 09, 2025 at 01:16:00AM +1100, Nathaniel Shead wrote:
> > > > Tested on x86_64-pc-linux-gnu, OK for trunk
On Thu, Mar 06, 2025 at 11:20:59AM -0500, Jason Merrill wrote:
> On 2/9/25 6:38 AM, Nathaniel Shead wrote:
> > On Sun, Feb 09, 2025 at 01:16:00AM +1100, Nathaniel Shead wrote:
> > > Tested on x86_64-pc-linux-gnu, OK for trunk if full bootstrap + regtest
> > > passes?
> > >
> > > -- >8 --
> > >
>
ently use warning_enabled_at to suppress a diagnostic based on
whether the diagnostic is enabled at the point of definition of some entity.
JasonFrom c4b03fed1b6f1bad193a90ddfc64b175fdb92f7b Mon Sep 17 00:00:00 2001
From: Jason Merrill
Date: Thu, 6 Mar 2025 12:39:36 -0500
Subject: [PATCH]
On 2/9/25 6:38 AM, Nathaniel Shead wrote:
On Sun, Feb 09, 2025 at 01:16:00AM +1100, Nathaniel Shead wrote:
Tested on x86_64-pc-linux-gnu, OK for trunk if full bootstrap + regtest
passes?
-- >8 --
There are two issues with no-linkage decls (e.g. explicit type aliases)
in unnamed namespaces that
On 2/8/25 7:32 AM, Nathaniel Shead wrote:
On Fri, Feb 07, 2025 at 11:11:21AM -0500, Jason Merrill wrote:
On 2/7/25 9:28 AM, Nathaniel Shead wrote:
On Fri, Feb 07, 2025 at 08:14:23AM -0500, Jason Merrill wrote:
On 1/31/25 8:46 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-
On 3/5/25 8:00 AM, Nathaniel Shead wrote:
Ping for this. Or should this cleanup wait till GCC16?
OK, let's go ahead with it now.
On Wed, Feb 12, 2025 at 12:49:03AM +1100, Nathaniel Shead wrote:
On Mon, Jan 27, 2025 at 10:20:05AM -0500, Patrick Palka wrote:
[snip]
@@ -18486,6 +18562,12 @@
On Wed, Feb 26, 2025 at 10:29:59AM -0500, Jason Merrill wrote:
> On 2/21/25 6:05 AM, Nathaniel Shead wrote:
> > After seeing PR c++/118964 I'm coming back around to this [1] patch
> > series, since it appears that this can cause errors on otherwise valid
> > code by instantiations coming into modul
Ping for this. Or should this cleanup wait till GCC16?
On Wed, Feb 12, 2025 at 12:49:03AM +1100, Nathaniel Shead wrote:
> On Mon, Jan 27, 2025 at 10:20:05AM -0500, Patrick Palka wrote:
> > [snip]
> >
> > > @@ -18486,6 +18562,12 @@ dependent_operand_p (tree t)
> > > {
> > >while (TREE_CODE (t
Ping for this; was there any changes that you wanted me to make here?
On Sat, Feb 08, 2025 at 11:32:28PM +1100, Nathaniel Shead wrote:
> On Fri, Feb 07, 2025 at 11:11:21AM -0500, Jason Merrill wrote:
> > On 2/7/25 9:28 AM, Nathaniel Shead wrote:
> > > On Fri, Feb 07, 2025 at 08:14:23AM -0500, Jaso
Ping for this fix for a P1 issue.
On Sun, Feb 09, 2025 at 10:38:24PM +1100, Nathaniel Shead wrote:
> On Sun, Feb 09, 2025 at 01:16:00AM +1100, Nathaniel Shead wrote:
> > Tested on x86_64-pc-linux-gnu, OK for trunk if full bootstrap + regtest
> > passes?
> >
> > -- >8 --
> >
> > There are two iss
Hi!
modules.cc has apparently support for extensions and attempts to ensure
that if a module is compiled with those extensions enabled, sources which
use the module are compiled with the same extensions.
The only extension supported is SE_OPENMP right now.
And the use of the extension is keyed on
On 2/21/25 6:05 AM, Nathaniel Shead wrote:
After seeing PR c++/118964 I'm coming back around to this [1] patch
series, since it appears that this can cause errors on otherwise valid
code by instantiations coming into module purview that reference
TU-local entities.
[1]: https://gcc.gnu.org/piper
On Fri, 21 Feb 2025, Nathaniel Shead wrote:
> After seeing PR c++/118964 I'm coming back around to this [1] patch
> series, since it appears that this can cause errors on otherwise valid
> code by instantiations coming into module purview that reference
> TU-local entities.
>
> [1]: https://gcc.g
After seeing PR c++/118964 I'm coming back around to this [1] patch
series, since it appears that this can cause errors on otherwise valid
code by instantiations coming into module purview that reference
TU-local entities.
[1]: https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650324.html
We'd p
On 2/12/25 1:07 PM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
There are two separate issues making various template parameters behave
as if they were TU-local.
Firstly, the TU-local detection code uses WILDCARD_TYPE_P to check for
t
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
There are two separate issues making various template parameters behave
as if they were TU-local.
Firstly, the TU-local detection code uses WILDCARD_TYPE_P to check for
types that are not yet concrete; for some reason UNBO
On Wed, 12 Feb 2025, Nathaniel Shead wrote:
> On Mon, Jan 27, 2025 at 10:20:05AM -0500, Patrick Palka wrote:
> > [snip]
> >
> > > @@ -18486,6 +18562,12 @@ dependent_operand_p (tree t)
> > > {
> > >while (TREE_CODE (t) == IMPLICIT_CONV_EXPR)
> > > t = TREE_OPERAND (t, 0);
> > > +
> > > +
On Mon, Jan 27, 2025 at 10:20:05AM -0500, Patrick Palka wrote:
> [snip]
>
> > @@ -18486,6 +18562,12 @@ dependent_operand_p (tree t)
> > {
> >while (TREE_CODE (t) == IMPLICIT_CONV_EXPR)
> > t = TREE_OPERAND (t, 0);
> > +
> > + /* If we contain a TU_LOCAL_ENTITY assume we're non-dependent;
On Sun, Feb 09, 2025 at 01:16:00AM +1100, Nathaniel Shead wrote:
> Tested on x86_64-pc-linux-gnu, OK for trunk if full bootstrap + regtest
> passes?
>
> -- >8 --
>
> There are two issues with no-linkage decls (e.g. explicit type aliases)
> in unnamed namespaces that this patch fixes.
>
> Firstly
Tested on x86_64-pc-linux-gnu, OK for trunk if full bootstrap + regtest
passes?
-- >8 --
There are two issues with no-linkage decls (e.g. explicit type aliases)
in unnamed namespaces that this patch fixes.
Firstly, we don't currently handle exporting no-linkage decls in unnamed
namespaces. This
On Fri, Feb 07, 2025 at 11:11:21AM -0500, Jason Merrill wrote:
> On 2/7/25 9:28 AM, Nathaniel Shead wrote:
> > On Fri, Feb 07, 2025 at 08:14:23AM -0500, Jason Merrill wrote:
> > > On 1/31/25 8:46 AM, Nathaniel Shead wrote:
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> >
On 2/7/25 9:28 AM, Nathaniel Shead wrote:
On Fri, Feb 07, 2025 at 08:14:23AM -0500, Jason Merrill wrote:
On 1/31/25 8:46 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
Happy to remove the custom inform for lambdas, but I felt that the
original messa
On Fri, Feb 07, 2025 at 08:14:23AM -0500, Jason Merrill wrote:
> On 1/31/25 8:46 AM, Nathaniel Shead wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> >
> > Happy to remove the custom inform for lambdas, but I felt that the
> > original message (which suggests that defi
On 1/31/25 8:46 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
Happy to remove the custom inform for lambdas, but I felt that the
original message (which suggests that defining it within a class should
make it OK) was unhelpful here.
Similarly the 'i
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
Happy to remove the custom inform for lambdas, but I felt that the
original message (which suggests that defining it within a class should
make it OK) was unhelpful here.
Similarly the 'is_exposure_of_member_type' function is not ne
On Mon, Jan 27, 2025 at 10:20:05AM -0500, Patrick Palka wrote:
> On Sat, 12 Oct 2024, Nathaniel Shead wrote:
>
> > This version rewords all "ignored exposures" language.
> >
> > I haven't fixed up the issue with DECL_TEMPLATE_INSTANTIATIONS for this
> > patch. I'll try to get to that as a separa
On Sat, 12 Oct 2024, Nathaniel Shead wrote:
> This version rewords all "ignored exposures" language.
>
> I haven't fixed up the issue with DECL_TEMPLATE_INSTANTIATIONS for this
> patch. I'll try to get to that as a separate patch if I find the time,
> but it's not 100% needed here I don't think.
On 1/23/25 10:15 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
This fills in a hole left in r15-6378-g9016c5ac94c557 with regards to
detection of TU-local lambdas. Now that LAMBDA_EXPR_EXTRA_SCOPE is
properly set for most lambdas we can us
On 1/23/25 10:16 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
This fixes ICEs where unattached lambdas at class scope (for instance,
in member template instantiations) are streamed. This is only possible
in header units, as in name
On 1/23/25 11:50 AM, yxj-github-437 wrote:
On 1/15/25 7:36 PM, yxj-github-437 wrote:
On Fri, Jan 03, 2025 at 05:18:55PM +, xxx wrote:
From: yxj-github-437 <2457369...@qq.com>
This patch attempts to fix an error when build module std. The reason for the
error is __builrin_va_list (aka struc
On 1/23/25 5:11 PM, Nathaniel Shead wrote:
On Thu, Jan 23, 2025 at 04:47:32PM -0500, Jason Merrill wrote:
On 1/6/25 7:24 AM, Nathaniel Shead wrote:
Happy to defer this till GCC16 if preferred.
-- >8 --
This fills in a hole left in r15-6378-g9016c5ac94c557 with regards to
detection of TU-local
On Thu, Jan 23, 2025 at 04:47:32PM -0500, Jason Merrill wrote:
> On 1/6/25 7:24 AM, Nathaniel Shead wrote:
> > Happy to defer this till GCC16 if preferred.
> >
> > -- >8 --
> >
> > This fills in a hole left in r15-6378-g9016c5ac94c557 with regards to
> > detection of TU-local lambdas. Now that L
On 1/6/25 7:24 AM, Nathaniel Shead wrote:
Happy to defer this till GCC16 if preferred.
-- >8 --
This fills in a hole left in r15-6378-g9016c5ac94c557 with regards to
detection of TU-local lambdas. Now that LAMBDA_EXPR_EXTRA_SCOPE is
properly set for most lambdas we can use it to detect lambdas
>On 1/15/25 7:36 PM, yxj-github-437 wrote:
>>> On Fri, Jan 03, 2025 at 05:18:55PM +, xxx wrote:
From: yxj-github-437 <2457369...@qq.com>
This patch attempts to fix an error when build module std. The reason for
the
error is __builrin_va_list (aka struct __va_list) is a
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
This fixes ICEs where unattached lambdas at class scope (for instance,
in member template instantiations) are streamed. This is only possible
in header units, as in named modules attempting to stream such lambdas
will be a
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
This fills in a hole left in r15-6378-g9016c5ac94c557 with regards to
detection of TU-local lambdas. Now that LAMBDA_EXPR_EXTRA_SCOPE is
properly set for most lambdas we can use it to detect lambdas that are
TU-local.
Lam
On 1/22/25 6:30 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
When we started streaming the bit to handle merging of imported temploid
friends in r15-2807, I unthinkingly only streamed it in the
'!state->is_header ()' case.
This pat
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
When we started streaming the bit to handle merging of imported temploid
friends in r15-2807, I unthinkingly only streamed it in the
'!state->is_header ()' case.
This patch reworks the streaming logic to ensure that this d
On 21/01/2025 21:58, Jason Merrill wrote:
On 1/15/25 7:36 PM, yxj-github-437 wrote:
On Fri, Jan 03, 2025 at 05:18:55PM +, xxx wrote:
From: yxj-github-437 <2457369...@qq.com>
This patch attempts to fix an error when build module std. The
reason for the
error is __builrin_va_list (aka struc
On 1/15/25 7:36 PM, yxj-github-437 wrote:
On Fri, Jan 03, 2025 at 05:18:55PM +, xxx wrote:
From: yxj-github-437 <2457369...@qq.com>
This patch attempts to fix an error when build module std. The reason for the
error is __builrin_va_list (aka struct __va_list) is an internal linkage. so
atte
On 1/20/25 6:54 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
In r15-4862 we ensured that merging a partial specialisation would
properly update its TYPE_CANONICAL. However, this confuses the deduping
mechanism, since the canonical
On 1/19/25 4:39 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
When looking at PR c++/118513 I noticed that we don't currently check
the linkage of structured binding declarations in modules. This patch
adds those checks, and correct
On 1/18/25 10:16 PM, Nathaniel Shead wrote:
On Fri, Jan 17, 2025 at 11:35:19AM -0500, Patrick Palka wrote:
On Fri, 17 Jan 2025, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
In the linked testcase, we're erroring because the declared return
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
In r15-4862 we ensured that merging a partial specialisation would
properly update its TYPE_CANONICAL. However, this confuses the deduping
mechanism, since the canonical type has updated out from under it,
causing is_match
1 - 100 of 684 matches
Mail list logo
