[cfe-dev] devirtualisation appears to crash clang on covariant functions on ARM

[Eli Friedman]

On Wed, Oct 24, 2012 at 12:24 AM, David Tweed <david.tweed at arm.com> wrote:
> Hi,
>
> | Killing all frontend devirtualization of destructors is a bit
> over-the-top.
>
> | Note that we shouldn't actually need a conversion here because, while
> | destructors do generally return 'this', the correctness of that return
> value
> | is not guaranteed for *virtual* destructor calls, basically so that we
> don't
> | have to thunk them just to maintain this optimization.  So I'd like to
> know
> | what's actually introducing a dependence on the return value.
>
>
> To recap what's happening: on a platform using the ARM ABI (at least a linux
> version) that test is crashing clang due to an assertion in the module
> verifier. I don't understand exactly what's happening, but the error message
> from the verifier (which can be obtained running the test on x86 with the
> -triple armv7l-unknown-linux-gnueabihf)
>
> Function return type does not match operand type of return inst!
>   ret %"struct.Test6::D"* %this1
>  %"struct.Test6::A"*Broken module found, compilation aborted!
>
> is to do with matching up return instruction types and type signature return
> types is seeing a D* (derived class) returned where it wants an A* (parent
> class). What I don't know is "which" signature this is: there'd be other
> breakage everywhere if the actual D's destructor had a wrong type, so I'm
> thinking it's either the signature of the method apparently being called
> (A's specific destructor which returns an A*), or some sort of
> combined-signature for the virtual function as a whole. Single stepping
> through, _at the point the devirtualisation decision is taken_ both
> functions have the return type code for void (as they would in "generic
> C++") so the devirtualisation decision gets taken.
>
> In terms of what to do: I'm of the opinion that having code that can crash
> the compiler is not a good behaviour. However, I lack the expertise to
> resolve the underlying problem here properly in the time I've got allocated.
> Suppressing devirtualisation of destructors _only when using the ARM CXXABI_
> (which I've got a patch to do) at least stops the compiler crashing, and so
> would be my preferred intermediate solution. But I'm very open to other
> ideas or ways to improve the situation on the ARM platform for this case.

r166651.

-Eli