https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98110
--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> --- In the glibc bugzilla or on private IRC I've suggested either: diff --git a/sysdeps/x86_64/nptl/tls.h b/sysdeps/x86_64/nptl/tls.h index a08bf972de..ccb5f24d92 100644 --- a/sysdeps/x86_64/nptl/tls.h +++ b/sysdeps/x86_64/nptl/tls.h @@ -180,11 +180,16 @@ _Static_assert (offsetof (tcbhead_t, __glibc_unused2) == 0x80, assignments like pthread_descr self = thread_self(); do not get optimized away. */ -# define THREAD_SELF \ +# if __GNUC_PREREQ (6, 0) +# define THREAD_SELF \ + (*(struct pthread *__seg_fs *) offsetof (struct pthread, header.self)) +# else +# define THREAD_SELF \ ({ struct pthread *__self; \ asm ("mov %%fs:%c1,%0" : "=r" (__self) \ : "i" (offsetof (struct pthread, header.self))); \ __self;}) +# endif /* Magic for libthread_db to know how to do THREAD_SELF. */ # define DB_THREAD_SELF_INCLUDE <sys/reg.h> /* For the FS constant. */ or diff --git a/sysdeps/x86_64/nptl/tls.h b/sysdeps/x86_64/nptl/tls.h index a08bf972de..f3cbae9cba 100644 --- a/sysdeps/x86_64/nptl/tls.h +++ b/sysdeps/x86_64/nptl/tls.h @@ -180,11 +180,21 @@ _Static_assert (offsetof (tcbhead_t, __glibc_unused2) == 0x80, assignments like pthread_descr self = thread_self(); do not get optimized away. */ -# define THREAD_SELF \ +# if __GNUC_PREREQ (6, 0) +# define THREAD_SELF \ + ({ struct pthread *__self; \ + asm ("mov %%fs:%c1,%0" : "=r" (__self) \ + : "i" (offsetof (struct pthread, header.self)), \ + "m" (*(struct pthread *__seg_fs *) \ + offsetof (struct pthread, header.self))); \ + __self;}) +# else +# define THREAD_SELF \ ({ struct pthread *__self; \ asm ("mov %%fs:%c1,%0" : "=r" (__self) \ : "i" (offsetof (struct pthread, header.self))); \ __self;}) +# endif /* Magic for libthread_db to know how to do THREAD_SELF. */ # define DB_THREAD_SELF_INCLUDE <sys/reg.h> /* For the FS constant. */ With make check I'm seeing 153 glibc FAILs with trunk with the first patch, about to make check the second one, but maybe I'm doing something wrong or there are other gcc or glibc bugs unrelated to this one. I think it would be good to try these patches with GCC 10 first to see if those patches don't break stuff with known working compilers and only then look at the failed tests if any. Florian said he'll take it over on the glibc side.