[Bug libstdc++/95989] Segmentation fault compiling with static libraries and using jthread::request_stop

["redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989

--- Comment #15 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #14)
> > --- a/libgcc/gthr-posix.h
> > +++ b/libgcc/gthr-posix.h
> > @@ -684,7 +684,12 @@ __gthread_equal (__gthread_t __t1, __gthread_t __t2)
> >  static inline __gthread_t
> >  __gthread_self (void)
> >  {
> > +#if __GLIBC_PREREQ(2, 27)
> 
> Hmm, maybe we should just check #ifdef __GLIBC__ here, since it's available
> in libc even before glibc 2.27 (it returns 0 rather than a real tid before
> 2.27, but that's OK).

Except that as Florian said above, it's missing from libc.a prior to 2.27 so if
we used it unconditionally, you wouldn't be able to link statically.

> > --- a/libstdc++-v3/include/std/thread
> > +++ b/libstdc++-v3/include/std/thread
> > @@ -364,13 +364,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> >      inline thread::id
> >      get_id() noexcept
> >      {
> > -#ifdef __GLIBC__
> > +#if defined __GLIBC__ && ! __GLIBC_PREREQ(2, 27)
> 
> And maybe we shouldn't change this check either.
> 
> If we make it depend on the glibc version then because this function is
> inline a program could have two different definitions inlined if different
> objects were compiled by different versions of gcc, or against different
> versions of glibc. One object could inline the version returning
> thread::id(1) and another could inline the version returning
> thread::id(__gthread_self()). This could result in two different IDs for the
> main thread of a single-threaded program. So maybe we should just stick to
> returning thread::id(1) for all glibc versions.

I've decided I'm not too concerned about this. There are probably not many
users of std::this_thread::get_id() in programs not linked with -lpthread, and
any such code will have to deal with a change here once all pthreads symbols
move into glibc's libc anyway. When that happens __gthread_active_p will always
be true. Let's just go ahead and use pthread_self() when it's known to work
(i.e. glibc 2.27 and later).

Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558737.html