[Bug c++/45065] -fvisibility-inlines-hidden: Decl order in derived class affects visibility of inlines in base.

["egallager at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2017-08-20
                 CC|                            |egallager at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #3 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to Dean Edmonds from comment #0)
> Compiling with -fvisibility=hidden and -fvisibility-inlines-hidden.
> 
> I have a Base class with default visibility which contains two virtual
> methods, one inlined and the other not. A Derived class with hidden
> visibility overrides the non-inlined method and doesn't touch the inlined
> one. If the declaration of the overridden method appears *before* the
> Derived's virtual destructor then the object file for Derived weakly exports
> the Base class's inlined method. But if the declaration appears *after*
> Derived's virtual destructor then the object for Derived doesn't export the
> Base class's inlined method at all.
> 
> Given that I'm compiling with -fvisibility-inlines-hidden I *think* that
> means that the Base class's inlined method should never be exported. Even if
> I'm wrong about that, surely it should not matter the order in which the
> Derived class's methods are declared.
> 
> Here's an example which demonstrates the problem:
> 
> class __attribute__ ((visibility("default"))) Base
> {
> public:
>     Base();
>     virtual ~Base();
>     virtual void func()  const;
>     virtual void inlineFunc()	{}
> };
> 
> class Derived : public Base
> {
> public:
>     Derived();
>     void func() const;
>     virtual ~Derived();
> };
> 
> void Derived::func() const
> {}
> 
> Compiled on OSX 10.6.4 with g++ 4.2.1, using the following command:
> 
>   g++-4.2 -Wall -c -arch x86_64 -fvisibility=hidden
> -fvisibility-inlines-hidden -O3 -m64 -isysroot
> /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6 -o Derived.o
> Derived.cpp
> 
> Looking at the object file using 'nm -m Derived.o | grep inlineFunc' gives:
> 
>   0000000000000010 (__TEXT,__textcoal_nt) weak private external
> __ZN6Common10inlineFuncEv
>   0000000000000098 (__TEXT,__eh_frame) weak private external
> __ZN6Common10inlineFuncEv.eh
> 
> If I move the declaration of Derived::func() so that it comes after
> ~Derived() then 'nm -m Derived.o | grep inlineFunc' returns nothing.
> 
> 

On 10.5 with gcc8, the grep only returns one line:

$ /usr/local/bin/g++ -Wall -c -arch x86_64 -fvisibility=hidden
-fvisibility-inlines-hidden -O3 -m64 -isysroot /Developer/SDKs/MacOSX10.5.sdk
-mmacosx-version-min=10.5 -Wextra -pedantic -o 45065.o 45065.cc
$ nm -m 45065.o | grep inlineFunc
0000000000000010 (__TEXT,__textcoal_nt) weak private external
__ZN4Base10inlineFuncEv

The difference is no version suffixed with '.eh' so I think it's a 10.5 to 10.6
difference.

> I see similar behaviour on GNU/Linux (2.6.30.9-96.fc11.x86_64) using g++
> 4.4.1. Compiling with this command:
> 
>   g++ -Wall -c -fvisibility=hidden -fvisibility-inlines-hidden -O3 -m64 -o
> Derived.o Derived.cpp
> 
> and using 'objdump -t Derived.o | grep inlineFunc' to inspect the result
> gives this when Derived::func() is declared before ~Derived():
> 
>   0000000000000000 l    d  .text._ZN4Base10inlineFuncEv   0000000000000000
> .text._ZN4Base10inlineFuncEv
>   0000000000000000  w    F .text._ZN4Base10inlineFuncEv   0000000000000002
> .hidden _ZN4Base10inlineFuncEv
> 
> and gives nothing when Derived::func() is declared after ~Derived().

(In reply to Paolo Carlini from comment #2)
> I can confirm the behavior with today's mainline. And seems weird indeed.

Changing status to NEW then since it's confirmed.