[Bug libstdc++/44952] New: #include <iostream.h> imply global constructor.

[Bug libstdc++/44952] New: #include <iostream.h> imply global constructor.

[hubicka at gcc dot gnu dot org]

Noticed while reading
http://comments.gmane.org/gmane.comp.web.chromium.devel/16789

evans:/abuild/jh/trunk-install/bin/:[0]# more g.C
#include <iostream>
evans:/abuild/jh/trunk-install/bin/:[0]# ./g++  -O2 g.C -S
evans:/abuild/jh/trunk-install/bin/:[0]# more g.s
        .file   "g.C"
        .text
        .p2align 4,,15
        .type   _GLOBAL__I_g.C, @function
_GLOBAL__I_g.C:
.LFB969:
        .cfi_startproc
        subq    $8, %rsp
        .cfi_def_cfa_offset 16
        movl    $_ZStL8__ioinit, %edi
        call    _ZNSt8ios_base4InitC1Ev
        movl    $__dso_handle, %edx
        movl    $_ZStL8__ioinit, %esi
        movl    $_ZNSt8ios_base4InitD1Ev, %edi
        addq    $8, %rsp
        .cfi_def_cfa_offset 8
        jmp     __cxa_atexit
        .cfi_endproc
.LFE969:


-- 
           Summary: #include <iostream.h> imply global constructor.
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: hubicka at gcc dot gnu dot org


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

Re: [Bug libstdc++/44952] New: #include <iostream.h> imply global constructor.

[Andrew Pinski]

This is expected and iirc required by the c++ standard too.

On Jul 15, 2010, at 8:51 AM, "hubicka at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org 
 > wrote:

> Noticed while reading
> http://comments.gmane.org/gmane.comp.web.chromium.devel/16789
>
> evans:/abuild/jh/trunk-install/bin/:[0]# more g.C
> #include <iostream>
> evans:/abuild/jh/trunk-install/bin/:[0]# ./g++  -O2 g.C -S
> evans:/abuild/jh/trunk-install/bin/:[0]# more g.s
>        .file   "g.C"
>        .text
>        .p2align 4,,15
>        .type   _GLOBAL__I_g.C, @function
> _GLOBAL__I_g.C:
> .LFB969:
>        .cfi_startproc
>        subq    $8, %rsp
>        .cfi_def_cfa_offset 16
>        movl    $_ZStL8__ioinit, %edi
>        call    _ZNSt8ios_base4InitC1Ev
>        movl    $__dso_handle, %edx
>        movl    $_ZStL8__ioinit, %esi
>        movl    $_ZNSt8ios_base4InitD1Ev, %edi
>        addq    $8, %rsp
>        .cfi_def_cfa_offset 8
>        jmp     __cxa_atexit
>        .cfi_endproc
> .LFE969:
>
>
> -- 
>           Summary: #include <iostream.h> imply global constructor.
>           Product: gcc
>           Version: 4.6.0
>            Status: UNCONFIRMED
>          Severity: normal
>          Priority: P3
>         Component: libstdc++
>        AssignedTo: unassigned at gcc dot gnu dot org
>        ReportedBy: hubicka at gcc dot gnu dot org
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44952
>

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

[pinskia at gmail dot com]

------- Comment #1 from pinskia at gmail dot com  2010-07-15 16:02 -------
Subject: Re:   New: #include <iostream.h> imply global constructor.

This is expected and iirc required by the c++ standard too.

On Jul 15, 2010, at 8:51 AM, "hubicka at gcc dot gnu dot org"
<gcc-bugzilla@gcc.gnu.org 
 > wrote:

