This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcov: option to instrument whole basic block graph, no use of spanning tree optimization

Hello Holger,

here's a syntactic-only review:

* Holger Blasum wrote on Mon, Nov 08, 2010 at 03:28:12PM CET:
> --- gcc/doc/gcov.texi	(revision 166172)
> +++ gcc/doc/gcov.texi	(working copy)
> @@ -512,6 +512,32 @@
>  coverage of all the uses of the inline function will be shown for the
>  same source lines, the line counts themselves might seem inconsistent.
> +@node Overflow
> +@section Counter Overflow 

Trailing white space; several instances.

> +Counters are implemented as a 64-bit value which means that overflow 
> +would occur only after @math{2^64} times of stepping through a program path. 

@math{2^{64}}, otherwise only the 6 is superscripted.

> +Overflow usually can be ruled out by ascertaining that coverage
> +run time times CPU speed is less than @math{2^64}.


> +@node Multithreaded Programs
> +@section Collecting Coverage Data of Multithreaded Programs 

A new section needs to appear in some menu, no?

> +As the implementation of threads and context switching depends on 
> +the operational environment, it is hard to implement a truly portable 
> +coverage for multithreaded programs at the compiler level. So 

Two spaces after end-of-sentence period; several instances.

> +@command{gcov} will not be faithful in multithreaded programs. If, 
> +during compilation, the additional option @samp{-fprofile-whole-graph} 


> +is specified then @command{gcov} will use a representation of 

comma after specified

> +the whole basic block graph instead of the otherwise optimal
> +spanning tree optimization. That means that the compiled program 
> +will use more memory but is more robust than when the spanning tree
> +optimization is used. In the absence of counter overflow that 
> +implies that coverage in multithreaded programs is conservatively 
> +estimated: it may be underreported but in particular this option 
> +ensures that a non-zero coverage value means that the path has been 
> +taken and conversely that if a path has been taken the coverage value 
> +is non-zero. (This property still can be useful if one wants test 
> +coverage.) 
> +
>  @c man end
>  @node Gcov Data Files


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]