[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