https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500
--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to R. Diez from comment #8) > Why does this 'eh_globals' object have to use a constexpr constructor? So it can be constinit. > 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? Because that's what constinit means. https://en.cppreference.com/w/cpp/language/constinit > 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. No, it doesn't work on all targets supported by GCC and libstdc++. > 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. The "if you don't fix this people will switch to clang" threat is not as motivating as you might think. It gets tedious after the thousandth time you hear it. I've confirmed the bug as a missed-optimization, and suggested ways the compiler might be able to solve it. I am not going to reintroduce race conditions in libstdc++ to work around your needs here. If you think GCC (and libstdc++ in particular) doesn't care about embedded then you're not paying attention. The changes to eh_globals.cc were introduced for PR105880 specifically to solve a bug on embedded targets using newlib. And there have been more than a dozen commits in the past month making huge parts of libstdc++ more usable on bare metal. If you think the codegen for empty functions can be improved, please file a separate bug as that's not the same topic as optimizing away atexit calls for empty destructors.
