On 09/30/2016 11:22 AM, Rainer Orth wrote: > Hi Martin, > >>> the testcase FAILs on Solaris 12 (both SPARC and x86): >>> >>> +FAIL: g++.dg/gcov/pr16855.C -std=gnu++11 gcov: 1 failures in line >>> counts, 0 i >>> n branch percentages, 0 in return percentages, 0 in intermediate format >>> +FAIL: g++.dg/gcov/pr16855.C -std=gnu++11 line 21: is #####:should be 1 >>> +FAIL: g++.dg/gcov/pr16855.C -std=gnu++14 gcov: 1 failures in line >>> counts, 0 i >>> n branch percentages, 0 in return percentages, 0 in intermediate format >>> +FAIL: g++.dg/gcov/pr16855.C -std=gnu++14 line 21: is #####:should be 1 >>> +FAIL: g++.dg/gcov/pr16855.C -std=gnu++98 gcov: 1 failures in line >>> counts, 0 i >>> n branch percentages, 0 in return percentages, 0 in intermediate format >>> +FAIL: g++.dg/gcov/pr16855.C -std=gnu++98 line 21: is #####:should be 1 >>> >>> I haven't looked closer yet, but notice that you require constructor >>> priority support which isn't available everywhere (it is on Solaris 12, >>> but not before). >>> >>> Rainer >>> >> >> Hello. >> >> Sorry for the test-breakage. The issue is really connected to fact that >> current trunk relies >> on support of dtor priority. The former implementation called the function >> __gcov_exit via atexit. >> If I understand correctly, fully support of static ctors/dtors, C++ >> ctors/dtors, with combination >> of atexit cannot be done on a target w/o ctor/dtor priorities. > > understood. However, Solaris 12 *does* have support for constructor > priorities and the testcase still fails, so there's more going on here.
I see, however I don't have access to such a machine. I would appreciate if you help me to debug what's going on. Can you please send me --target=x, so that I can at least check created assembly? > >> Ideally we should have a macro for each target telling whether it supports >> priorities or not. >> However, we probably don't have? I would suggest to make the test >> conditional just for main >> targets which support priorities? >> >> Thoughts? > > While this would take care of the testsuite failures, this creates a > terrible user experience outside of the testsuite: if we know that > -fprofile-arcs -ftest-coverage cannot work on targets without > constructor priority support, the compiler should error out with an > appropriate message instead of just creating confusing non-working > executables. More precisely, it does not work reliably on constructor and destructors as we depend on an order how are ctor/dtors executed. We had the same behavior even before my patch, but documenting that definitely worth for doing. I'll do a patch. Martin > > Rainer >
