[Bug c++/92855] -fvisibility-inlines-hidden failing to hide out-of-line copies of certain inline member functions

[thiago at kde dot org]

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

--- Comment #5 from Thiago Macieira <thiago at kde dot org> ---
(In reply to Alexander Monakov from comment #4)
> (FWIW, making 'f' a template in your example makes it non-hidden)
> 
> Can you explain why you expect the command-line option to override the
> attribute on the namespace? GCC usually implements the opposite, i.e.
> attributes prevail over the defaults specified on the command line.
> 
> In your sample on Godbolt, Clang also appears to honour the attribute rather
> than the option.

And ICC does the opposite and hides everything. Either way, GCC's behaviour of
applying this to templates (which is bug 47877, so you may close as duplicate)
is unexpected and seems inconsistent.

I expect the emitted function to be hidden because it's inline and because of
-fvisibility-inlines-hidden. From the TexInfo manual:

     The effect of this is that GCC may, effectively, mark inline
     methods with '__attribute__ ((visibility ("hidden")))' so that they
     do not appear in the export table of a DSO and do not require a PLT
     indirection when used within the DSO.  Enabling this option can
     have a dramatic effect on load and link times of a DSO as it
     massively reduces the size of the dynamic export table when the
     library makes heavy use of templates.

Since the out-of-line copies of the inline functions will be emitted in every
TU that failed to inline them, and thus remain in every DSO, there's no need to
export them. Each DSO can call its own, local copy through PC-relative calls
and jumps.

For the particular problem at hand, which we're still debugging, see
https://bugreports.qt.io/browse/QTBUG-80535. The issue there is that certain
non-Qt symbols were exported by the DSO and thus got tagged with the ELF
version "Qt_5". That by itself is not a problem, but we've found that some
applications began referencing those symbols with that ELF version and we don't
understand why. The result is that the internal details of how something was
implemented became part of our ABI.