[Bug libstdc++/56557] New: Link error about `std::fstream' or `std::stringstream' with `-flto' and `-rdynamic' options

[Bug libstdc++/56557] New: Link error about `std::fstream' or `std::stringstream' with `-flto' and `-rdynamic' options

[ai.azuma at gmail dot com]

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

             Bug #: 56557
           Summary: Link error about `std::fstream' or `std::stringstream'
                    with `-flto' and `-rdynamic' options
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: ai.azuma@gmail.com


Created attachment 29605
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29605
Output of -v option

The following code results in a link error when compiling on GCC 4.8.0 20130303
with `-flto' and `-rdynamic' options;

//================
#include <fstream>

int main()
{
  std::fstream x;
}
//================

The link error is;

cryolite@ubuntu:~/work/gcc-bugs/20130306$ ~/local/gcc-4.8-20130303/bin/g++
-flto -rdynamic main.cpp
/usr/bin/ld: a.out: hidden symbol
`_ZTCSt13basic_fstreamIcSt11char_traitsIcEE0_Sd' isn't defined
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status

Other specializations of `std::basic_fstream' or `std::basic_stringstream' have
the similar issue.

As far as I can confirm, this problem is not reproduced with 4.6.4 20130301 or
4.7.3 20130302. Thus, this seems a regression.

[Bug libstdc++/56557] Link error about `std::fstream' or `std::stringstream' with `-flto' and `-rdynamic' options

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

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

--- Comment #1 from Paolo Carlini <paolo.carlini at oracle dot com> 2013-03-07 01:29:17 UTC ---
Seems related to PR54314.

[Bug libstdc++/56557] [4.8 Regression] Link error about `std::fstream' or `std::stringstream' with `-flto' and `-rdynamic' options

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-03-07
   Target Milestone|---                         |4.8.0
            Summary|Link error about            |[4.8 Regression] Link error
                   |`std::fstream' or           |about `std::fstream' or
                   |`std::stringstream' with    |`std::stringstream' with
                   |`-flto' and `-rdynamic'     |`-flto' and `-rdynamic'
                   |options                     |options
     Ever Confirmed|0                           |1

--- Comment #2 from Paolo Carlini <paolo.carlini at oracle dot com> 2013-03-07 09:07:46 UTC ---
Confirmed.

[Bug libstdc++/56557] [4.8 Regression] Link error about `std::fstream' or `std::stringstream' with `-flto' and `-rdynamic' options

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

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

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> 2013-03-07 10:11:13 UTC ---
Honza?

[Bug libstdc++/56557] [4.8 Regression] Link error about `std::fstream' or `std::stringstream' with `-flto' and `-rdynamic' options

[hubicka at gcc dot gnu.org]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|unassigned at gcc dot       |hubicka at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #4 from Jan Hubicka <hubicka at gcc dot gnu.org> 2013-03-07 19:59:57 UTC ---
mine..

[Bug libstdc++/56557] [4.8 Regression] Link error about `std::fstream' or `std::stringstream' with `-flto' and `-rdynamic' options

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

[Bug libstdc++/56557] [4.8 Regression] Link error about `std::fstream' or `std::stringstream' with `-flto' and `-rdynamic' options

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-11 09:27:10 UTC ---
If I change:
--- cp/class.c    (revision 196593)
+++ cp/class.c    (working copy)
@@ -8364,7 +8364,7 @@ build_ctor_vtbl_group (tree binfo, tree
      targets that don't support hidden visibility, this tells
      can_refer_decl_in_current_unit_p not to assume that it's safe to
      access from a different compilation unit (bz 54314).  */
-  DECL_VISIBILITY (vtbl) = VISIBILITY_HIDDEN;
+  DECL_VISIBILITY (vtbl) = VISIBILITY_DEFAULT;
   DECL_VISIBILITY_SPECIFIED (vtbl) = true;

   v = NULL;
(remember, gimple-fold.c still uses the nonsensical DECL_VISIBILITY_SPECIFIED
test rather than actually looking what the visibility is) and link against
older
libstdc++ (one before r195550 fix), the testcase links, but contains lots of
bogus
SHN_UNDEF symbols (using ld.bfd 2.22.52.0.1), including the _ZTC* symbols that
will fail to link against latest 4.8.0 libstdc++ (or 4.7.x libstdc++), because
they aren't exported.
I'd say that the only needed SHN_UNDEF symbols in the dynamic table are the
symbols that are actually used in the relocations.
If I link without -flto, the relocs are:
0000000000600dc0  0000000400000006 R_X86_64_GLOB_DAT      0000000000000000
__gmon_start__ + 0
0000000000600de0  0000000700000007 R_X86_64_JUMP_SLOT     0000000000000000
__libc_start_main + 0
0000000000600de8  0000000c00000007 R_X86_64_JUMP_SLOT     0000000000000000
_ZNSt13basic_fstreamIcSt11char_traitsIcEED1Ev + 0
0000000000600df0  0000000e00000007 R_X86_64_JUMP_SLOT     0000000000000000
_ZNSt13basic_fstreamIcSt11char_traitsIcEEC1Ev + 0
0000000000600df8  0000001200000007 R_X86_64_JUMP_SLOT     0000000000400820
__gxx_personality_v0 + 0
0000000000600e00  0000001300000007 R_X86_64_JUMP_SLOT     0000000000000000
_Unwind_Resume + 0
and SHN_UNDEF symbols in the binary beyond those are just:
     1: 0000000000600e08     0 NOTYPE  WEAK   DEFAULT   24 data_start
     5: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _Jv_RegisterClasses
     8: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND
_ITM_deregisterTMCloneTable
    10: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND
_ITM_registerTMCloneTable
But with -flto there are 96 SHN_UNDEF symbols in the binary.  That looks like
liblto_plugin.so bug to me, the symbols are there just in the symbol tables,
but aren't actually used for anything.

[Bug libstdc++/56557] [4.8 Regression] Link error about `std::fstream' or `std::stringstream' with `-flto' and `-rdynamic' options

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-11 09:36:24 UTC ---
BTW, even stock cc1plus (i.e. no the above class.c change) against latest 4.8.0
libstdc++ shows the myriads of useless SHN_UNDEF symbols with -flto alone (and
not -rdynamic), just the _ZTC* symbols aren't included in that case.

