[Bug libstdc++/39796] cin/cout/cerr constructors should run at high priority when possible

[Bug libstdc++/39796] cin/cout/cerr constructors should run at high priority when possible

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39796

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-01-03
     Ever Confirmed|0                           |1

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-01-03 16:39:39 UTC ---
http://stackoverflow.com/questions/8708539/order-of-initialization was brought
to my attention, which crashes without messing with init-priority

struct Foo
{

   Foo();
}foo;

#include <iostream>

Foo::Foo()
{
   std::cout << "Hello World";
}

int main() {}

So I'm confirming this as a valid enhancement.

PR 44952 might lead to a better way to ensure the initialization is done once
as early as possible.

[Bug libstdc++/39796] cin/cout/cerr constructors should run at high priority when possible

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39796

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:4e4e3ffd10f53ef71696bc728ab40258751a2df4

commit r13-3707-g4e4e3ffd10f53ef71696bc728ab40258751a2df4
Author: Patrick Palka <ppalka@redhat.com>
Date:   Sun Nov 6 11:16:00 2022 -0500

    libstdc++: Move stream initialization into compiled library [PR44952]

    This patch moves the static object for constructing the standard streams
    out from <iostream> and into the compiled library on systems that support
    init priorities.  This'll mean <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 a way to ensure the stream initialization runs first before any
    user global initializer, particularly when linking with a static
    libstdc++.a.

            PR libstdc++/44952
            PR libstdc++/39796
            PR libstdc++/98108

    libstdc++-v3/ChangeLog:

            * include/std/iostream (__ioinit): No longer define here if
            the init_priority attribute is usable.
            * src/c++98/ios_init.cc (__ioinit): Define here instead if
            init_priority is usable, via ...
            * src/c++98/ios_base_init.h: ... this new file.

[Bug libstdc++/39796] cin/cout/cerr constructors should run at high priority when possible

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39796

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vhaisman at gmail dot com

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 62200 has been marked as a duplicate of this bug. ***

[Bug libstdc++/39796] cin/cout/cerr constructors should run at high priority when possible

[bkoz at gcc dot gnu dot org]

------- Comment #3 from bkoz at gcc dot gnu dot org  2009-04-21 02:46 -------

I consider this undefined behaviour, so enhancement is the correct severity. 

People wanting to mess with non-standard init order should probably be taking
steps to insure that libstdc++ is initialized first anyway. Not doing so is
arguably a bug..... especially as it's not hard to do:

ie:
#include <iostream>

void f1() __attribute__ ((constructor (101)));
void f1() 
{ 
  std::ios_base::Init i;
  std::cout << "f1" << std::endl; 
}

int main() { }


But anyway........

libstdc++ is currently not using the first 100 slots reserved for the GNU
implementation as per:

http://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Attributes.html#C_002b_002b-Attributes

No efforts or audit have ever been made as to enshrine a specified init order
for libstd++. Locales, mutexes, and __mt_allocator would all have to be scoped
and modified as code is/was changed. I consider this doable, but probably as
much work in the long run as the efforts for symbol versioning. There may be an
advantage to doing this for size reasons, as then <iostream>'s  

  // For construction of filebuffers for cout, cin, cerr, clog et. al.
  static ios_base::Init __ioinit;

could be killed. 

If there was some kind of real advantage, I would be more into this whole idea.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39796

[Bug libstdc++/39796] cin/cout/cerr constructors should run at high priority when possible

[ian at airs dot com]

------- Comment #2 from ian at airs dot com  2009-04-18 05:40 -------
You are much more familiar with the library than I am.  I don't know if this
issue arises anywhere else.  cin/cout/cerr is sort of an obvious case.  It
didn't really occur to me that there might be similar issues elsewhere.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39796

[Bug libstdc++/39796] cin/cout/cerr constructors should run at high priority when possible

[paolo dot carlini at oracle dot com]

------- Comment #1 from paolo dot carlini at oracle dot com  2009-04-17 15:06 -------
I see. I would be tempted to ask you to propose a fix at once, seems pretty
simple, basically a bit of configury and very few lines of actual code.
However, I wonder if we have something similar elsewhere, I seem to remember
something for the memory allocators, for example, but possibly by now we have
static locals everywhere to avoid completely running into such priority issues.
Another area which probably should be audited is that of locale. What do you
think?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39796