https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500
--- Comment #15 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to R. Diez from comment #13) > From your comments about "constexpr constructor" and "constinit", I gather > that the "eh_globals" singleton is guaranteed then to be initialised very > early, earlier than anything else that might use it, right? But that does At compile time, before any code executes. > not guarantee that it will be destroyed later than anything that wants to > use it, is that correct? That is why we need the hack, to make it outlive > all potential users. Yes, the destruction is dynamic, and so not ordered relative to destructors in other translation units. > Therefore, destroying this object should have real no effect. I wonder why > there was a problem to fix in 'eh_globals' then. Read the bug. There was another global with a non-trivial destructor, which had problems due to destructor ordering. Without using the constant_init type to make the eh_globals variable immortal, its destructor would still logically "run" at some point before or after destruction of the other globals in that translation unit. That is true even if the destructor is trivial and no code actually "runs". The current solution avoids that, because its destructor never runs. Its lifetime would end when the storage is reused, but it's a global so that doesn't happen. The object is effectively immortal, and we don't run foul of optimizers making assumptions about object lifetime. > This all feels iffy. If I understand this correctly, it is impossible for > GCC to guarantee the correct construction and destruction order of such > global objects, and that is why we are hacking our way out. The reason is > mainly, that not all targets support "__attribute__ constructor", so there > is no way to implement a deterministic initialisation and destruction order > for everybody. Is that right? I don't consider this a hack, unlike using init priority. Constant initialization is better than dynamic initialization where possible, so I see no reason to forego constant initialization for dynamic initialization that then needs init priority to make it work reliably. Constant init is always reliable.
