[PATCH] libstdc++: bvector: undef always_inline macro

[Alexandre Oliva]

On Nov  9, 2023, Jonathan Wakely <jwakely@redhat.com> wrote:

> On Thu, 9 Nov 2023 at 19:49, Alexandre Oliva <oliva@adacore.com> wrote:
>> 
>> On Nov  9, 2023, Jonathan Wakely <jwakely@redhat.com> wrote:
>> 
>> > But I've just realised we probably want to #undef the macro at the end
>> > of bits/stl_bvector.h too.
>> 
>> I'm not sure why (what if another libstdc++ header were to define the
>> macro, includes stl_bvector.h, and then use the macro expecting it to
>> still be there?), but I suppose this is what you mean.

> It's consistent with all the other definitions of the macro in our
> headers. We always define it locally and then undef it again at the
> end of the header. You're right that that makes it rather hard to use
> reliably.

Not only that.  It also seems to cause failures, but I messed up in my
testing and didn't catch them.

We've seen gcc-13 regressions in g++.dg/modules/xtreme-header* and
27_io/basic_syncbuf/sync_ops/1.cc.  I suspect they're going to show up
in trunk as well starting today, since I've just installed this bit
(unfortunately, shortly before I learned about the regressions)

I'm about to rerun trunk testing and, if I confirm the regressions, I'll
revert this followup patch.

The symptom in gcc-13 is that bits/semaphore_base.h fails to compile
because _GLIBCXX_ALWAYS_INLINE is no longer available.  AFAICT it relied
on the define from bits/atomic_base.h included by <atomic>, but <chrono>
includes <vector> that, in stl_bvector.h, undefines the macro, and then
when bits/semaphore_base.h includes bits/atomic_base.h again, the macro
doesn't get defined again.  We should probably define and undefine it
explicitly in semaphore_base.h as well, and everywhere else that uses
it, if the current policy is to be maintained.

Backporters beware ;-)

>> * include/bits/stl_bvector.h (_GLIBCXX_ALWAYS_INLINE): Undef.

-- 
Alexandre Oliva, happy hacker            https://FSFLA.org/blogs/lxo/
   Free Software Activist                   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive