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

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

[deane at gooroos dot com]

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.


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().


-- 
           Summary: -fvisibility-inlines-hidden: Decl order in derived class
                    affects visibility of inlines in base.
           Product: gcc
           Version: 4.4.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: deane at gooroos dot com


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

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

[deane at gooroos dot com]

------- Comment #1 from deane at gooroos dot com  2010-07-25 08:04 -------
Created an attachment (id=21305)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21305&action=view)
Complete example demonstrating bug.


-- 


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

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

[paolo.carlini at oracle dot com]

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

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

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

--- Comment #2 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-10-05 13:51:46 UTC ---
I can confirm the behavior with today's mainline. And seems weird indeed. Jason
can you help triaging this?