[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