https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91087
Bug ID: 91087
Summary: g++.dg/gcov/pr16855.C fails everywhere on Darwin.
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
I don't think the test has ever passed on Darwin.
FAIL: g++.dg/gcov/pr16855.C -std=gnu++14 line 21: is #####:should be 1
FAIL: g++.dg/gcov/pr16855.C -std=gnu++14 line 45: is #####:should be 1
(and corresponding fails on other std++ versions)
The analysis is this:
Darwin *does* run the DTORs, but they run before the profile DTORs, and
therefore are not recorded in the output.
Darwin does not support contractor priorities (well. not between TUs unless
LRTO ins enabled).
So two things come into play.
1. The DTOR the c++ class is run before the __attribute__((__destructor__))
^ See below this is a Darwin ABI issue, I think, not a GCC one.
2. Because Darwin is marked as ! SUPPORTS_INIT_PRIORITY, the CTOR and DTOR
priority for the profile are set to default.
so we get this:
.mod_init_func
.long __ZL12ctor_defaultv <<== calls the attribute ctor case.
.long __GLOBAL__sub_I_pr16855.C <<== calls
__Z41__static_initialization_and_destruction_0ii
(which registers the static c++ DTOR onto cxa-atexit.)
.long __GLOBAL__sub_I_65535_0_pr16855.C <<== calls gcov_init
and this...
in constructor(())
In Test::Test
>> profile CTOR
In main
In foo
>> profile DTOR
in destructor(())
In Test::~Test
So it happens that the statics for the first two vars are incremented
*and it's not obvious that the profile CTOR hasn't run then*
but the DTOR (which writes the output) runs before the static DTORs.
=====
So SysV ABI says: This (SysV spec) is not the current situation on Darwin-based
systems, where it appears that the __DATA,__mod_term_.func functions are
executed _before_ the ones registered via atexit.
I have asked on the Darwin dev list, and directly to the Apple ABI chap if
there's a written statement of the ABI for Darwin - posix seems to be silent
about the relationship between atexit and other static DTORs.
=====
In the meantime.
(a) If the profile code depends on SUPPORTS_INIT_PRIORITY for correct
operation, there's no point in setting it to DEFAULT_INIT_PRIORITY for targets
that don't support between TUs - we might as well leave it at the intended -
and at least it will get correct ordering within one TU.
(b) If I do (a) and build the code with -fno-use-cxa-atexit, then Darwin passes
the test .. but I need an answer on the formal ABI.
** back in the Darwin9 day, with Apple gcc-4.x, the nesting of CTOR/DTOR was as
expected, so I'm not sure....