[Bug libstdc++/56557] [4.8 Regression] Link error about `std::fstream' or `std::stringstream' with `-flto' and `-rdynamic' options

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-11 10:05:39 UTC ---
Note that this behavior (tons of undesirable SHN_UNDEF symbols in binaries
linked with -flto) seems to be specific to ld.bfd, with gold the #c0 testcase
links just fine, and the SHN_UNDEF symbols are the expected ones.  I've also
tried latest CVS binutils (both gold and ld.bfd) and the behavior is the same,
gold works here, ld.bfd broken.
So perhaps this is a binutils bug instead?

[Bug libstdc++/56557] [4.8 Regression] Link error about `std::fstream' or `std::stringstream' with `-flto' and `-rdynamic' options

[hubicka at ucw dot cz]

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

--- Comment #8 from Jan Hubicka <hubicka at ucw dot cz> 2013-03-11 13:58:07 UTC ---
Yes, I agree it is GNU LD bug.
There is also GCC problem: this particular symbol should not appear in the LTO
symtab. It appears because we see the refernece, but the reference itself comes
from external var initializer and ought to be ignored.  I will fix this
problem.

Honza

[Bug libstdc++/56557] [4.8 Regression] Link error about `std::fstream' or `std::stringstream' with `-flto' and `-rdynamic' options

[hubicka at gcc dot gnu.org]

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

--- Comment #9 from Jan Hubicka <hubicka at gcc dot gnu.org> 2013-03-11 18:10:57 UTC ---
I am testing the following that should prevent references from external vtables
to land in LTO symbol table.

Index: lto-streamer-out.c
===================================================================
--- lto-streamer-out.c  (revision 196596)
+++ lto-streamer-out.c  (working copy)
@@ -1265,17 +1265,36 @@ bool
 output_symbol_p (symtab_node node)
 {
   struct cgraph_node *cnode;
-  struct ipa_ref *ref;
-
   if (!symtab_real_symbol_p (node))
     return false;
   /* We keep external functions in symtab for sake of inlining
      and devirtualization.  We do not want to see them in symbol table as
-     references.  */
+     references unless they are really used.  */
   cnode = dyn_cast <cgraph_node> (node);
-  if (cnode && DECL_EXTERNAL (cnode->symbol.decl))
-    return (cnode->callers
-           || ipa_ref_list_referring_iterate (&cnode->symbol.ref_list, 0,
ref));
+  if (cnode && DECL_EXTERNAL (cnode->symbol.decl)
+      && cnode->callers)
+    return true;
+
+ /* Ignore all referrences from external vars initializers - they are not
really
+    part of the compilation unit until they are used by folding.  Some
symbols,
+    like referneces to external construction vtables can not be referred to at
all.
+    We decide this at can_refer_decl_in_current_unit_p */
+ if (DECL_EXTERNAL (node->symbol.decl))
+    {
+      int i;
+      struct ipa_ref *ref;
+      for (i = 0; ipa_ref_list_referring_iterate (&node->symbol.ref_list,
+                                                 i, ref); i++)
+       {
+         if (ref->use == IPA_REF_ALIAS)
+           continue;
+          if (is_a <cgraph_node> (ref->referring))
+           return true;
+         if (!DECL_EXTERNAL (ref->referring->symbol.decl))
+           return true;
+       }
+      return false;
+    }
   return true;
 }

[Bug libstdc++/56557] [4.8 Regression] Link error about `std::fstream' or `std::stringstream' with `-flto' and `-rdynamic' options

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-11 18:21:19 UTC ---
(In reply to comment #9)
Sorry for nitpicking ;) :

> + /* Ignore all referrences from external vars initializers - they are not
> really

references

> +    part of the compilation unit until they are used by folding.  Some
> symbols,
> +    like referneces to external construction vtables can not be referred to at

references

> all.
> +    We decide this at can_refer_decl_in_current_unit_p */

Dot + space missing.

