[Bug c++/61214] New: [4.9 regression] Weird interaction between -fvisibility-inlines-hidden, inline virtuals and devirtualization

["delroth@dolphin-emu.org" <gcc-bugzilla@gcc.gnu.org>]

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

            Bug ID: 61214
           Summary: [4.9 regression] Weird interaction between
                    -fvisibility-inlines-hidden, inline virtuals and
                    devirtualization
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: delroth@dolphin-emu.org

Created attachment 32814
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32814&action=edit
Small test case reproducing this issue

A shared library (libtest.so) is compiled using -fvisibility=hidden
-fvisibility-inlines-hidden. This library exports (visibility=default) a class
hierarchy with virtual inline methods:

struct VISIBILITY_DEFAULT Base { virtual Base* clone() { return new Base(); }};
struct VISIBILITY_DEFAULT Foo { virtual Base* clone() { return new Foo(); }};
// + at least one method that is defined in a compilation unit, along with the
vtable, typeinfo, etc.

The code that uses libtest.so looks like this:
Base* obj = new Foo();
obj->clone();

When this is compiled to libtest.so, Base::clone and Foo::clone are not present
among the exported symbols. This did not cause issues before g++4.9 because g++
was not smart enough to determine that "obj" is always a Foo. It always issued
a call through the vtable, which *is* exported by libtest.so (and contains a
valid entry for Foo::clone).

Now, with g++4.9 and (better) devirtualization, g++ tries to generate a direct
call to Foo::clone. But instead of instantiating the inline function, it
assumes the inline function is already instantiated. This fails at link time
because no definition of Foo::clone can be found.

Small test case attached (with Makefile, reproduces the bug on g++4.9 on Linux
x86_64). In practice, s/libtest/wxWidgets/,
s/Foo::clone/wxCommandEvent::Clone/. Whether this is a bug of wxWidgets that
should not be using -fvisibility-inlines-hidden or a bug of g++4.9 that should
be instantiating the inline function, is something you will have to debate :)
>From gcc-bugs-return-451836-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun May 18 03:26:09 2014
Return-Path: <gcc-bugs-return-451836-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 30547 invoked by alias); 18 May 2014 03:26:01 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 30459 invoked by uid 48); 18 May 2014 03:25:53 -0000
From: "sandra at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/60758] Infinite backtrace in  __cxa_end_cleanup
Date: Sun, 18 May 2014 03:26:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: sandra at codesourcery dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-60758-4-mxPrPyBb4X@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60758-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60758-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-05/txt/msg01528.txt.bz2
Content-length: 2232

https://gcc.gnu.org/bugzilla/show_bug.cgi?id`758

Sandra Loosemore <sandra at codesourcery dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sandra at codesourcery dot com

--- Comment #5 from Sandra Loosemore <sandra at codesourcery dot com> ---
The patch committed as r210215 is broken for -mthumb on arm-none-eabi:

libtool: compile:
/scratch/sandra/arm-fsf/obj/gcc-mainline-0-arm-none-eabi-i686-pc-linux-gnu/./gcc/xgcc
-shared-libgcc
-B/scratch/sandra/arm-fsf/obj/gcc-mainline-0-arm-none-eabi-i686-pc-linux-gnu/./gcc
-nostdinc++
-L/scratch/sandra/arm-fsf/obj/gcc-mainline-0-arm-none-eabi-i686-pc-linux-gnu/arm-none-eabi/thumb/libstdc++-v3/src
-L/scratch/sandra/arm-fsf/obj/gcc-mainline-0-arm-none-eabi-i686-pc-linux-gnu/arm-none-eabi/thumb/libstdc++-v3/src/.libs
-L/scratch/sandra/arm-fsf/obj/gcc-mainline-0-arm-none-eabi-i686-pc-linux-gnu/arm-none-eabi/thumb/libstdc++-v3/libsupc++/.libs
-B/scratch/sandra/arm-fsf/install/arm-none-eabi/bin/
-B/scratch/sandra/arm-fsf/install/arm-none-eabi/lib/ -isystem
/scratch/sandra/arm-fsf/install/arm-none-eabi/include -isystem
/scratch/sandra/arm-fsf/install/arm-none-eabi/sys-include -mthumb
-I/scratch/sandra/arm-fsf/src/gcc-mainline/libstdc++-v3/../libgcc
-I/scratch/sandra/arm-fsf/obj/gcc-mainline-0-arm-none-eabi-i686-pc-linux-gnu/arm-none-eabi/thumb/libstdc++-v3/include/arm-none-eabi
-I/scratch/sandra/arm-fsf/obj/gcc-mainline-0-arm-none-eabi-i686-pc-linux-gnu/arm-none-eabi/thumb/libstdc++-v3/include
-I/scratch/sandra/arm-fsf/src/gcc-mainline/libstdc++-v3/libsupc++
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=eh_arm.lo -g -O2 -mthumb -c
/scratch/sandra/arm-fsf/src/gcc-mainline/libstdc++-v3/libsupc++/eh_arm.cc -o
eh_arm.o
/tmp/cchJLQxH.s: Assembler messages:
/tmp/cchJLQxH.s:26: Error: invalid register list to push/pop instruction --
`pop {r1,r2,r3,lr}'

It looks to me like lr is valid in the reglist for PUSH but not POP on Thumb.

Since this breaks builds, please either fix ASAP or revert the broken patch.