[Bug libstdc++/44952] #include <iostream> implies global constructor.

[Bug libstdc++/44952] #include <iostream> implies global constructor.

[ccoutant at gcc dot gnu.org]

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

Cary Coutant <ccoutant at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ccoutant at gcc dot gnu.org

--- Comment #15 from Cary Coutant <ccoutant at gcc dot gnu.org> 2010-12-14 18:50:11 UTC ---
(In reply to comment #13)
> So reopening for this enhancement...
> 
> Another alternative would be some .init.first array or something similar which
> would contain pointers to functions to be run as early constructors and linker
> would remove duplicates in it and put it at the beginning of .init_array
> section.

For ELF targets, this is what DT_PREINIT_ARRAY is for.

http://www.sco.com/developers/gabi/latest/ch5.dynamic.html#init_fini

-cary

[Bug libstdc++/44952] #include <iostream> implies global constructor.

[redi at gcc dot gnu.org]

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

--- Comment #16 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #5)
> 27.4 [iostream.objects] paragraph 2
> The results of including <iostream> in a translation unit shall be as if
> <iostream> defined an instance of ios_base::Init with static storage
> duration. Similarly, the entire program shall behave as if there were at
> least one instance of ios_base::Init with static storage duration.

N.B. https://wg21.link/lwg2765 removed that last sentence, so we are no longer
required to run the stream initialization in all programs. Only in programs
which include <iostream> in at least one TU.

[Bug libstdc++/44952] #include <iostream> implies global constructor.

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-11-03
                 CC|                            |jason at gcc dot gnu.org,
                   |                            |ppalka at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW

--- Comment #17 from Jason Merrill <jason at gcc dot gnu.org> ---
The __ioinit hack won't work with the move to modules, and it doesn't seem
necessary either:

For programs that use libstdc++ as a shared library, it should be fine for the
initialization to run in the library, before the main program is loaded.

For programs that use a static libstdc++, attribute init_priority should be
sufficient to make sure it runs first.

[Bug libstdc++/44952] #include <iostream> implies global constructor.

[ppalka at gcc dot gnu.org]

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

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |ppalka at gcc dot gnu.org

[Bug libstdc++/44952] #include <iostream> implies global constructor.

[cvs-commit at gcc dot gnu.org]

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

--- Comment #18 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++/44952] #include <iostream> implies global constructor.

[hubicka at gcc dot gnu dot org]

------- Comment #14 from hubicka at gcc dot gnu dot org  2010-08-19 09:39 -------
Well, it might be easy to modify libstdc++ implementation so the static
constructor compiles into single function call.  Then we can teach GCC to
optimize constructor containing only a call into entry in ctors table.
Then we will get a lot of duplicate calls, but all at one place and we won't
have the locality problem at startup.


-- 


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

[Bug libstdc++/44952] #include <iostream> implies global constructor.

[jakub at gcc dot gnu dot org]

------- Comment #13 from jakub at gcc dot gnu dot org  2010-07-22 11:41 -------
So reopening for this enhancement...

Another alternative would be some .init.first array or something similar which
would contain pointers to functions to be run as early constructors and linker
would remove duplicates in it and put it at the beginning of .init_array
section.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


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

[Bug libstdc++/44952] #include <iostream> implies global constructor.

[paolo dot carlini at oracle dot com]

------- Comment #12 from paolo dot carlini at oracle dot com  2010-07-22 11:25 -------
The same idea vaguely occurred to me...


-- 


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

[Bug libstdc++/44952] #include <iostream> implies global constructor.

[jakub at gcc dot gnu dot org]

------- Comment #11 from jakub at gcc dot gnu dot org  2010-07-22 11:03 -------
Perhaps with LTO we could special case this (perhaps using some special
attribute) and only construct/destruct the first of these
  static ios_base::Init __ioinit;
vars and optimize all the others away together with their
construction/destruction, assuming they aren't otherwise referenced.


-- 


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

[Bug libstdc++/44952] #include <iostream> implies global constructor.

[pinskia at gcc dot gnu dot org]

------- Comment #10 from pinskia at gcc dot gnu dot org  2010-07-22 00:01 -------
The C++ standard actually requires this as noted in comment #5.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


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

[Bug libstdc++/44952] #include <iostream> implies global constructor.

[paolo dot carlini at oracle dot com]

------- Comment #9 from paolo dot carlini at oracle dot com  2010-07-15 18:26 -------
Let's say we remove that horrible .h from the Summary, since, to be fair,
didn't exist in g.C in the first place ;)

That said, I agree with Jon, by and large, with the following minor additional
observations: 1- I'm pretty sure the library is correct, but we should double
check whether other established and new implementations of the C++ runtime are
trying to do something special, performance-wise - low priority I'm afraid; 2-
As library maintainers we certainly welcome any improvement to the optimizers
improving the code GCC generates for these constructors, because certainly many
user applications could benefit, not just because the library would; -3 While
we are at it, I think we should make sure not regressing on libstdc++/39796, or
even making progress at once. Ideas? (I didn't really manage to study it in any
detail)


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
            Summary|#include <iostream.h> imply |#include <iostream> implies
                   |global constructor.         |global constructor.


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