This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/47316] New: devirtualize calls to virtual methods that are never further overriden
- From: "zsojka at seznam dot cz" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Sun, 16 Jan 2011 15:15:36 +0000
- Subject: [Bug tree-optimization/47316] New: devirtualize calls to virtual methods that are never further overriden
- Auto-submitted: auto-generated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47316
Summary: devirtualize calls to virtual methods that are never
further overriden
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: zsojka@seznam.cz
CC: jamborm@gcc.gnu.org
Created attachment 22984
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22984
testcase
Similiar to PR46043, but the compiler itself can be able to find out there are
cases a virtual method is never overriden.
Maybe this is the original intention of the devirtualization work, but in the
case it is not, I am opening this PR.
It is quite common to have one base class and several derived classes that are
no further derived, and the hierarchy looks roughly like:
class Base {
virtual void f1();
virtual void f2();
virtual void f3();
};
class A : Base {
virtual void f1() { ... this->f3(); ... }
virtual void f2() { ... this->f1(); ... }
};
class B : Base {
virtual void f2() { ... this->f1(); ... }
};
void foo(A *a)
{
... a->f1(); ...
}
In a whole-program mode, if the compiler finds no type/variable is coming from
external calls (where there could be possibly type derived from Base/A/B), all
these cases could be devirtualized.
Attached is a simple testcase that could be devirtualized, but isn't even with:
$ g++ tstdevirt.C -O3 -fwhole-program