[Bug libstdc++/56557] [4.8 Regression] Link error about `std::fstream' or `std::stringstream' with `-flto' and `-rdynamic' options

[hubicka at gcc dot gnu.org]

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

--- Comment #11 from Jan Hubicka <hubicka at gcc dot gnu.org> 2013-03-12 00:58:48 UTC ---
BTW, one thing i do not understand is why the construction vtables are not
static when they can not be used across .o boundary?

[Bug libstdc++/56557] [4.8 Regression] Link error about `std::fstream' or `std::stringstream' with `-flto' and `-rdynamic' options

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-12 08:19:28 UTC ---
Wouldn't that mean that if you emit _ZTT* for the same class in multiple TUs in
one shared library and the _ZTT* references these static _ZTC* symbols, that
the construction vtables then couldn't be comdat and thus you'd have tons of
copies of them, wasting .data space as well as dynamic relocations?

[Bug libstdc++/56557] [4.8 Regression] Link error about `std::fstream' or `std::stringstream' with `-flto' and `-rdynamic' options

[hubicka at gcc dot gnu.org]

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

--- Comment #13 from Jan Hubicka <hubicka at gcc dot gnu.org> 2013-03-12 12:38:54 UTC ---
Author: hubicka
Date: Tue Mar 12 12:38:47 2013
New Revision: 196613

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196613
Log:
    PR lto/56557
    * lto-streamer-out.c (output_symbol_p): Skip references from
    constructors of external variables.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/lto-streamer-out.c

[Bug lto/56557] [4.8 Regression] Link error about `std::fstream' or `std::stringstream' with `-flto' and `-rdynamic' options

[hubicka at gcc dot gnu.org]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|libstdc++                   |lto

--- Comment #14 from Jan Hubicka <hubicka at gcc dot gnu.org> 2013-03-12 12:53:17 UTC ---
This is the LTO symbol table I get out of the testcase now:
         U _ZNSdC2Ev
         U _ZNSdD1Ev
         U _ZNSdD2Ev
         U _ZNSiC2Ev
         U _ZNSiD1Ev
         U _ZNSiD2Ev
         U _ZNSoC2Ev
         U _ZNSoD1Ev
         U _ZNSoD2Ev
         U _ZNSt12__basic_fileIcED1Ev
         U _ZNSt13basic_filebufIcSt11char_traitsIcEE5closeEv
         U _ZNSt13basic_filebufIcSt11char_traitsIcEEC1Ev
         U _ZNSt13basic_filebufIcSt11char_traitsIcEED1Ev
         U _ZNSt13basic_fstreamIcSt11char_traitsIcEEC1Ev
         U _ZNSt13basic_fstreamIcSt11char_traitsIcEED1Ev
         U _ZNSt15basic_streambufIcSt11char_traitsIcEED1Ev
         U _ZNSt15basic_streambufIcSt11char_traitsIcEED2Ev
         U _ZNSt6localeD1Ev
         U _ZNSt8ios_baseC2Ev
         U _ZNSt8ios_baseD2Ev
         U _ZNSt9basic_iosIcSt11char_traitsIcEE4initEPSt15basic_streambufIcS1_E
         U _ZNSt9basic_iosIcSt11char_traitsIcEEC2Ev
         U _ZNSt9basic_iosIcSt11char_traitsIcEED1Ev
         U _ZNSt9basic_iosIcSt11char_traitsIcEED2Ev
         U _ZTTSd
         U _ZTTSt13basic_fstreamIcSt11char_traitsIcEE
         U _ZTVSd
         U _ZTVSi
         U _ZTVSo
         U _ZTVSt13basic_filebufIcSt11char_traitsIcEE
         U _ZTVSt13basic_fstreamIcSt11char_traitsIcEE
         U _ZTVSt15basic_streambufIcSt11char_traitsIcEE
         U _ZTVSt9basic_iosIcSt11char_traitsIcEE
         U _ZdlPv
         U __gxx_personality_v0
00000000 T main

So still quite a bit more than w/o LTO:

                 U _ZNSt13basic_fstreamIcSt11char_traitsIcEEC1Ev
                 U _ZNSt13basic_fstreamIcSt11char_traitsIcEED1Ev
0000000000000001 C __gnu_lto_v1
0000000000000000 T main

but the construction vtable is no longer on the list. Those extra symbols are
from virtual functions we hold for possible devirtualization.
We ought to make sure that linkers optimize out the dynamic table entries after
we are done with optimizing them out

[Bug lto/56557] [4.8 Regression] Link error about `std::fstream' or `std::stringstream' with `-flto' and `-rdynamic' options

[hubicka at gcc dot gnu.org]

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

--- Comment #15 from Jan Hubicka <hubicka at gcc dot gnu.org> 2013-03-12 13:00:11 UTC ---

Filled in binutils PR http://sourceware.org/bugzilla/show_bug.cgi?id=15270

[Bug libstdc++/56557] [4.8 Regression] Link error about `std::fstream' or `std::stringstream' with `-flto' and `-rdynamic' options

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
          Component|lto                         |libstdc++
         Resolution|                            |FIXED

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-12 13:29:35 UTC ---
I've verified Honza's patch fixed the problem.