@llvm/pr-subscribers-libc

Author: Alexey Samsonov (vonosmas)

diff --git a/libc/include/__llvm-libc-common.h b/libc/include/__llvm-libc-common.h
index 1fe3f4d2aea9c..70d8263e63b65 100644
--- a/libc/include/__llvm-libc-common.h
+++ b/libc/include/__llvm-libc-common.h
@@ -37,9 +37,6 @@
 #undef _Alignof
 #define _Alignof alignof
 
-#undef _Thread_local
-#define _Thread_local thread_local
-
 #undef __NOEXCEPT
 #if __cplusplus >= 201103L
 #define __NOEXCEPT noexcept

I don't think we should remove this definition from our public header. This is an alternative form of thread_local that is specified in C standard. So we should provide it in our public headers.

I'd like to confirm what we actually want to provide. E.g. this change removed _Thread_local macro declaration that was only used for C++ code (it was under #ifdef __cplusplus section), which looks confusing to me, since _Thread_local is not a C++ keyword. Do we want it to work there?

As for C, IIUC (per https://en.cppreference.com/w/c/keyword.html), _Thread_local is a C keyword between C11 and C23, but then <threads.h> is actually responsible for providing the opposite transition between C11 and C23 (https://en.cppreference.com/w/c/thread/thread_local.html). Shouldn't we only retain #define _Thread_local thread_local for compatibility purposes, and only in C mode, and when we're compiling for C23 or later?

Shouldn't we only retain #define _Thread_local thread_local for compatibility purposes, and only in C mode, and when we're compiling for C23 or later?

C23 6.4.1 points out that _Thread_local (along with a few other things) is special --- you can say either thread_local or _Thread_local in C23, and it's left to the implementation to worry about how exactly that's implemented.

There is no need for any spelling of the thread-local storage class in the public libc API right now. So it's correct to leave any related header support out for now. If we (re-)introduce a public ABI using a thread-local variable exposed in a public header, then we will address all the complexities of different C and C++ language versions and extensions and how best to declare these variables in public headers.

C23 6.4.1 points out that _Thread_local (along with a few other things) is special --- you can say either thread_local or _Thread_local in C23, and it's left to the implementation to worry about how exactly that's implemented.

Right, so if in C23 _Thread_local is just an alternative spelling of thread_local, then we don't need to do anything in libc headers, and it's the compiler responsibility to properly treat those keywords?

C23 6.4.1 points out that _Thread_local (along with a few other things) is special --- you can say either thread_local or _Thread_local in C23, and it's left to the implementation to worry about how exactly that's implemented.

Right, so if in C23 _Thread_local is just an alternative spelling of thread_local, then we don't need to do anything in libc headers, and it's the compiler responsibility to properly treat those keywords?

that is my understanding, yes. (since it's in 6.4 "lexical elements" rather than in the library.)