[PATCH, FYI] libstdc++: vxworks: enable gthread_yield

[Jonathan Wakely]

On Wed, 24 Jun 2026 at 14:33, Jonathan Wakely <jwakely@redhat.com> wrote:
>
> On Wed, 24 Jun 2026 at 13:41, Alexandre Oliva <oliva@adacore.com> wrote:
> >
> > On Jun 24, 2026, Jonathan Wakely <jwakely@redhat.com> wrote:
> >
> > > What do you think?
> >
> > No opposition from me.  Maybe it would make more sense to require any
> > gthreads implementation to offer gthread_yield, so that libstdc++ could
> > call it unconditionally.
> >
> > Worst case, it could be a do-nothing implementation.
>
> According to libgcc/gthr.h it's already required if __GTHREADS_CXX0X
> is defined, and libstdc++ defines _GLIBCXX_HAS_GTHREADS when
> __GTHREADS_CXX0X is defined. So maybe we should replace uses of
> USE_SCHED_YIELD with HAS_GTHREADS.

Ugh, I remember the history now. Old Solaris systems required librt.so
in order to use sched_yield. So it's not sufficient to know that
__gthread_yield() is available, we also need to check whether we can
call it without requiring librt.so

So that's why we have the USE_SCHED_YIELD macro. It means that
__gthread_yield() exists, and we can use it without getting linker
errors.

But in the Solaris systems that are still supported today, sched_yield
is in libc.so and I think we can clean up all the related configury.
Please go ahead with your patch, I'll clean it up for GCC 17 later in
stage 1.