[Bug c++/107500] Useless atexit entry for ~constant_init in eh_globals.cc

["rdiezmail-gcc at yahoo dot de" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500

--- Comment #8 from R. Diez <rdiezmail-gcc at yahoo dot de> ---
Why does this 'eh_globals' object have to use a constexpr constructor?

How does the current code avoid the "static initialization order fiasco"? If
the user defines his/her own static C++ objects, how is it guaranteed now that
'eh_globals' is initialised before all other user code?

Isn't using the "__attribute__ constructor" trick safer anyway? With it, you
can document what priority levels libstdc++ uses. The user may even want to run
a few routines before libstdc++ initialises. Flexibility in the initialisation
order is often important in embedded environments.

Portability is not really an issue. You can just "#ifdef GCC" around the
"better" hack. Is GCC not using "__attribute__ constructor" internally anyway
to implement such static constructors? So anybody using C++ with GCC must
support that mechanism already.

And about saving a few bytes, 400 bytes is no small amount in tightly-embedded
environments. But it is not just the amount of memory. As I mentioned, my code
is checking that nothing unexpected registers an atexit() destructor. If
libstdc++ does that on start-up, it becomes hard to tell whether something
unexpected has been added recently.

I can surely put up with yet another little annoyance with this new GCC
version. But bear in mind that flexibility and attention to detail in the
embedded world is one of GCC's few remaining bastions. If GCC starts dropping
the ball here too, even more people will consider moving to clang.