From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id A49E53858D28; Wed, 2 Nov 2022 13:29:14 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A49E53858D28 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1667395754; bh=UmTpLQI4TSrJBDHGkQlXc4+j7rUfMJGrJXtShJnGPOU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=VqsT3WrkJlEevrdz5et6nDw4w08H71c7RD31IVCv/YTntswMQohKRwU4Hh/CDudip Qgn/lONmW6FF7HuZ6EtpgIf5EfzvA0EarDWvPo7yRDV8/E22R89uLI7eRbjbJwXw52 WvJc+O1XyBbjlpw3hUL6jg6rU1rlwFxf7uzzMe+g= From: "rdiezmail-gcc at yahoo dot de" 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 13:29:14 +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: rdiezmail-gcc at yahoo dot de 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 #8 from R. Diez --- 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 t= hat '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 initialisat= ion 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 anyw= ay 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-embed= ded environments. But it is not just the amount of memory. As I mentioned, my c= ode 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 droppi= ng the ball here too, even more people will consider moving to clang.=