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.
