[Bug lto/53831] New: Inline virtuals missing in LTO symtab

[Bug lto/53831] New: Inline virtuals missing in LTO symtab

[tetra2005 at gmail dot com]

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

             Bug #: 53831
           Summary: Inline virtuals missing in LTO symtab
    Classification: Unclassified
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: tetra2005@gmail.com


The attached sample program works fine when compiled without LTO:
  $ make clean all
but fails if I specify -flto:
  $ make USE_LTO=1 clean all
  libdummy.a: could not read symbols: Bad value
  collect2: error: ld returned 1 exit status
  make: *** [test.exe] Error 1
The error is caused by a mismatch in libdummy.a's ordinary symtab:
  $ arm-linux-androideabi-nm libdummy.a
  impl.o:
  ...
  00000000 W _ZN1C1fEv
  00000000 T _ZN1C1gEv
  00000000 D _ZTV1C
  ...
and it's LTO symtab:
  $ arm-linux-androideabi-objdump -hts impl.o
  ...
  Contents of section .gnu.lto_.symtab.1306600d0972f21a:
  0000 5f5a4e31 43316745 76000000 00000000  _ZN1C1gEv.......
  0010 00000000 00a10000 005f5a54 56314300  ........._ZTV1C.
  0020 00000000 00000000 000000b5 000000    ...............
  Contents of section .gnu.lto_.opts:
  ...
Note that _ZN1C1fEv (which is mangled name for inline virtual C::f()) is
missing in LTO symtab. This later causes linker to go mad in
elf_link_add_archive_symbols() when trying to link in impl.o more than once
(element->archive_pass > 0).

It seems that C::f() is filtered out in produce_symtab in lto-streamer-out.c:
  if (DECL_COMDAT (node->symbol.decl)
      && cgraph_comdat_can_be_unshared_p (node))
    continue;
because C::f() is (erroneously) considered to be COMDAT.

I've tested the code with TOT binutils and gcc. I had to include multiple file
program because otherwise bug would fail to manifest.

[Bug lto/53831] Inline virtuals missing in LTO symtab

[tetra2005 at gmail dot com]

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

--- Comment #1 from Yuri Gribov <tetra2005 at gmail dot com> 2012-07-02 19:52:16 UTC ---
Created attachment 27731
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27731
Small project which demonstrates the bug

[Bug lto/53831] Inline virtuals missing in LTO symtab

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|arm-linux-androideabi       |arm-linux-androideabi,
                   |                            |x86_64-linux-gnu
             Status|UNCONFIRMED                 |NEW
            Version|unknown                     |4.7.1
           Keywords|                            |lto
   Last reconfirmed|                            |2012-07-03
                 CC|                            |hubicka at gcc dot gnu.org
     Ever Confirmed|0                           |1
      Known to fail|                            |4.7.2

--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-07-03 10:32:07 UTC ---
Confirmed on x86_64-linux.  Works when not using the linker plugin.  Might be
a linker bug as well.

[Bug lto/53831] Inline virtuals missing in LTO symtab

[tetra2005 at gmail dot com]

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

--- Comment #3 from Yuri Gribov <tetra2005 at gmail dot com> 2012-07-03 10:45:09 UTC ---
I don't think linker can do much after gcc removes the symbol from symtab.

BTW it would help a lot if linker verified that LTO and ELF symtabs actually
match. Currently mismatches causes all sorts or weird errors which are somewhat
hard to understand without getting your hands dirty.