> Noticed while reading
> http://comments.gmane.org/gmane.comp.web.chromium.devel/16789
>
> evans:/abuild/jh/trunk-install/bin/:[0]# more g.C
> #include <iostream>
> evans:/abuild/jh/trunk-install/bin/:[0]# ./g++  -O2 g.C -S
> evans:/abuild/jh/trunk-install/bin/:[0]# more g.s
>        .file   "g.C"
>        .text
>        .p2align 4,,15
>        .type   _GLOBAL__I_g.C, @function
> _GLOBAL__I_g.C:
> .LFB969:
>        .cfi_startproc
>        subq    $8, %rsp
>        .cfi_def_cfa_offset 16
>        movl    $_ZStL8__ioinit, %edi
>        call    _ZNSt8ios_base4InitC1Ev
>        movl    $__dso_handle, %edx
>        movl    $_ZStL8__ioinit, %esi
>        movl    $_ZNSt8ios_base4InitD1Ev, %edi
>        addq    $8, %rsp
>        .cfi_def_cfa_offset 8
>        jmp     __cxa_atexit
>        .cfi_endproc
> .LFE969:
>
>
> -- 
>           Summary: #include <iostream.h> imply global constructor.
>           Product: gcc
>           Version: 4.6.0
>            Status: UNCONFIRMED
>          Severity: normal
>          Priority: P3
>         Component: libstdc++
>        AssignedTo: unassigned at gcc dot gnu dot org
>        ReportedBy: hubicka at gcc dot gnu dot org
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44952
>


-- 


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

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

[rguenth at gcc dot gnu dot org]

------- Comment #2 from rguenth at gcc dot gnu dot org  2010-07-15 16:03 -------
Why's this not in libstdc++.so .init?


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|rguenther at suse dot de    |rguenth at gcc dot gnu dot
                   |                            |org, paolo dot carlini at
                   |                            |oracle dot com


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

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

[hubicka at gcc dot gnu dot org]

------- Comment #3 from hubicka at gcc dot gnu dot org  2010-07-15 16:12 -------
... and are we required to emit the constructor even if we know var is not
used?


-- 


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

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

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2010-07-15 16:30 -------
(In reply to comment #2)
> Why's this not in libstdc++.so .init?

because this will not work if libstdc++ is a static library.
Take:

#include <iostream>

namespace {
struct g
{
  g(){ std::cout << "t"; }
};
g one;
}

--- CUT ---
The C++ standard says order of initializers between TUs is unspecified (though
the order inside TUs is specified as being the first one will run first).
So with a static version, the above will be included first and that will cause
std::cout to be used without being initialized.

>... and are we required to emit the constructor even if we know var is not
used?
It is hard to do that in Standard C++ really or imposable.


-- 


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

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

[redi at gcc dot gnu dot org]

------- Comment #5 from redi at gcc dot gnu dot org  2010-07-15 16:38 -------
This is why you should only include <iostream> if you want actually want
std::cin, std::cout or std::cerr (or the wide character equivalents.)
Otherwise you should only include one or more of <iosfwd>, <istream> and
<ostream>, as needed.


(In reply to comment #3)
> ... and are we required to emit the constructor even if we know var is not
> used?

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.


-- 


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

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

[redi at gcc dot gnu dot org]

------- Comment #6 from redi at gcc dot gnu dot org  2010-07-15 16:45 -------
and please ... it's 2010, <iostream> not <iostream.h>  ;-)


-- 


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

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

[hubicka at gcc dot gnu dot org]

------- Comment #7 from hubicka at gcc dot gnu dot org  2010-07-15 16:53 -------
Hehe, I am really not C++ guy even in 2010, but I have impression that people
are including iostream without really thinking about consequences here.

Well, so what we can do about the startup times then?  I will teach ipa-profile
to propagate info if function is only called from constructor and will put them
into separate section. This will save the random access at file startup. But we
ought to be able to do better.


-- 


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

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

[redi at gcc dot gnu dot org]

------- Comment #8 from redi at gcc dot gnu dot org  2010-07-15 17:49 -------
(In reply to comment #7)
> Hehe, I am really not C++ guy even in 2010, but I have impression that people
> are including iostream without really thinking about consequences here.

Yes, and in many cases that's the simplest thing to do, but it has a cost.

> Well, so what we can do about the startup times then?

I would do nothing.  If people care about startup times they should not include
facilities they don't use.


-- 


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

[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.

[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.

[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 #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.

[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.

[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.

[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.

[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.

[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.

[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