RFA: New ipa-devirt PATCH for c++/58678 (devirt vs. KDE)

[Jan Hubicka]

> This patch fixes the latest 58678 testcase by avoiding speculative
> devirtualization to the destructor of an abstract class, which can
> never succeed: you can't create an object of an abstract class, so
> the pointer must point to an object of a derived class, and the
> derived class necessarily has its own destructor.  Other virtual
> member functions of an abstract class are OK for devirtualization:
> the destructor is the only virtual function that is always
> overridden in every class.
> 
> We could also detect an abstract class by searching through the
> vtable for __cxa_pure_virtual, but I figured it was easy enough for
> the front end to set a flag on the BINFO.
> 
> Tested x86_64-pc-linux-gnu.  OK for trunk?

> commit b64f52066f3f4cdc9d5a30e2d48aaf6dd5efd3d4
> Author: Jason Merrill <jason@redhat.com>
> Date:   Wed Mar 5 11:35:07 2014 -0500
> 
>     	PR c++/58678
>     gcc/
>     	* tree.h (BINFO_ABSTRACT_P): New.
>     	* ipa-devirt.c (abstract_class_dtor_p): New.
>     	(likely_target_p): Check it.
>     gcc/cp/
>     	* search.c (get_pure_virtuals): Set BINFO_ABSTRACT_P.
>     	* tree.c (copy_binfo): Copy it.

Jason, I was looking into this and I think I have patch that works.  I would
just like to verify I inderstnad things right.  First thing I implemented is to
consistently skip dtors of abstract classes as per the comment in
abstract_class_dtor_p there is no way to call those by virtual table pointer.
Unlike your patch it will i.e. enable better unreachable code removal since
they will not appear in possible target lists of polymorphic calls.

The second change I did is to move methods that are reachable only
via abstract class into the part of list that is in construction,
since obviously we do not have instances of these classes.
I do not think it is too important (and it needs bit of changes in the
walk), but it is better to be correct here so we avoid further problems
where the ipa-devirt digs out target that is in fact not possible.

What I would like to verify with you shtat I also changed walk when looking
for destructors to not consider types in construction. I believe there is no way
to get destructor call via construction vtable as we always know the type.
Is that right?

Honza