From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 7BBBF3858D20; Wed, 2 Nov 2022 14:17:00 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7BBBF3858D20 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1667398620; bh=hXiTbDhwAnL/KmOqtqP69xV8QfT1TK0vt/og94aM6kQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=BcpoDeCEGrxhIGn5aUfz9HuT04coSs29+BauOMRRNazdrNFt3lA8KA2UcTXfkW9zw DHbVA65VVIkYSgAWuz2ISWVwehUYqppJt+ZLwgMLzbvRmEapSlrFqnmxWNTW0JjUp3 iQ5/R6wDiZ5nyRanoG4+jQwBvT5Mkry4GpHaAQhg= From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/107500] Useless atexit entry for ~constant_init in eh_globals.cc Date: Wed, 02 Nov 2022 14:17:00 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 12.2.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: redi at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D107500 --- Comment #10 from Jonathan Wakely --- (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. >=20 > 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 G= CC > 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. A= s I > mentioned, my code is checking that nothing unexpected registers an atexi= t() > destructor. If libstdc++ does that on start-up, it becomes hard to tell > whether something unexpected has been added recently. >=20 > 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 clan= g. 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 f= or 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 par= ts 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 f= or empty destructors.=