Bug 65009 - [4.9 Regression] g++ 4.9 sometimes leaves inline methods undefined when compiling with -Os
Summary: [4.9 Regression] g++ 4.9 sometimes leaves inline methods undefined when compi...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.9.3
: P2 normal
Target Milestone: 5.0
Assignee: Not yet assigned to anyone
URL:
Keywords: wrong-code
Depends on:
Blocks:
 
Reported: 2015-02-10 23:22 UTC by Don Lewis
Modified: 2016-08-03 10:52 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work: 4.8.3, 5.0
Known to fail: 4.9.0
Last reconfirmed: 2015-02-11 00:00:00


Attachments
example code that generates undefined symbols for inline methods when compiled with -Os (451.55 KB, application/gzip)
2015-02-11 00:11 UTC, Don Lewis
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Don Lewis 2015-02-10 23:22:56 UTC
# g++49 -v
Using built-in specs.
COLLECT_GCC=g++49
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc49/gcc/i386-portbld-freebsd8.4/4.9.3/lto-wrapper
Target: i386-portbld-freebsd8.4
Configured with: ./../gcc-4.9-20150204/configure --with-build-config=bootstrap-debug --disable-nls --enable-gnu-indirect-function --libdir=/usr/local/lib/gcc49 --libexecdir=/usr/local/libexec/gcc49 --program-suffix=49 --with-as=/usr/local/bin/as --with-gmp=/usr/local --with-gxx-include-dir=/usr/local/lib/gcc49/include/c++/ --with-ld=/usr/local/bin/ld --with-libiconv-prefix=/usr/local --with-pkgversion='FreeBSD Ports Collection' --with-system-zlib --with-ecj-jar=/usr/local/share/java/ecj-4.5.jar --enable-languages=c,c++,objc,fortran,java --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/gcc49 --build=i386-portbld-freebsd8.4
Thread model: posix
gcc version 4.9.3 20150204 (prerelease) (FreeBSD Ports Collection) 


When compiling at the -Os optimization level, g++ 4.9 sometimes leaves undefined symbols in the resulting .o file.  In the example below, this causing a fatal linker error when trying to build a shared library that includes this .o file.  This problem does not occur when compiling with -O0 optimization, and does not occur with g++ 4.8.

In this example, the following class methods are inline:
  KeyListenerMultiplexer::acquire()
  FocusListenerMultiplexer::acquire()
  MouseListenerMultiplexer::acquire()
  PaintListenerMultiplexer::acquire()
  WindowListenerMultiplexer::acquire()
  MouseMotionListenerMultiplexer::acquire()

When the code is compiled with g++ 4.9 and -Os, the .o file contains undefined
symbols for them.  This does not happen with g++ 4.8 or when compiling with -O0.

Broken:

# g++49 -fPIC -fmessage-length=0 -fno-common -fno-strict-aliasing -fno-use-cxa-atexit -fvisibility-inlines-hidden -fvisibility=hidden -fexceptions -fno-enforce-eh-specs -Os -c fmgridif.ii -Wall -o fmgridif.o
# nm fmgridif.o | grep 'ListenerMultiplexer'              U _ZThn24_N22KeyListenerMultiplexer7acquireEv
         U _ZThn24_N24FocusListenerMultiplexer7acquireEv
         U _ZThn24_N24MouseListenerMultiplexer7acquireEv
         U _ZThn24_N24PaintListenerMultiplexer7acquireEv
         U _ZThn24_N25WindowListenerMultiplexer7acquireEv
         U _ZThn24_N30MouseMotionListenerMultiplexer7acquireEv
#


Works:

# g++49 -fPIC -fmessage-length=0 -fno-common -fno-strict-aliasing -fno-use-cxa-atexit -fvisibility-inlines-hidden -fvisibility=hidden -fexceptions -fno-enforce-eh-specs -O0 -c fmgridif.ii -Wall -o fmgridif.o
# nm fmgridif.o | grep 'ListenerMultiplexer'
#

Works:

# g++48 -fPIC -fmessage-length=0 -fno-common -fno-strict-aliasing -fno-use-cxa-atexit -fvisibility-inlines-hidden -fvisibility=hidden -fexceptions -fno-enforce-eh-specs -Os -c fmgridif.ii -Wall -o fmgridif.o
# nm fmgridif.o | grep 'ListenerMultiplexer'
#
Comment 1 Don Lewis 2015-02-11 00:11:48 UTC
Created attachment 34719 [details]
example code that generates undefined symbols for inline methods when compiled with -Os
Comment 2 Jakub Jelinek 2015-02-11 09:20:48 UTC
Bisected to r206042, related to devirtualization.  Since that commit there is:
         U _ZThn24_N22KeyListenerMultiplexer7acquireEv
         U _ZThn24_N24FocusListenerMultiplexer7acquireEv
         U _ZThn24_N24MouseListenerMultiplexer7acquireEv
         U _ZThn24_N24PaintListenerMultiplexer7acquireEv
         U _ZThn24_N25WindowListenerMultiplexer7acquireEv
         U _ZThn24_N30MouseMotionListenerMultiplexer7acquireEv
Stopped on the trunk with r215902, since then there is:
00000000 W _ZN22KeyListenerMultiplexer7acquireEv
00000000 W _ZN23ListenerMultiplexerBase7acquireEv
00000000 W _ZN24FocusListenerMultiplexer7acquireEv
00000000 W _ZN24MouseListenerMultiplexer7acquireEv
00000000 W _ZN24PaintListenerMultiplexer7acquireEv
00000000 W _ZN25WindowListenerMultiplexer7acquireEv
00000000 W _ZN30MouseMotionListenerMultiplexer7acquireEv
00000009 W _ZThn24_N22KeyListenerMultiplexer7acquireEv
00000009 W _ZThn24_N24FocusListenerMultiplexer7acquireEv
00000009 W _ZThn24_N24MouseListenerMultiplexer7acquireEv
00000009 W _ZThn24_N24PaintListenerMultiplexer7acquireEv
00000009 W _ZThn24_N25WindowListenerMultiplexer7acquireEv
00000009 W _ZThn24_N30MouseMotionListenerMultiplexer7acquireEv
Still reproduceable on the 4.9 branch.
Comment 3 Jakub Jelinek 2015-06-26 19:54:44 UTC
GCC 4.9.3 has been released.
Comment 4 Don Lewis 2015-09-05 05:59:07 UTC
Still fails with:

% gcc49 --version
gcc49 (FreeBSD Ports Collection) 4.9.4 20150819 (prerelease)
Copyright (C) 2015 Free Software Foundation, Inc.
Comment 5 Richard Biener 2016-08-03 10:52:25 UTC
Fixed in GCC 5+