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

[Jonathan Wakely]

On Wed, 15 Nov 2023 at 02:44, Alexandre Oliva <oliva@adacore.com> wrote:
>
> 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.

Yes, please revert. I misremembered.

I thought I even checked my assumption, but I don't see it in my shell
history now.

Sorry for the mixup.

>
> 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
>