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 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/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
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
On Wed, 3 Jan 2024, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
>
> -- >8 --
>
> Static data members marked 'inline' should be emitted in TUs where they
> are ODR-used. We need to make sure that statics imported from modules
> are correctly added to
On 1/8/24 04:21, Iain Sandoe wrote:
On 6 Jan 2024, at 22:30, Nathan Sidwell wrote:
Richard Smith & I discussed whether we should use the module interface's
capability of giving vague linkage entities a strong location. I didn't want to go
messing with that, 'cos it was changing yet more stuff
> On 6 Jan 2024, at 22:30, Nathan Sidwell wrote:
>
> Richard Smith & I discussed whether we should use the module interface's
> capability of giving vague linkage entities a strong location. I didn't want
> to go messing with that, 'cos it was changing yet more stuff.
>
> But, perhaps we sh
Richard Smith & I discussed whether we should use the module interface's
capability of giving vague linkage entities a strong location. I didn't want to
go messing with that, 'cos it was changing yet more stuff.
But, perhaps we should revisit that? Any keyless polymorphic class in module
purv
On 1/4/24 18:02, Nathaniel Shead wrote:
On Thu, Jan 04, 2024 at 05:42:34PM -0500, Jason Merrill wrote:
On 1/4/24 17:24, Nathaniel Shead wrote:
On Thu, Jan 04, 2024 at 03:31:50PM -0500, Jason Merrill wrote:
On 1/2/24 17:40, Nathaniel Shead wrote:
Static data members marked 'inline' should be e
On Thu, Jan 04, 2024 at 05:42:34PM -0500, Jason Merrill wrote:
> On 1/4/24 17:24, Nathaniel Shead wrote:
> > On Thu, Jan 04, 2024 at 03:31:50PM -0500, Jason Merrill wrote:
> > > On 1/2/24 17:40, Nathaniel Shead wrote:
> > > > Static data members marked 'inline' should be emitted in TUs where they
>
On 1/4/24 17:24, Nathaniel Shead wrote:
On Thu, Jan 04, 2024 at 03:31:50PM -0500, Jason Merrill wrote:
On 1/2/24 17:40, Nathaniel Shead wrote:
Static data members marked 'inline' should be emitted in TUs where they
are ODR-used. We need to make sure that statics imported from modules
are corre
On Thu, Jan 04, 2024 at 03:31:50PM -0500, Jason Merrill wrote:
> On 1/2/24 17:40, Nathaniel Shead wrote:
> > Static data members marked 'inline' should be emitted in TUs where they
> > are ODR-used. We need to make sure that statics imported from modules
> > are correctly added to the 'pending_sta
On 1/2/24 17:40, Nathaniel Shead wrote:
Static data members marked 'inline' should be emitted in TUs where they
are ODR-used. We need to make sure that statics imported from modules
are correctly added to the 'pending_statics' map so that they get
emitted if needed, otherwise the attached testca
On Feb 24, 2023, Richard Earnshaw wrote:
> Given the logic of this macro, the text should be
> "!TARGET_CXX_METHOD_MAY_BE_INLINE".
I was thinking just "related to that macro", but yeah, negating it makes
sense.
> OK with that change.
Thanks, here's what I'm checking in.
[PR105224] C++ module
> On 24 Feb 2023, at 10:23, Richard Earnshaw via Gcc-patches
> wrote:
>
>
>
> On 23/02/2023 21:20, Alexandre Oliva wrote:
>> On Feb 23, 2023, Alexandre Oliva wrote:
>>> On Feb 23, 2023, Richard Earnshaw wrote:
On 22/02/2023 19:57, Alexandre Oliva wrote:
> On Feb 21, 2023, Richard
On 23/02/2023 21:20, Alexandre Oliva wrote:
On Feb 23, 2023, Alexandre Oliva wrote:
On Feb 23, 2023, Richard Earnshaw wrote:
On 22/02/2023 19:57, Alexandre Oliva wrote:
On Feb 21, 2023, Richard Earnshaw wrote:
Rather than scanning for the triplet, a better test would be
{ xfail { a
On Feb 23, 2023, Alexandre Oliva wrote:
> On Feb 23, 2023, Richard Earnshaw wrote:
>> On 22/02/2023 19:57, Alexandre Oliva wrote:
>>> On Feb 21, 2023, Richard Earnshaw wrote:
>>>
Rather than scanning for the triplet, a better test would be
>>>
{ xfail { arm_eabi } }
>>>
>>> Indeed,
On Feb 23, 2023, Richard Earnshaw wrote:
> On 22/02/2023 19:57, Alexandre Oliva wrote:
>> On Feb 21, 2023, Richard Earnshaw wrote:
>>
>>> Rather than scanning for the triplet, a better test would be
>>
>>> { xfail { arm_eabi } }
>>
>> Indeed, thanks. Here's the updated patch, retested. Ok t
On 22/02/2023 19:57, Alexandre Oliva wrote:
On Feb 21, 2023, Richard Earnshaw wrote:
Rather than scanning for the triplet, a better test would be
{ xfail { arm_eabi } }
Indeed, thanks. Here's the updated patch, retested. Ok to install?
Based on Nathan's comments, we should just ski
On Feb 21, 2023, Richard Earnshaw wrote:
> Rather than scanning for the triplet, a better test would be
> { xfail { arm_eabi } }
Indeed, thanks. Here's the updated patch, retested. Ok to install?
[PR105224] C++ modules and AAPCS/ARM EABI clash on inline key methods
From: Alexandre Oliva
On 2/21/23 11:31, Richard Earnshaw wrote:
I started looking at this a few weeks back, but I was a bit confused by the
testcase and then never got around to following up.
The Arm C++ binding rules normally exclude using an inline function definition
from being chosen as the key function becaus
On 21/02/2023 16:31, Richard Earnshaw via Gcc-patches wrote:
On 17/02/2023 06:09, Alexandre Oliva via Gcc-patches wrote:
On Apr 5, 2022, Alexandre Oliva wrote:
Would something like this be acceptable/desirable? It's overreaching,
in that not all arm platforms are expected to fail, but th
On 17/02/2023 06:09, Alexandre Oliva via Gcc-patches wrote:
On Apr 5, 2022, Alexandre Oliva wrote:
Would something like this be acceptable/desirable? It's overreaching,
in that not all arm platforms are expected to fail, but the result on
them will be an unexpected pass, which is not quite a
On Apr 5, 2022, Alexandre Oliva wrote:
> Would something like this be acceptable/desirable? It's overreaching,
> in that not all arm platforms are expected to fail, but the result on
> them will be an unexpected pass, which is not quite as bad as the
> unexpected fail we get on most arm variant
On Mar 31, 2022, Alexandre Oliva wrote:
> g++.dg/modules/virt-2_a.C fails on arm-eabi and many other arm targets
> that use the AAPCS variant. ARM is the only target that overrides
> TARGET_CXX_KEY_METHOD_MAY_BE_INLINE. It's not clear to me which way the
> clash between AAPCS and C++ Modules de
Correction to what I just wrote:
On 25.01.21 11:02, Tobias Burnus wrote:
Executing on $remote_host: rm -f
gcm.cache/$srddir/g++.dg/modules/concept-4.H.gcm(timeout = 360)
→ This deletes in gcm.cache/$srddir
Executing on host: cp -pf /$srcdir/g++.dg/modules/concept-4.H concept-4.H
Executing
Awesome!
On Fri, Jul 5, 2019, 2:30 PM Nathan Sidwell wrote:
> Hi all,
> I have achieved a major milestone in adding C++ Modules support to GCC.
> Namely the iostream header can be built and used as a header unit.
> #including includes an awful lot of the STL, so this has
> pushed a large swathe
On 02/12/2017 05:58 AM, Gerald Pfeifer wrote:
On Mon, 6 Feb 2017, Nathan Sidwell wrote:
Are you planning to add this to svn.html
Ah, thanks for the reminder.
And here's the patch I committed to document the branch.
nathan
--
Nathan Sidwell
? htdocs/.#svn.html.1.208
Index: htdocs/svn.html
==
On Mon, 6 Feb 2017, Nathan Sidwell wrote:
Are you planning to add this to svn.html
Ah, thanks for the reminder.
First, here's a patch to collate the existing list, ok?
Oh, definitely. This makes sense, and I trust your sorting
skills. :-)
(It seems quite a few may be dead now, time for som
On 02/05/2017 02:58 PM, Gerald Pfeifer wrote:
On Tue, 24 Jan 2017, Nathan Sidwell wrote:
As some have already noticed, I created a c++-modules branch yesterday.
Don't get too excited, that doesn't mean I have an implementation to
commit there.
Are you planning to add this to svn.html (where we
On Tue, 24 Jan 2017, Nathan Sidwell wrote:
> As some have already noticed, I created a c++-modules branch yesterday.
> Don't get too excited, that doesn't mean I have an implementation to
> commit there.
Are you planning to add this to svn.html (where we generally
describe all branches)?
Gerald
Woo!
On Tue, Jan 24, 2017 at 8:05 AM, Nathan Sidwell wrote:
> As some have already noticed, I created a c++-modules branch yesterday.
> Don't get too excited, that doesn't mean I have an implementation to commit
> there.
>
> I expect several false starts, and don't intend to post patches here.
>
32 matches
Mail list logo
