thread_local + clang crash

[seppeon]

Hello, the following demo results in a crash:

https://godbolt.org/z/Gbv3dvaeE

The thread local storage doesn't appear to be initialized.

The error is stated as:

Exception 0xc0000005 encountered at address 0x7ff694b72354: Access violation writing location 0x1df6895df38

It occurs on the placement new, I suspect it'd happen with any memory assignment.

clang++.exe flags:

_SILENCE_CLANG_COROUTINE_MESSAGE
_WIN32_WINNT=0x0602 
WINVER=0x0602 
_WIN32_IE=0x0602 
CSIDL_MYMUSIC=0x000D 
CSIDL_MYVIDEO=0x000E 
-g
-march=native
-static
-gdwarf-3
-fno-omit-frame-pointer
-ftemplate-depth=65536
-fconstexpr-steps=51200000
-msse2
-msse3
-mssse3
-msse4.1
-msse4.2
-mavx
-mavx2
-std=gnu++20

[brechtsanders]

winlibs.com support for LLVM/CLang is still a work in progress. If you can reproduce this with other builds of LLVM/CLang you should report the issue with the LLVM team.

[seppeon]

winlibs.com support for LLVM/CLang is still a work in progress. If you can reproduce this with other builds of LLVM/CLang you should report the issue with the LLVM team.

I haven't been able to reproduce elsewhere.

[seppeon]

This is a significantly simpler test case:

struct MyObj {
    [[gnu::noinline]] MyObj(){}
    ~MyObj(){}
};

MyObj &func() {
    thread_local MyObj thing;
    return thing;
}

int main()
{
    func();
    return 0;
}

[seppeon]

Seems to work with MSYS2 clang 13.0.0 + mingw.

[brechtsanders]

I will keep this issue open until my next build of LLVM/Clang.

The goal is to have have LLVM/Clang in a seperate package from GCC and to abandon GCC standard library compatibility, and instead use LLVM's own standard standard libraries.