[cfe-dev] devirtualisation appears to crash clang on covariant functions on ARM
David Tweed
david.tweed at arm.com
Mon Oct 22 04:28:32 PDT 2012
Hi,
Could someone familiar with the devirtualisation code in clang++ please have
a look at the attached code (which is derived from one of the few remaining
regression test failures on ARM), or suggest who's actively working in the
devirtualisation area please? It's involving the confluence of the following
C++ issues:
1. Replacement of virtual functions with direct calls when the compiler
knows the "actual" type of an pointer-to-object.
2. Use of C++11's final to make-apparent that a pointer must be to the
actual object type, not a parent-class.
3. C++ allows virtual functions to have covariant returns.
4. The ARM ABI specifies destructors return "this" as the final argument.
For virtual derived destructors this means it's a covariant return type.
When I run this on current trunk on x86-64 or with an x86-64 triple
argument, it's able to devirtualise the destructor call in f but not the
covariant function call in g.
On either an actual ARM or with triple armv7-unknown-linux-gnueabi argument
I get a crash due to the module verifier:
Function return type does not match operand type of return inst!
ret %"struct.Test6::D"* %this1
%"struct.Test6::A"*Broken module found, compilation aborted!
It looks like what's happening is that it's correctly figuring out a direct
call to D's destructor, but because of the ABI this function is returning a
D* while some version of the function specification being compared against
is still saying the return type should be A*. For the general covariant
function who() in g, or if I change f to assign d to an A* temporary
variable and call the destructor on that, the ARM code doesn't actually
crash but returns code which isn't devirtualised.
So there's two questions here:
1. Does the devirtualiser work in the presence of covariant returns? If it
doesn't then it's unlikely the devirtualiser will work with destructors when
using the ARM ABI.
2. If it does work (even if covariance prevents devirtualisation), how can
it be stopped from crashing in the verifier in cases like this?
Many thanks for any assistance,
Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: devirtualise-virtual-destructor-calls-final.cpp
Type: application/octet-stream
Size: 713 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121022/bbfe27f7/attachment.obj>
More information about the cfe-dev
mailing list