Hello all,

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.


The following code seems to work both for the big code and for the example;
without '#pragma implementation', the destructor is not generated for the example,
only with.

The patch survived boostrapping GCC with default languages on x86-64-gnu-linux
and "make check-g++".*

[One probably could get rid of some of the conditions for generating the code,
e.g. TREE_USED and DECL_DEFAULTED_FN are probably not both needed; one might
want to set some additional DECL to the fn decl.]

Does the patch and the test case make sense? Or is something else/in addition
needed?

Tobias


*I do get the following failures on this CentOS6 system:

FAIL: g++.dg/pr83239.C  -std=gnu++98 (test for excess errors)
Excess errors:
cc1plus: warning: 'void* __builtin_memset(void*, int, long unsigned int)' specified size 18446744073709551608 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]
cc1plus: warning: 'void* __builtin_memset(void*, int, long unsigned int)' specified size 18446744073709551600 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]

FAIL: g++.dg/tls/thread_local-order2.C  -std=c++14 execution test
FAIL: g++.dg/tls/thread_local-order2.C  -std=c++17 execution test

plus each 32 times:
FAIL: guality/guality.h: 0 PASS, 1 FAIL, 0 UNRESOLVED
FAIL: guality/guality.h: varl is -1, not 6