g++ -std=c++11 -c -o t.o -x c++ - << EOF struct Bar final { Bar(); }; Bar::Bar() {} EOF nm t.o gives: 0000000000000000 T _ZN3BarC1Ev 0000000000000000 T _ZN3BarC2Ev '_ZN3BarC2Ev' is the "base object constructor" and can never be called for 'final' classes, AFAICS.
Maybe the ABI mandates these nevertheless.
(In reply to Richard Biener from comment #1) > Maybe the ABI mandates these nevertheless. Right, the ABI doesn't say anything about final classes. Note that the extra symbol is only an alias; there aren't two function definitions taking up space.
Well, my real problem is related to coverage analysis. Function coverage will show the base object constructor as not called. But my concrete test case is more complex and involves virtual functions and inheritance. Might me that an alias is not enough in the real code. A different solution to my problem might be to exclude the base object constructor from coverage analysis. A related problem: I also have a class that is always used as a base class and will never be constructed directly (because it has pure virtual functions). The "complete object constructor" is emitted nevertheless. But function coverage marks it as never called.
Author: jason Date: Wed Jun 26 04:56:07 2019 New Revision: 272669 URL: https://gcc.gnu.org/viewcvs?rev=272669&root=gcc&view=rev Log: PR c++/70462 - unnecessary base ctor variant with final. As pointed out in the PR, we don't need base 'tor variants for a final class, since it can never be a base. I tried also dropping complete variants for abstract classes, but that runs into ABI compatibility problems with older releases that refer to those symbols. * optimize.c (populate_clone_array): Skip base variant if CLASSTYPE_FINAL. (maybe_clone_body): We don't need an alias if we are only defining one clone. Added: trunk/gcc/testsuite/g++.dg/other/final8.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/optimize.c
Fixed for GCC 10.
This does introduce an ABI incompatibility. I'm seeing this with kuduraft-1.8 compiled with GCC 10, giving linker errors from clang 9.0.20190721 like: error: undefined symbol: kudu::consensus::OpId::OpId() Reverting this patch fixes the issue here.
(In reply to Pádraig Brady from comment #6) > This does introduce an ABI incompatibility. > > I'm seeing this with kuduraft-1.8 compiled with GCC 10, giving linker errors > from clang 9.0.20190721 like: > > error: undefined symbol: kudu::consensus::OpId::OpId() > > Reverting this patch fixes the issue here. I second that. A library built with gcc10 is not linking with a program built with clang. Why would clang not call the complete class constructor, though?
Let's keep that discussion in PR 95428 rather than in a resolved bug.
Because of PR 95428, it's necessary to emit the unreachable definition of the base variant, so I've reverted the fix.