This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcov questions
- From: Nathan Sidwell <nathan at codesourcery dot com>
- To: Ed Swierk <eswierk at cs dot stanford dot edu>
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 13 Aug 2003 09:26:45 +0100
- Subject: Re: gcov questions
- Organization: Codesourcery LLC
- References: <Pine.LNX.4.56.0308121752500.3463@localhost.localdomain>
Ed Swierk wrote:
Hello,
A few questions:
(1) A while back, I hacked up gcov to generate coverage statistics for
multiple source files simultaneously. Unfortunately the version I hacked
up is fairly old (3.2.3), but I thought others might still find it useful.
Where would be an appropriate place to post such a patch?
here.
(2) Eventually I would like to migrate to a more recent version of gcc.
I understand there were major changes in gcov in the 3.3 release, and a
perusal of the CVS archives reveals more recent changes to gcov. Is there
a summary of recent gcov development activity, or features that are
expected to be included in the 3.4 release?
no. There were some changes in 3.3 then the file format was completely
redesigned for 3.4. I should probably write one ...
(3) The codebase on which I am running gcov is mostly C++ code that makes
heavy use of member functions defined inline within class definitions.
Even when compiling in debug mode with no optimizations, I find that code
is not generated for such member functions if the compiler sees that they
are unused, and as a result those functions are not included in the
coverage statistics.
it should still produce counts information for the lines of the inlined
function based on their execution where they have been inlined. But you are
right that there is no summary for those functions. Could you file a bug
report about that so we don't forget -- it might be possible to do something
As a workaround, I compile with the -fno-default-inline flag. However,
this causes ld to fail unless I rebuild my entire codebase, including any
C++ libraries, with the same compiler flag. Unfortunately some of those
libraries themselves do not compile with that flag.
wouldn't -fno-inline be the right thing? I don't immediately see why either
option would cause the problem your describe.
nathan
--
Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery LLC
The voices in my head said this was stupid too
nathan@codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk