This is the mail archive of the gcc-prs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

c++/10680: Inlining in inheritance seems broken.


>Number:         10680
>Category:       c++
>Synopsis:       Inlining in inheritance seems broken.
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu May 08 13:16:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     Michael Nielsen
>Release:        gcc version 3.2.1
>Organization:
>Environment:
Linux i686

Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/specs
Configured with: ../configure --enable-languages=c c++
Thread model: posix
gcc version 3.2.1
>Description:
We have a class hierachy where there is a lot of inheritance, and functions (commonly used) are in the base of the tree, and the sub classes then use this functionality farther down..  But because the code is called a lot of times I'd really like the code to be inlined in the sub classes, so I put some inlines into the class definition, expecting the compiler to use this to inline the code as much as possible

I have reduced the code down to a few lines, and can reproduce the same issues with this trivial code example.

When creating a simple inheritance system, with two classes located in two different files (a.h, and b.h).

a.h : 

#include <list> 
class A {
	public:
		
		void a();


	protected:
		void b();

	private:
		std::list<class A *> *_a;
};

b.h

#include "a.h"
#include <list>

class B : public A {
	public:
		B();

	private:
		std::list<A * > *_a;
};


The implementations of A and B are placed in a.cpp, and b.cpp, (see attachment for full code).

A program main.cpp creates an instance of B, to activate the classes, and cause a call to the inlined functions.

Then when compiling by.

g++ *.cpp -o testprog

The resulting message is:

/tmp/ccHXusSr.o: In function `B::B[not-in-charge]()':
/tmp/ccHXusSr.o(.text+0x18): undefined reference to `A::a()'
/tmp/ccHXusSr.o(.text+0x23): undefined reference to `A::b()'
/tmp/ccHXusSr.o: In function `B::B[in-charge]()':
/tmp/ccHXusSr.o(.text+0x42): undefined reference to `A::a()'
/tmp/ccHXusSr.o(.text+0x4d): undefined reference to `A::b()'
collect2: ld returned 1 exit status


It seems that the compiler has removed the inlined functions from the definition, and only inlined them in the a.o file, making them unavailable in the sub class B.   

This behaviour is different from what I expected.  

>From the C++ language definition the calls A::a(), and A::b() should be available in class B, however the compiler has removed the code, due to the inline, thus they are not available in B.

This seems to me, to be in conflict with the C++ language definition ?.   

I've tried adding the -fkeep-inline-functions, and this fixes the issue, however then enabling -O3 on the compiler, will then cause several of the std:: files such as 
bool std::lexicographical_compare to become multiply defined, when you use iostreams, and lists from stl.

Not sure if it is a bug, or an understanding issue.

>How-To-Repeat:
take the included archive, and extract it, go to the directory testprog.

run make.
or
g++ *.cpp -o testprog -fkeep-inline-functions -O3
or
g++ *.cpp -o testprog -fkeep-inline-functions -finline-functions -O2

This will generate errors..

run the command 

g++ *.cpp -o testprog -fkeep-inline-functions
or
g++ *.cpp -o testprog -fkeep-inline-functions  -O2


And the code will compile flawlessly.

>Fix:
Temp work around, do not combine -O2 and -finline-functions, or use -O3.
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/x-bzip2; name="testprog.tar.bz2"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="testprog.tar.bz2"

QlpoOTFBWSZTWbN2uJAAAx//5sewAEBYe/+dOAKUhP/v32oCAAgAAACISAAIQAJxLpqylCSUJqeT
ap+oajJ6QbUaPJAyANGmJoNPUEiIEVMnqMm1NMQ0ZMEPSAwRoaAHNMTJk0YTBMTTAJgEMEYEYBFR
FPaieoxD1PU0ZHqA0ADQ9QA0Af7Ul1NnwNrSLdsWSeu2m2hPAgS3a7kb2JkVGJRSN6J8rpFpfhYl
gS8STSSgTeYtltrSwIB9z34198KvuqRZSi1FLjc4HRwVYqEwEsInMEYMMOShSi+Eq9BXQDGTobcN
OelyVU2pTCDJIeuDOQzQXWae1qlHXRlwFQZiVSoKD9ZmSZkGxTLq63SIY9QLCPJsQaNuM8Y0xDbd
xeM2SgyVkOTIb6q4kTIW5RtLS0oWWdxxIQHnnWmYUuGEDK+6jpSneqUkvELWc5QWux4d9QIxllXE
298XwxXy0RnZGTzibpUM4FIlCTSqK2K3ttDHG4SYCswlWp5ipIkVgZa8kDBxwmI61bVLDYA+Q+ww
UT6awLnetHJmvjpOhovoMyUssqlyQ0Dz3y5sJeSwqc2D917PHmsh2KBSXzMJEq0g+GgI3kuCkAzL
fguyKSZy0gTkomgdxEConxGW7VEiEFvgmikQwi5tUsPIAuwSQaQVjt4uzkYRl8SdNFUopDGp1aoL
ZIYCUSIB/DSlrW+Xj3YAOOCkxhqmMBPgILtBOxvPeGOIa5hAhZA1FmGgoJEUIhTUnySSkMC56Vhc
AvEAolMSgiQtP+y5tsx2f22yVwlfVAkY7EriwFwrKy6TAbYFir/i7kinChIWbtcSAA==


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]