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

[David Tweed]

Just finished a an ARM native rebuild and retested and can confirm the test
now passes. Thanks for fixing.

-----Original Message-----
From: John McCall [mailto:rjmccall at apple.com] 
Sent: 25 October 2012 01:21
To: Eli Friedman
Cc: David Tweed; Rafael Espíndola; cfe-dev at cs.uiuc.edu
Subject: Re: [cfe-dev] devirtualisation appears to crash clang on covariant
functions on ARM

On Oct 24, 2012, at 5:15 PM, Eli Friedman wrote:
> On Wed, Oct 24, 2012 at 12:24 AM, David Tweed <david.tweed at arm.com> wrote:
>> | 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.

Thank you.

John.