On 10/8/24 8:58 AM, Michael Matz wrote:
Hello,
On Tue, 8 Oct 2024, Jonathan Wakely wrote:
We originally had global static variables, which means a different
variable per TU. That causes ODR violations which were silently
ignored until we try to use them in modules, where they're diagnosed.
So
On Tue, 8 Oct 2024 at 13:59, Michael Matz wrote:
>
> Hello,
>
> On Tue, 8 Oct 2024, Jonathan Wakely wrote:
>
> > We originally had global static variables, which means a different
> > variable per TU. That causes ODR violations which were silently
> > ignored until we try to use them in modules, w
Hello,
On Tue, 8 Oct 2024, Jonathan Wakely wrote:
> We originally had global static variables, which means a different
> variable per TU. That causes ODR violations which were silently
> ignored until we try to use them in modules, where they're diagnosed.
> So we need to replace them.
Aren't th
On Tue, Oct 08, 2024 at 11:32:16AM +0100, Jonathan Wakely wrote:
> But that's because foo() is declared static, which we can't do because
> of C++ modules. That was the original problem Nathaniel was fixing.
>
> If you remove the 'static' from foo() then both z and _ZZ3foovE1v use
> @gnu_unique_ob
On Tue, 8 Oct 2024 at 11:11, Jakub Jelinek wrote:
>
> On Tue, Oct 08, 2024 at 10:57:06AM +0100, Jonathan Wakely wrote:
> > Whoops, yes of course. Raising the topic of __cxa_guard_acquire was my
> > fault, and doesn't apply here, sorry.
> >
> > But we still want to get rid of the STB_GNU_UNIQUE bin
On Tue, Oct 08, 2024 at 10:57:06AM +0100, Jonathan Wakely wrote:
> Whoops, yes of course. Raising the topic of __cxa_guard_acquire was my
> fault, and doesn't apply here, sorry.
>
> But we still want to get rid of the STB_GNU_UNIQUE binding for the
> static variables, don't we?
I think it is the
On Tue, 8 Oct 2024 at 10:28, Jakub Jelinek wrote:
>
> On Tue, Oct 08, 2024 at 08:18:56PM +1100, Nathaniel Shead wrote:
> > On Tue, Oct 01, 2024 at 12:36:21PM +0200, Jakub Jelinek wrote:
> > > On Tue, Oct 01, 2024 at 11:10:03AM +0100, Jonathan Wakely wrote:
> > > > Let's use an inline variable. A f
On Tue, Oct 08, 2024 at 08:18:56PM +1100, Nathaniel Shead wrote:
> On Tue, Oct 01, 2024 at 12:36:21PM +0200, Jakub Jelinek wrote:
> > On Tue, Oct 01, 2024 at 11:10:03AM +0100, Jonathan Wakely wrote:
> > > Let's use an inline variable. A function-local static requires
> > > __cxa_guard_acquire, whic
So something like this maybe; bootstrapped and regtested on
x86_64-pc-linux-gnu and aarch64-unknown-linux-gnu, OK for trunk?
Or maybe it would be clearer to do the #ifdef __cplusplus here locally
rather than introducing a new __GTHREAD_VAR macro?
-- >8 --
Subject: [PATCH] libgcc: Use inli
