[Bug lto/50687] New: Missing symbols with -flto -fvisibility=hidden on 4.6.x but not on 4.7.0

[Bug lto/50687] New: Missing symbols with -flto -fvisibility=hidden on 4.6.x but not on 4.7.0

[giulio.eulisse at cern dot ch]

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

             Bug #: 50687
           Summary: Missing symbols with -flto -fvisibility=hidden on
                    4.6.x but not on 4.7.0
    Classification: Unclassified
           Product: gcc
           Version: 4.6.2
            Status: UNCONFIRMED
          Severity: blocker
          Priority: P3
         Component: lto
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: giulio.eulisse@cern.ch


There seems to be a bug (or least a different behavior) when compiling: 

  cat >test.cc <<-EOF
  struct bar {
     static void * foo();
     virtual void * getFoo() const { return bar::foo();}
  };
  EOF

with:

  c++ -fPIC -shared -flto -fvisibility=hidden test.cc

using gcc 4.6.x (both 4.6.1 release and this week 4.6.2 snapshot) compared to
gcc
4.7.0 (20111001 snapshot).

In the case of gcc 4.6.x I get a missing symbol:

  % nm a.out | grep U
  U _ZN3bar3fooEv  

while with 4.7.x I don't get it anymore (which is what I would expect).

Dropping -flto fixes the behavior also for 4.6.x.

[Bug lto/50687] Missing symbols with -flto -fvisibility=hidden on 4.6.x but not on 4.7.0

[lat at cern dot ch]

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

Lassi Tuura <lat at cern dot ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lat at cern dot ch

--- Comment #1 from Lassi Tuura <lat at cern dot ch> 2011-10-11 09:25:24 UTC ---
FWIW, I don't think this is a bug in the compiler. With -fvisibility=hidden a
promise is made that bar::foo() is internal to the shared library, and if the
compiler generates virtual function table for bar, it needs foo too.

At least on a system I tested, RHEL5-derived system with GCC 4.6.1 and binutils
2.21.1 gold as the linker, the reason there's no unreferenced symbols without
-flto is simply that no code what so ever is getting generated for 'bar'. In
fact no code at all is emitted for test.cc. I assume the compiler just decides
the class is irrelevant to the compilation unit, which seems entirely
reasonable choice to me -- otherwise it'd be generating code for loads of types
from headers which are never used in a particular compilation unit.

With 4.6.x LTO presumably this pruning doesn't happen, or isn't complete
enough, and/or isn't garbage collected at link phase as unreferenced, so the
bar::foo reference remains and becomes unsatisfied symbol - which seems
reasonable to me. Perhaps it's a quality issue that unreferenced types cause
code to be generated, but IMHO is not a bug in the compiler.

If I change the code so it forces a reference generated for bar, so the bar
virtual function table gets generated, triggering getFoo() to be compiled, I
get the same undefined symbol without LTO with GCC 4.6.1 too. I didn't try with
GCC trunk, so can't comment on why the reference isn't seen there.

[Bug lto/50687] Missing symbols with -flto -fvisibility=hidden on 4.6.x but not on 4.7.0

[giulio.eulisse at cern dot ch]

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

Giulio Eulisse <giulio.eulisse at cern dot ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|blocker                     |normal

--- Comment #2 from Giulio Eulisse <giulio.eulisse at cern dot ch> 2011-10-11 09:56:56 UTC ---
Sorry for the bad wording, let's just call it "different behavior" between
4.6.x + -flto and 4.7.x (with and without -flto) or 4.6.1 (without -flto).

What would be satisfactory for me is to know whether this different behavior is
intended or not and if not whether there is plan to make the behavior uniform
in 4.6.2.

Also notice that the difference is not -fvisibility=hidden related as the same
kind of difference persists if such an option is dropped.

[Bug lto/50687] Missing symbols with -flto -fvisibility=hidden on 4.6.x but not on 4.7.0

[paolo.carlini at oracle dot com]

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

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

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

--- Comment #3 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-10-11 09:58:16 UTC ---
Honza, could you help triaging this?

[Bug lto/50687] Missing symbols with -flto -fvisibility=hidden on 4.6.x but not on 4.7.0

[lat at cern dot ch]

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

--- Comment #4 from Lassi Tuura <lat at cern dot ch> 2011-10-11 12:00:47 UTC ---
Right, as far as I can tell at the moment visibility option is somewhat
peripheral to the issue. The main difference you see with LTO vs. no LTO
appears to be whether code for the type is generated at all. As far as I can
tell, once the compiler decides to generate code for 'bar', you get the same
behaviour in all cases. The visibility controls only apply after that.

Whether it's an issue that LTO in 4.6.x generates references to otherwise
unreferenced  types I can't say. I'd say it is not invalid, though perhaps
undesirable. But once code is generated for types like 'bar', the app needs to
make sure it uses correct visibility controls.

As far as I understand, the actual upstream problem is that 'bar' really comes
from a header file, from another package. The #include for that header is not
using visibility push/pop to reset visibility to 'default', so the header
inherits the 'hidden' visibility from command line. At the moment, without
visibility directives, there's a side effect that 4.6.x LTO generates
references to otherwise unused types from those headers, resulting in link
errors. But I'd suggest this usage is quite fragile - the moment anything from
those headers is actually referenced, the app needs to be fixed to reset
visibility to 'default' around #includes anyway (because the module in question
is being compiled with -fvisibility=hidden).

Of course if 4.6.x can be amended to prune types from LTO more aggressively, it
will help to avoid this particular issue. I'm just not sure it will actually
fix all the upstream problems, I rather suspect some types coming from headers
are actually referenced in ways which in the end will require full visibility
management in the source code.