> From: Patrick Palka via Gcc-patches <gcc-patches@gcc.gnu.org> > Date: Fri, 4 Nov 2022 16:05:25 +0100
> This patch moves the global object for constructing the standard streams > out from <iostream> and into the compiled library on targets that support > the init_priority attribute. This means that <iostream> no longer > introduces a separate global constructor in each TU that includes it. > > We can do this only if the init_priority attribute is supported because > we need to force that the stream initialization runs first before any > user-defined global initializer in programs that that use a static > libstdc++.a. > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look right? > Unfortunately I don't have access to a system that truly doesn't support > init priorities, so I instead tested that situation by artificially > disabling the init_priority attribute on x86_64. > > PR libstdc++/44952 > PR libstdc++/98108 > > libstdc++-v3/ChangeLog: > > * include/bits/c++config (_GLIBCXX_HAS_ATTRIBUTE): Define. > (_GLIBCXX_HAVE_ATTRIBUTE_INIT_PRIORITY): Define. > * include/std/iostream (__ioinit): Define only if init_priority > attribute isn't usable. > * src/c++98/ios_init.cc (__ioinit): Define here instead if > the init_priority is usable. > * src/c++98/ios_base_init.h: New file. This (r13-3707-g4e4e3ffd10f53e) broke statically linked programs using iostreams (affected embedded targets + "native" with -static). For me it manifests as adding some 100+ fails to my cris-elf autotester also repeatable using a native Debian 11 x86_64 build running the test-suite with -static like "make check-gcc-c++ 'RUNTESTFLAGS=--target_board=unix/-static old-deja.exp=15071.C'". I opened PR107701 for it. brgds, H-P
