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
