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.
