public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "deane at gooroos dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/45065] New: -fvisibility-inlines-hidden: Decl order in derived class affects visibility of inlines in base. Date: Sun, 25 Jul 2010 08:01:00 -0000 [thread overview] Message-ID: <bug-45065-19481@http.gcc.gnu.org/bugzilla/> (raw) 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
next reply other threads:[~2010-07-25 8:01 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2010-07-25 8:01 deane at gooroos dot com [this message] 2010-07-25 8:04 ` [Bug c++/45065] " deane at gooroos dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-45065-19481@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).