This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
GCov showing closing braces as not executed between gcc 4.4.4 and 4.6.3
- From: Graeme Bunyan <graeme at opekia dot com>
- To: gcc-help at gcc dot gnu dot org
- Date: Fri, 14 Dec 2012 15:14:11 -0800
- Subject: GCov showing closing braces as not executed between gcc 4.4.4 and 4.6.3
Hi,
The output from gcov (compiled with -g, no optimization) shows some
closing braces as not being highlighted - I've put together a minimal
testcase (attached), and testing this with the other versions of gcc I
have access to, it appears to have been introduced in 4.4.4, and
resolved sometime before 4.6.3. Unfortunately, I'm stuck on 4.4.5 for
at least the next year, so I can't simply switch to a later release to
get the fix. I searched through all of the release notes for gcc since
4.4, and had a look at the bugs fixed in each release in Bugzilla, but
I'm afraid nothing leaps out at me as being the culprit.
I actually used to see this exact same behavior in 4.4.3 and prior iff
the code was compiled with -O, so I'm wondering if maybe some
optimization flag was turned on by default in 4.4.4, and then reverted
sometime before 4.6.3 (in which case, hopefully I can work around it by
supplying a flag to gcc)?
I'd appreciate any help in narrowing down the culprit to a particular
bug report - if it's minor enough, it may be something I can have
integrated into our 4.4.5 builds. Minimally, at least I'll know in
which release this is fixed.
The testcase is fairly straightforward - simply unzip and type 'make',
and it will compile the test with '-g --coverage', run the exe, run gcov
on one of the source files, and cat the output from gcov. The problem
is the closing brace in the constructor:
1: 5:SubClass::SubClass()
-: 6:{
-: 7: // Certain calls within this function result in gcov
-: 8: // reporting the line with the closing brace for this
-: 9: // function as not executed ('#####'). The first two
-: 10: // exhibit the problem, the other two do not.
-: 11:
-: 12: // (Problem) Call static member of another class
-: 13: //UnrelatedClass::unrelatedTestFunction();
-: 14: // (Problem) Call superclass member function
1: 15: superTestFunction();
-: 16: // (Ok) Call member of this class
-: 17: // subTestFunction();
-: 18: // (Ok) Call plain ol' C function
-: 19: // rand();
#####: 20:}
It isn't always a problem - calling a member defined within the same
class (ie. not inherited from a superclass) is fine, as is calling a
non-member C function like rand(). Calling a member of another class,
however - even if it's a superclass of the current class - exhibits the
problem. In the releases I've tested which don't exhibit this bug, this
line shows as executed with the same count as the other lines in the
same function.
Any information on this would be very much appreciated :)
Best regards,
Graeme.
Attachment:
GCovTest.tar.bz2
Description: application/bzip