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

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

[Michael Nielsen]

The following reply was made to PR c++/10680; it has been noted by GNATS.

From: Michael Nielsen <mn@onair.dk>
To: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
	mike@thetroubleshooters.dk, nobody@gcc.gnu.org, gcc-prs@gcc.gnu.org,
	mn@onair.dk
Cc:  
Subject: Re: c++/10680: Inlining in inheritance seems broken.
Date: Fri, 09 May 2003 12:18:12 +0200

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10680
 
 Is this the correct spot to send a response to a closed PR ?
 
 
 Eh, you only answered one of the issues, the other issue was that.
 
 --fkeep-inline-functions combined with -O3, or -finline-functions, causes errors in the
 STL headers.
 
 
 
 
 
 But the line you qoute, means that in reality, the compiler should generate an error when
 compiling, when someone has an inline method in any section other than private:, because
 any method defined in the public: and protected: areas of a class are meant to be reusable
 farther down the class hierachy.  (though wether an error or warning, something
 should be generated, because it does not work, when you use the definition that
 have been cited in the bug report.).
 
 The current way it is implemented, a function can be inlined in either the cpp file, or the
 header, or both, in some of the cases, you cannot determine from the header file that the
 method is unavailable farther down, this makes it tricky to export API's, or to develop using
 an api.
 
 So it may be in accordance with the language definition, but it does not make sense the way it
 is implemented.  The compiler should emit some warning, or error, when someone tries to
 access a function that (in reality) is not visible from the caller, or when someone inlines
 a public/protected function, that will become unavailable farther down.  An inline function can
 in effect cause this situation, overriding the public, and protected keywords.
 
 Of course this is just IMHO.
 
 regards
     Michael Nielsen.
 

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

[nathan]

Synopsis: Inlining in inheritance seems broken.

State-Changed-From-To: open->closed
State-Changed-By: nathan
State-Changed-When: Thu May  8 13:51:37 2003
State-Changed-Why:
    not a bug. [7.1.2]/4 says 'an inline funcxtion shall be defined in every translation unit in which it is used ...'
    You have used it in translation unit b.cpp, but it is not defined nor declared inline within that TU.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10680

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

[mn]

>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==