On 1/11/19 1:36 PM, Tobias Burnus wrote:
Dear Jason, dear all,
Jason Merrill wrote on 5 Dec 2018:
You can get at the destructor with CLASSTYPE_DESTRUCTOR rather than walking
through TYPE_FIELDS. I'd also check DECL_DEFAULTED_IN_CLASS_P.
I'd also do this in maybe_emit_vtables rather than here, so that it only
happens once per class.
Updated patch. I also added a test case which checks that the destructor
is not generated.
[ Original patch: https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01824.html ]
Background again:
If a class contains any 'virtual ... = 0', it's an abstract class and for an
abstract class, the destructor not added to the vtable.
For a normal
virtual ~class() { }
that's not a problem as the class::~class() destructor will be generated
during
the parsing of the function.
But for
virtual ~class() = default;
the destructor will be generated via mark_used via the vtable.
If one now declares a derived class and uses it, the class::~class() is
generated
in that translation unit. Unless, #pragma interface/implementation is used.
In that case, the 'default' destructor will never be generated.
Build and regtested on x86_64-gnu-linux.
OK? Or do you have more suggested changes?
+ && DECL_DEFAULTED_IN_CLASS_P(CLASSTYPE_DESTRUCTOR(ctype))
+ && DECL_DEFAULTED_FN (CLASSTYPE_DESTRUCTOR(ctype)))
Checking DECL_DEFAULTED_FN again is redundant, it's checked by
DECL_DEFAULTED_IN_CLASS_P. OK with that last condition removed.
Jason
