[PATCH] w32: Use __declspec(thread) for FIPS thread context TLS
Martin Storsjö
martin at martin.st
Sat Dec 13 19:13:05 CET 2025
On Sat, 13 Dec 2025, Knugi via Gcrypt-devel wrote:
> The proposed change, which uses conditional compilation to replace
> __thread with __declspec(thread) when __MINGW32__ is defined, provides
> a viable solution. This approach is effective because __declspec(thread)
> is a Windows-native API that leverages the OS's built-in TLS mechanism,
> thereby eliminating the dependency on the aforementioned DLLs and ensuring
> the library loads correctly on all Windows targets.
Sorry, but I don't think this part is true.
The compiler uses its choice of mechanism for thread local variables,
regardless of the syntax for specifying that it is thread local. (Either
"__thread", or "thread_local", etc.)
With GCC, this is emutls (which does depend on libgcc, as you've noticed).
Clang in mingw mode defaults to Windows native TLS, but by passing
-femulated-tls, one can make it use the same mechanism as GCC.
Using "__declspec(thread)" in mingw mode doesn't do anything at all; with
GCC it produces the following warning:
tls.c:2:1: warning: ‘thread’ attribute directive ignored [-Wattributes]
2 | int __declspec(thread) var1;
| ^~~
With Clang it produces the following warning:
tls.c:2:16: warning: unknown attribute 'thread' ignored [-Wunknown-attributes]
2 | int __declspec(thread) var1;
| ^~~~~~
To see this for yourselves, see https://gcc.godbolt.org/z/K3snhT1rc.
With the upcoming GCC 16, it should be possible to use the Windows native
TLS mechanism with GCC as well - but this is a choice that is made when
GCC is configured and built; the syntax used for declaring the variable as
thread local does not affect it.
// Martin
More information about the Gcrypt-devel
mailing list