On Wed, 24 Jun 2026 at 14:33, Jonathan Wakely <[email protected]> wrote: > > On Wed, 24 Jun 2026 at 13:41, Alexandre Oliva <[email protected]> wrote: > > > > On Jun 24, 2026, Jonathan Wakely <[email protected]> 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.