[Bug lto/53831] Inline virtuals missing in LTO symtab

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-07-03 10:52:42 UTC ---
(In reply to comment #3)
> I don't think linker can do much after gcc removes the symbol from symtab.

I belive the contract between the linker and GCC is that GCC can introduce
new references to externally visible symbols and remove references and
defs of symbols that are only used from inside the executable (the linker
tells GCC that fact).  The question is who is at fault here - GCC doing
something it may not do or the linker not handling a situation it should
handle.

> BTW it would help a lot if linker verified that LTO and ELF symtabs actually
> match. Currently mismatches causes all sorts or weird errors which are somewhat
> hard to understand without getting your hands dirty.

True ... debugging LTO issues can be quite painful.

[Bug lto/53831] Inline virtuals missing in LTO symtab

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-07-03 10:59:57 UTC ---
(In reply to comment #4)
> (In reply to comment #3)
> > I don't think linker can do much after gcc removes the symbol from symtab.
> 
> I belive the contract between the linker and GCC is that GCC can introduce
> new references to externally visible symbols and remove references and
> defs of symbols that are only used from inside the executable (the linker
> tells GCC that fact).  The question is who is at fault here - GCC doing
> something it may not do or the linker not handling a situation it should
> handle.

That is, the linker tells us (-v -save-temps, grab the -fresolution= filename
from the lto1 -fwpa invocation):

repro> cat -- -lm.res
2
main.o 4
208 7b62d4c061a2d132 PREVAILING_DEF main
193 7b62d4c061a2d132 RESOLVED_IR _ZN1C1gEv
204 7b62d4c061a2d132 UNDEF _ZN1C1fEv
180 7b62d4c061a2d132 RESOLVED_IR _ZTV1C
libdummy.a@0xbc 2
164 84325c9d3f031d4d PREVAILING_DEF_IRONLY _ZN1C1gEv
184 84325c9d3f031d4d PREVAILING_DEF_IRONLY _ZTV1C

so _ZN1C1gEv is not referenced from outside the link target.  So GCC
removes it and (hopefully!) all references.  And I cannot see any
references to _ZN1C1gEv in the final assembler file, but only the
version that was brought local (_ZN1C1gEv.2356 in my case).

So it does look like a linker issue after all.

[Bug lto/53831] Inline virtuals missing in LTO symtab

[tetra2005 at gmail dot com]

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

--- Comment #6 from Yuri Gribov <tetra2005 at gmail dot com> 2012-07-03 12:16:21 UTC ---
First of all note that we are talking about _ZN1C1fEv (not _ZN1C1gEv!) here.

I agree that linker doesn't mention it in the resolution file but I think this
happens because it's missing in impl.o's lto_.symtab section:
  $ cat impl.s | grep -C 5 lto_.symtab
  ...
  .section        .gnu.lto_.symtab.919ce2eae4796a64,"",%progbits
  .ascii  "_ZN1C1gEv\000\000\000\000\000\000\000\000\000\000\000"
  .ascii  "\000\241\000\000\000_ZTV1C\000\000\000\000\000\000\000"
  .ascii  "\000\000\000\000\000\265\000\000\000"
  .text
  .section        .gnu.lto_.opts,"",%progbits
Thus it isn't reported to linker by lto-plugin via add_symbols() (see
ld/plugin.c). So linker doesn't have a chance to know that _ZN1C1fEv is
actually defined in impl.o and generates invalid resolution. I still think that
ld is innocent here.

Did I get it all wrong?

[Bug lto/53831] Inline virtuals missing in LTO symtab

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rafael.espindola at gmail
                   |                            |dot com
      Known to fail|                            |4.8.0

--- Comment #7 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-07-03 12:39:46 UTC ---
Heh, not sure ;)  Btw, the issue reproduces on trunk as well.  And if I use
-fno-fat-lto-objects I get a maybe more easily to debug linker failure:

repro> make USE_LTO=1
/space/rguenther/install/gcc-4.7.1/bin/g++ -B /abuild/rguenther/trunk-g/gcc -c
main.cpp -o main.o -ffunction-sections -funwind-tables -O2 -DNDEBUG
-fno-exceptions -fno-rtti -fno-fat-lto-objects -flto
In file included from main.cpp:1:0:
common.h:8:22: warning: inline function 'virtual void C::f()' used but never
defined [enabled by default]
  inline virtual void f();
                      ^
/space/rguenther/install/gcc-4.7.1/bin/g++ -B /abuild/rguenther/trunk-g/gcc -c
impl.cpp -o impl.o -ffunction-sections -funwind-tables -O2 -DNDEBUG
-fno-exceptions -fno-rtti -fno-fat-lto-objects -flto
ar rcs libdummy.a impl.o
/space/rguenther/install/gcc-4.7.1/bin/g++ -B /abuild/rguenther/trunk-g/gcc
main.o libdummy.a -o test.exe  -flto
/tmp/ccXwNVS0.ltrans0.ltrans.o: In function `main':
ccXwNVS0.ltrans0.o:(.text+0xc): undefined reference to `vtable for C'
ccXwNVS0.ltrans0.o:(.text+0x18): undefined reference to `C::f()'
ccXwNVS0.ltrans0.o:(.text+0x24): undefined reference to `C::g()'
collect2: error: ld returned 1 exit status
make: *** [test.exe] Error 1

note the warning about C::f() being never defined.  That leaves the vtable
for C in main.o with a reference to an external function - not sure if
that's valid from the ABI point of view (or if this is valid C++).

Might also be related to PR53808.

[Bug lto/53831] Inline virtuals missing in LTO symtab

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-07-03 12:46:36 UTC ---
So I think GCC is wrong to optimize away C::f() from impl.cpp and your analysis
is correct.  It is referenced from the vtable and we output that.

[Bug lto/53831] Inline virtuals missing in LTO symtab

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-07-03 12:54:07 UTC ---
Or your program is invalid because you have no inline definition where you
have a use.

[Bug lto/53831] Inline virtuals missing in LTO symtab

[tetra2005 at gmail dot com]

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

--- Comment #10 from Yuri Gribov <tetra2005 at gmail dot com> 2012-07-03 12:59:01 UTC ---
> if I use -fno-fat-lto-objects I get a maybe more easily to debug linker failure

I guess that's because in this case archive symtab doesn't reference any
symbols at all (which is another bug):
  $ nm libdummy.a 
  impl.o:
  00000001 C __gnu_lto_slim
  00000001 C __gnu_lto_v1
so linker doesn't get any symbols from impl.o (not even _ZTV1C).

> Or your program is invalid because you have no inline definition where you
have a use.

I'm not sure whether inline virtual without definition is valid in C++. But I
googled a bit before submitting the bug and found no evidence that it's a
non-standard (and more importantly - non-lto g++ accepts this code
just fine).

[Bug lto/53831] Inline virtuals missing in LTO symtab

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-07-03 13:11:59 UTC ---
(In reply to comment #10)
> > if I use -fno-fat-lto-objects I get a maybe more easily to debug linker failure
> 
> I guess that's because in this case archive symtab doesn't reference any
> symbols at all (which is another bug):
>   $ nm libdummy.a 
>   impl.o:
>   00000001 C __gnu_lto_slim
>   00000001 C __gnu_lto_v1
> so linker doesn't get any symbols from impl.o (not even _ZTV1C).

you need to use the LTO aware nm that gcc installs, gcc-nm.  It says

> gcc-nm-4.7 libdummy.a 

impl.o:
00000000 T _ZN1C1fEv
00000000 T _ZN1C1gEv
00000000 W _ZTV1C

> > Or your program is invalid because you have no inline definition where you
> have a use.
> 
> I'm not sure whether inline virtual without definition is valid in C++. But I
> googled a bit before submitting the bug and found no evidence that it's a
> non-standard (and more importantly - non-lto g++ accepts this code
> just fine).

Btw, removing the 'inline' keyword everywhere still reproduces the issue.
That makes the testcase certainly valid.

[Bug lto/53831] Inline virtuals missing in LTO symtab

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-07-03 13:17:12 UTC ---
Created attachment 27735
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27735
adjusted testcase

Certainly valid testcase w/o inline.  Fails at -O0 even, added
-fno-fat-lto-objects to ease debugging.

[Bug lto/53831] [4.7/4.8 Regression] Virtuals missing in LTO symtab

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |4.6.3
   Target Milestone|---                         |4.7.2
            Summary|Inline virtuals missing in  |[4.7/4.8 Regression]
                   |LTO symtab                  |Virtuals missing in LTO
                   |                            |symtab

--- Comment #13 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-07-03 13:19:13 UTC ---
GCC 4.6.3 works for me, so this is a regression.

[Bug lto/53831] [4.7/4.8 Regression] Virtuals missing in LTO symtab

[hubicka at gcc dot gnu.org]

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

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                     |

[Bug lto/53831] [4.7/4.8 Regression] Virtuals missing in LTO symtab

[tetra2005 at gmail dot com]

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

--- Comment #14 from Yuri Gribov <tetra2005 at gmail dot com> 2012-07-03 13:31:28 UTC ---
> you need to use the LTO aware nm that gcc installs, gcc-nm.  It says

My bad.

> Btw, removing the 'inline' keyword everywhere still reproduces the issue.
> That makes the testcase certainly valid.
  $ make USE_LTO=1 clean all
  $ echo $?
  0
Are you sure? Adding -Dinline= to CXXFLAGS fixed compilation for me:
I wasn't using -fno-fat-lto-objects though.

[Bug lto/53831] [4.7/4.8 Regression] Virtuals missing in LTO symtab

[markus at trippelsdorf dot de]

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

Markus Trippelsdorf <markus at trippelsdorf dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |markus at trippelsdorf dot
                   |                            |de

--- Comment #15 from Markus Trippelsdorf <markus at trippelsdorf dot de> 2012-07-03 13:38:46 UTC ---
(In reply to comment #11)

> you need to use the LTO aware nm that gcc installs, gcc-nm.  It says

You also need to use LTO aware ar that gcc installs...

[Bug lto/53831] [4.7/4.8 Regression] Virtuals missing in LTO symtab

[markus at trippelsdorf dot de]

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

--- Comment #16 from Markus Trippelsdorf <markus at trippelsdorf dot de> 2012-07-03 13:46:43 UTC ---
IOW with:

 % cat =ar
#!/bin/sh
cmd=$1
shift
/usr/bin/ar $cmd --plugin
/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.0/liblto_plugin.so $*

I cannot reproduce the issue anymore.

[Bug lto/53831] [4.7/4.8 Regression] Virtuals missing in LTO symtab

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #27735|0                           |1
        is obsolete|                            |

--- Comment #17 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-07-03 14:10:31 UTC ---
Comment on attachment 27735
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27735
adjusted testcase

True ... my bad.

[Bug lto/53831] [4.7/4.8 Regression] Virtuals missing in LTO symtab

[rguenth at gcc dot gnu.org]

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

--- Comment #18 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-07-03 14:13:38 UTC ---
That leaves us with the testcase that eventually is invalid.  The testcase
is fixed when using -fno-fat-lto-objects and gcc-ar (which is not required,
or should not be required(?) for -ffat-lto-objects?)

[Bug lto/53831] [4.7/4.8 Regression] Virtuals missing in LTO symtab

[tetra2005 at gmail dot com]

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

--- Comment #19 from Yuri Gribov <tetra2005 at gmail dot com> 2012-07-03 16:55:27 UTC ---
(In reply to comment #18)

> The testcase is fixed when using -fno-fat-lto-objects and gcc-ar

For me x64_64-linux version works if I use gcc-ar (both with and without
-fno-fat-lto-objects).

> (which is not required, or should not be required(?) for -ffat-lto-objects?)

No idea, today is the first time I hear about gcc-nm/ar. Are there any online
docs? Are users supposed to create LTO archives with gcc-ar instead of good ol'
ar these days?

[Bug lto/53831] [4.7/4.8 Regression] Virtuals missing in LTO symtab

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andi-gcc at firstfloor dot
                   |                            |org

--- Comment #20 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-07-04 09:27:53 UTC ---
(In reply to comment #19)
> (In reply to comment #18)
> 
> > The testcase is fixed when using -fno-fat-lto-objects and gcc-ar
> 
> For me x64_64-linux version works if I use gcc-ar (both with and without
> -fno-fat-lto-objects).
> 
> > (which is not required, or should not be required(?) for -ffat-lto-objects?)
> 
> No idea, today is the first time I hear about gcc-nm/ar. Are there any online
> docs? Are users supposed to create LTO archives with gcc-ar instead of good ol'
> ar these days?

Good question, even I am not sure.  This is an area that could have
documentation.  Honza, Andi, can you clarify?

[Bug lto/53831] [4.7/4.8 Regression] Virtuals missing in LTO symtab

[andi-gcc at firstfloor dot org]

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

--- Comment #21 from Andi Kleen <andi-gcc at firstfloor dot org> 2012-07-04 12:24:45 UTC ---
For non fat ("slim") LTO builds you need to use these tools yes. ar needs to
know the symbol table for its index and that needs LTO specific knowledge.

This follows other slim lto compilers like LLVM or icc.

There's no special documentation because the usage is the same as the standard
ar/ranlib/nm. The lto documentation hints at them, but could be perhaps
clearer.

[Bug lto/53831] [4.7/4.8 Regression] Virtuals missing in LTO symtab

[tetra2005 at gmail dot com]

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

--- Comment #22 from Yuri Gribov <tetra2005 at gmail dot com> 2012-07-04 12:32:08 UTC ---
> For non fat ("slim") LTO builds you need to use these tools yes

So it seems that original testcase with fat files which used plain ar is indeed
correct and we have a real bug.

[Bug lto/53831] [4.7/4.8 Regression] Virtuals missing in LTO symtab

[tetra2005 at gmail dot com]

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

--- Comment #23 from Yuri Gribov <tetra2005 at gmail dot com> 2012-07-10 15:34:02 UTC ---
The C++ Standard says that "an inline function shall be defined in every
translation unit in which it is used" (n1905, 7.1.2). The test in question
violates this rule: definition for C::f() is present only in impl.cpp.

Should we consider the test invalid?

[Bug lto/53831] [4.7/4.8 Regression] Virtuals missing in LTO symtab

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.7.2                       |4.7.3

--- Comment #24 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-09-20 10:13:42 UTC ---
GCC 4.7.2 has been released.

[Bug lto/53831] [4.7/4.8 Regression] Virtuals missing in LTO symtab

[hubicka at gcc dot gnu.org]

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

--- Comment #25 from Jan Hubicka <hubicka at gcc dot gnu.org> 2012-10-06 14:50:27 UTC ---
What you hit here is the V1 linker plugin API hack.  We, for purpose, hide
COMDAT objects when we know we can hide them, because otherwise linker will
assign them PREVAILING and we will be forced to output them even if they are
otherwise unused.  This kills code quality and breaks some C++ apps.

Plugin API is underspecfied as what symbols you can create without being asked
for.  Obviously one need to create ones to get WHOPR work. I would agree with
comment #4 that linker should survive introduction of the COMDAT.

I am not sure if the testcase is invalid - it should include the definition of
the function IMO. But without giving up on V1 API we can not fix that.  I am
going to commit that to 4.8, so that will leave it 4.7 regression (or
non-regression) only.

We discussed it couple times - there is way to get this working with V2 linker
while still supporting hack for V1 API. It requires moving the whole logic into
plugin and I am not sure it is worth the effort for 4.7 alone.

[Bug lto/53831] [4.7/4.8 Regression] Virtuals missing in LTO symtab

[hubicka at gcc dot gnu.org]

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

--- Comment #26 from Jan Hubicka <hubicka at gcc dot gnu.org> 2012-10-06 15:30:12 UTC ---
Also note that binutils has default search path for plugin. If we installed our
linker plugin there, the ugly gcc-nm/gcc-ar wrappers would not be needed.

[Bug lto/53831] [4.7/4.8 Regression] Virtuals missing in LTO symtab

[markus at trippelsdorf dot de]

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

--- Comment #27 from Markus Trippelsdorf <markus at trippelsdorf dot de> 2012-10-06 16:06:03 UTC ---
(In reply to comment #26)
> Also note that binutils has default search path for plugin. If we installed our
> linker plugin there, the ugly gcc-nm/gcc-ar wrappers would not be needed.

There is also H.J.'s proposal to add automatic plugin support, or
mine to add an environment variable. See:
http://sourceware.org/ml/binutils/2012-10/msg00050.html

[Bug lto/53831] [4.7/4.8 Regression] Virtuals missing in LTO symtab

[hubicka at ucw dot cz]

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

--- Comment #28 from Jan Hubicka <hubicka at ucw dot cz> 2012-10-06 16:20:57 UTC ---
> There is also H.J.'s proposal to add automatic plugin support, or
> mine to add an environment variable. See:
> http://sourceware.org/ml/binutils/2012-10/msg00050.html
Interesting, I missed this.

Why nm/ar/ld can't just support multiple plugins and load all plugins from its
default plugin directory (where all installed compilers will drop one) and
choose
the one claiming the file?
I see it would need some work on linker side if one plugin claims one file and
other
plugin other file, but there don't seem to be anything in the plugin API making
this
impossible and we can just error out in this case until mixing LTO from
different
compilers become fashionable.

Honza

[Bug lto/53831] [4.7/4.8 Regression] Virtuals missing in LTO symtab

[hubicka at gcc dot gnu.org]

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

--- Comment #29 from Jan Hubicka <hubicka at gcc dot gnu.org> 2012-10-06 17:30:51 UTC ---
Author: hubicka
Date: Sat Oct  6 17:30:42 2012
New Revision: 192166

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192166
Log:
    PR lto/53831
    PR lto/54776
    * lto-streamer-out.c (produce_symtab): Cleanup; drop v1 API hack.

Added:
    trunk/gcc/testsuite/g++.dg/lto/v1-plugin-api-not-supported_0.C
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/lto-streamer-out.c
    trunk/gcc/testsuite/ChangeLog

[Bug lto/53831] [4.7/4.8 Regression] Virtuals missing in LTO symtab

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |WAITING

--- Comment #30 from Richard Biener <rguenth at gcc dot gnu.org> 2012-12-06 16:24:19 UTC ---
Is this fixed on trunk?

[Bug lto/53831] [4.7 Regression] Virtuals missing in LTO symtab

[hubicka at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|hubicka at gcc dot gnu.org  |unassigned at gcc dot
                   |                            |gnu.org
            Summary|[4.7/4.8 Regression]        |[4.7 Regression] Virtuals
                   |Virtuals missing in LTO     |missing in LTO symtab
                   |symtab                      |

--- Comment #31 from Jan Hubicka <hubicka at gcc dot gnu.org> 2013-01-09 21:40:46 UTC ---
Yes, should be fixed for 4.8. We still do not install plugin in the binutils
search path, but it is different issue. When you use plugin enabled tools it
works.

[Bug lto/53831] [4.7 Regression] Virtuals missing in LTO symtab

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.7.3                       |4.7.4

--- Comment #32 from Richard Biener <rguenth at gcc dot gnu.org> 2013-04-11 07:59:01 UTC ---
GCC 4.7.3 is being released, adjusting target milestone.

[Bug lto/53831] [4.7 Regression] Virtuals missing in LTO symtab

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

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

--- Comment #34 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
(In reply to Sami Farin from comment #33)
> Is 4.9.0 supposed to work with -flto with ar archives? It works if I do gcc
> -flto *.o, though.
> 
> $ gcc-ar r libdiv.a div64.o
> /bin/ar terminated with signal 11 [Segmentation fault]
> 
> ...
> 
> Starting program: /usr/bin/ar r --plugin
> /usr/libexec/gcc/x86_64-redhat-linux/4.9.?/liblto_plugin.so libdiv.a div64.o
> 
> Program received signal SIGSEGV, Segmentation fault.
> bfd_plugin_get_symbols_in_object_only (abfd=0x6138f0) at plugin.c:151
> 151	  plugin_data->object_only_syms = NULL;
> (gdb) bt
> #0  bfd_plugin_get_symbols_in_object_only (abfd=0x6138f0) at plugin.c:151
> #1  add_symbols (handle=0x6138f0, nsyms=1, syms=0x618e20) at plugin.c:278
> #2  0x00007ffff0bb577a in claim_file_handler (file=0x7fffffff9880,
> claimed=0x7fffffff987c) at ../../lto-plugin/lto-plugin.c:929

This looks like a binutils bug to me. What version of binutils are you using?
Does it still happen with binutils trunk?
>From gcc-bugs-return-451927-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon May 19 16:03:18 2014
Return-Path: <gcc-bugs-return-451927-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8660 invoked by alias); 19 May 2014 16:03:17 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 8601 invoked by uid 48); 19 May 2014 16:03:12 -0000
From: "Joost.VandeVondele at mat dot ethz.ch" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/61234] New: Warn for use-stmt without explicit only-list.
Date: Mon, 19 May 2014 16:03:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: Joost.VandeVondele at mat dot ethz.ch
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-61234-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-05/txt/msg01619.txt.bz2
Content-length: 678

https://gcc.gnu.org/bugzilla/show_bug.cgi?ida234

            Bug ID: 61234
           Summary: Warn for use-stmt without explicit only-list.
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: Joost.VandeVondele at mat dot ethz.ch

It would be nice to have a warning (-Wuse-only) for a use-stmt without explicit
only-list. It would allow for enforcing this good style with -Werror.

Extra useful would be if the warning message would list everything that would
be required on the only-list.

[Bug lto/53831] [4.7 Regression] Virtuals missing in LTO symtab

[hvtaifwkbgefbaei at gmail dot com]

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

--- Comment #35 from Sami Farin <hvtaifwkbgefbaei at gmail dot com> ---
binutils-2.24-13.fc21
haven't tried latest from git://sourceware.org/git/binutils-gdb.git

[Bug lto/53831] [4.7 Regression] Virtuals missing in LTO symtab

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
      Known to work|                            |4.8.0
         Resolution|---                         |FIXED
   Target Milestone|4.7.4                       |4.8.0
      Known to fail|4.8.0                       |4.7.4

--- Comment #36 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed for 4.8.0.

[Bug lto/53831] [4.7 Regression] Virtuals missing in LTO symtab

[htl10 at users dot sourceforge.net]

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

Hin-Tak Leung <htl10 at users dot sourceforge.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |htl10 at users dot sourceforge.net

--- Comment #37 from Hin-Tak Leung <htl10 at users dot sourceforge.net> ---
(In reply to Sami Farin from comment #35)
> binutils-2.24-13.fc21
> haven't tried latest from git://sourceware.org/git/binutils-gdb.git

Apparently that's due to a redhat-specific patch.
https://bugzilla.redhat.com/show_bug.cgi?id=1149660
https://bugzilla.redhat.com/show_bug.cgi?id=1174065

If you upgrade to binutils-2.24-29.fc21+ , building 64-bit archive on 64-bit
host would work; but it would still segfault building 32-bit archive on 64-bit
host. Just upgraded to fedora 21 and gotten bitten by it, and still looking for
a solution.

[Bug lto/53831] [4.7 Regression] Virtuals missing in LTO symtab

[htl10 at users dot sourceforge.net]

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

--- Comment #38 from Hin-Tak Leung <htl10 at users dot sourceforge.net> ---
This is the only reference I have about the redhat specific patch. (from
redhat's binutils packaging git). I think "H.J." is "H.J.Lu" but I can't find
anything further - I am hoping there is an updated patch, or any kind of blog
or mailing list post that explains what the patch tries to do.

commit d43b72113c5879ddde546867dfe23baaccf35c1f
Author: Nick Clifton <nickc@redhat.com>
Date:   Fri May 17 08:42:58 2013 +0100

    Import H.J.'s patch to add support for kernel ld -r modules.