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, which (for some targets, including the ones
> > > affected by this change) uses __gthread_active_p which will
> > > recursively re-enter the variable's initialization.
> > >
> > > So something like:
> > >
> > > #pragma GCC diagnostic push
> > > #pragma GCC diagnostic ignored "-Wc++17-extensions"
> > > inline volatile int __gthread_active = -1;
> > > #pragma GCC diagnostic pop
> >
> > Note, only for #ifdef __cplusplus, for C there is no such thing as inline
> > variables and in that case it should use
> > static volatile int __ghtread_active = -1;
> > instead.
> >
> > Jakub
> >
>
> 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?
Actually, had a look again at this and I don't see what this is trying to
fix.
A function-local static requires __cxa_guard_acquire only if it needs
dynamic initialization, which is not the case here (the initializers are
= -1). The non-dynamic ones are just initialized that way without any
__cxa_guard_acquire.
So, the function-local static seems more portable than hoping inline vars
will be supported even for older C++ versions.
Jakub
