> > 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 <ja...@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, also if abstract_class_dtor_p functions are never called via vtables, is there reason for C++ FE to put them there? I understand that there is a slot in vtable initializer for them, but things would go smoother if it was initialized to NULL or some other marker different from cxa_pure_virtual. Then gimple-fold will already substitute it for builtin_unreachable and they will get ignored during the ipa-devirt's walks. Honza
