ICE with extern(C++)

[TurkeyMan]

1>d\ud\platform\dbg.d(28): Error: variable ud.platform.dbg.S.s ICE: C++ static non- __gshared non-extern variables not supported
1>Assertion failed: 0, file D:\OpenSource\ldc\ldc-release\dmd2\cppmangle.c, line 298

ICE with popup error dialog probably not the best way to inform the user of the problem here:

extern (C++):

struct S
{
  static int s;
}

• Latest MSVC LDC

[TurkeyMan]

That said, it would be nice if TLS variables were supported with extern (C++), since this actually is a C++ struct I'm trying to link against.

[redstar]

Same as #928 and #929. We really need to fix the frontend here.

[TurkeyMan]

Any comment on the extern to C++ TLS?
Know if DMD has plans to support this? Can LDC support it? Is it LLVM that handles TLS?

[dnadlinger]

It is likely just an arbitrary restriction in the frontend because nobody has needed it so far. We should definitely be able to implement it in LDC. LLVM does the TLS handling for us, we only need to get the C++ mangling correct. As for DMD: @yebblies?

[TurkeyMan]

Just to be clear, the static in the struct above is deliberately a TLS; it is declared __thread in the C++ counterpart.

[TurkeyMan]

And it raises the question, is the LLVM MSVC support compatible with MSC's TLS?
Ie, __declspec(thread) in MSVC terms.

[redstar]

There is no special name mangling with thread local variables in Visual C++. LLVM uses the same approach as Visual C++ therefore LDC should be compatible with MSC's TLS.
I look if I can enable the support.

[TurkeyMan]

Cool. I'm surprised they don't mangle differently, there must be some serious ABI difference for TLS from extern "C"?

[dnadlinger]

These errors do not crash the compiler any longer. To actually add support for further parts of C++, the changes should go into the upstream frontend first.