On the 25th November 2018, schrieb Tobias Burnus wrote:
On 21 November 2018, Tobias Burnus wrote:
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
