| Issue |
79714
|
| Summary |
[Clang] [MinGW] Dllimported thread local variables not allowed when using emulated TLS
|
| Labels |
clang
|
| Assignees |
|
| Reporter |
mstorsjo
|
Clang uses Windows native TLS by default for MinGW targets, contrary to GCC, which uses emulated TLS. Native TLS has one big practical limitation; one cannot directly access such a TLS variable from another DLL - while this is allowed with emulated TLS.
When declaring a dllimported variable as thread local, Clang rightfully errors out when using native TLS. However, when using emulated TLS, such a construct could be allowed - GCC does allow and compile it:
```c
extern __declspec(dllimport) int __thread libdata;
int get(void) { return libdata; }
```
```console
$ x86_64-w64-mingw32-gcc tls-dllimport.c -S -o - -O2
get:
subq $40, %rsp
movq __imp___emutls_v.libdata(%rip), %rcx
call __emutls_get_address
movl (%rax), %eax
addq $40, %rsp
ret
$ clang -target x86_64-w64-mingw32 -c tls-dllimport.c -femulated-tls
tls-dllimport.c:1:43: error: 'libdata' cannot be thread local when declared 'dllimport'
1 | extern __declspec(dllimport) int __thread libdata;
| ^
1 error generated.
```
The error is entirely accurate when using native TLS, but with `-femulated-tls`, one could consider that it should be allowed - as GCC does allow it.
![]()
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
