On Wednesday, 21 January 2026 14:18:43 Pacific Standard Time Levo D via Std-
Proposals wrote:
> Could we fix this somehow?

It isn't broken.

GCC is missing some optimisation opportunities there, by emitting the check
for the initialisation routine's presence repeatedly. Switch to Clang and
you'll see that it generates much better code. Not that it's perfect: I don't
understand why it emitted a call to flush(), because the condition should have
been obvious to be impossible. Maybe it's thinking that the object could
change between function calls?

> In the link below, someone has written an
> explanation of the problem. In short, the problem is that we can't see how
> it's initialized
> https://discourse.llvm.org/t/whats-with-thread-local-calling-an-initalizer/8
> 9459/6

Indeed.

>
> I was thinking about allowing something like `extern MyClass myObj{i,
> promise, to, init, like, _this_};` However, this may break some behavior.

What behaviour might it break? Because it compiles.

It is even better if you do initialise the array:
https://godbolt.org/z/xMP1qYqYE

> Or
> `[[no_initalizer]] extern MyClass myObj;`

This one semantically makes no sense. It must have an initialiser.

> Or have some kind of rule so it isn't dynamically initialized.

It must be initialised.

> I get into situations where I can't use the gcc __thread attribute, and it
> occasionally is annoying
>
> How should we fix this? It’s a problem in both gcc and clang

There is no problem.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Data Center - Platform & Sys. Eng.