public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* Question about the coverage statistics of Gcov
@ 2021-04-02  8:50 heng zhang
  2021-04-02 23:15 ` Jim Wilson
  0 siblings, 1 reply; 5+ messages in thread
From: heng zhang @ 2021-04-02  8:50 UTC (permalink / raw)
  To: gcc-help

$./gcc -v                                                                                                                                                                    
使用内建 specs。
COLLECT_GCC=./gcc
COLLECT_LTO_WRAPPER=/home/x/project/gcc/build/install/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target:x86_64-pc-linux-gnu
Configured:../configure --prefix=/home/x/project/gcc/build/install --enable-checking=release --enable-languages=c,c++ --disable-multilib
thread model:posix
Supported LTO compression algorithms: zlib
gcc 版本 11.0.0 20210105 (experimental) (GCC)

$./gcov -v                                                                                                                                                                   
gcov (GCC) 11.0.0 20210105 (experimental)
Copyright © 2021 Free Software Foundation, Inc.

$gcc -O0 --coverage test.c;./a.out;gcov test;cat test.c.gcov
  1        -:    0:Source:test.c
  2         -:    0:Graph:test.gcno
  3         -:    0:Data:test.gcda                                                                                                                                                
  4         -:    0:Runs:1
  5         -:    1:#include <stdio.h>
  6         -:    2:
  7         -:    3:
  8         1:    4:static int fun()
  9         -:    5:{
 10         1:    6:     float a = 0x1.9p+1;
 11         1:    7:     int b = 0xA20B95AEL;
 12        1*:    8:     for(int i=0;i<2;i++)
 13         -:    9:     {
 14         1:   10:         int c = 4;
 15         1:   11:         if(a>0)
 16         1:   12:             return 4;
 17         -:   13:     }
 18 #####:   14:     return 1;
 19         -:   15:}
 20         1:   16:int main()
 21         -:   17:{
 22         1:   18:    int result=fun();
 23         1:   19:    printf("%d \n",result);
 24         1:   20:    return 0;
 25         -:   21:}
 26         -:   22:

Why is the executed time of the 8th line performed 1* and what does the symbol ‘*' means?  According to the explanation of the official web,  executed basic blocks having a statement with zero execution_count end with ‘*’ character. For this case, there is not any unexecuted statement in for loop. When the 11th line is pruned, the executed time of the 8th line is only 1. so is it a bug? 

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Question about the coverage statistics of Gcov
  2021-04-02  8:50 Question about the coverage statistics of Gcov heng zhang
@ 2021-04-02 23:15 ` Jim Wilson
  2021-04-06 15:34   ` heng zhang
  0 siblings, 1 reply; 5+ messages in thread
From: Jim Wilson @ 2021-04-02 23:15 UTC (permalink / raw)
  To: heng zhang; +Cc: gcc-help

On Fri, Apr 2, 2021 at 1:50 AM heng zhang via Gcc-help <gcc-help@gcc.gnu.org>
wrote:

> Why is the executed time of the 8th line performed 1* and what does the
> symbol ‘*' means?  According to the explanation of the official web,
> executed basic blocks having a statement with zero execution_count end with
> ‘*’ character. For this case, there is not any unexecuted statement in for
> loop. When the 11th line is pruned, the executed time of the 8th line is
> only 1. so is it a bug?


The line
 12        1*:    8:     for(int i=0;i<2;i++)
is effectively more than one piece of code.  One of those pieces of code
wasn't executed.  If you put a newline after every ; and rerun gcov, the
results may make more sense.  But exactly attributing counts for some
complex statements like a for loop header is tricky, so it may always be a
little misleading.  Better is to just use the counts of the statements
inside the block and not worry about the for loop header.

Jim

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Question about the coverage statistics of Gcov
  2021-04-02 23:15 ` Jim Wilson
@ 2021-04-06 15:34   ` heng zhang
  2021-04-07 20:35     ` Jim Wilson
  0 siblings, 1 reply; 5+ messages in thread
From: heng zhang @ 2021-04-06 15:34 UTC (permalink / raw)
  To: Jim Wilson; +Cc: gcc-help

Thank your reply! 

I have modified my code.As shown below:
  1         -:    0:Source:test_o.c
  2         -:    0:Graph:test_o.gcno
  3         -:    0:Data:test_o.gcda
  4         -:    0:Runs:1
  5         -:    1:#include <stdio.h>
  6         -:    2:
  7         -:    3:
  8         1:    4:static int fun()
  9         -:    5:{
 10         1:    6:     float a = 0x1.9p+1;
 11         1:    7:     int b = 0xA20B95AEL;
 12         1:    8:     for(int i=0;i<2;i++)
 13         -:    9:     {
 14         1:   10:         int c = 4;
 15         1:   11:         return 4;
 16         -:   12:     }
 17     #####:   13:     return 1;
 18         -:   14:}
 19         1:   15:int main()
 20         -:   16:{
 21         1:   17:    int result=fun();
 22         1:   18:    printf("%d \n",result);
 23         1:   19:    return 0;
 24         -:   20:}
 25         -:   21:

As you said, the 8th line has some unexecuted parts, i.e., “ i++ ” so why is not the execution time of the 8th line 1*?

> 在 2021年4月3日,上午7:15,Jim Wilson <jimw@sifive.com> 写道:
> 
> On Fri, Apr 2, 2021 at 1:50 AM heng zhang via Gcc-help <gcc-help@gcc.gnu.org <mailto:gcc-help@gcc.gnu.org>> wrote:
> Why is the executed time of the 8th line performed 1* and what does the symbol ‘*' means?  According to the explanation of the official web,  executed basic blocks having a statement with zero execution_count end with ‘*’ character. For this case, there is not any unexecuted statement in for loop. When the 11th line is pruned, the executed time of the 8th line is only 1. so is it a bug?
> 
> The line 
>  12        1*:    8:     for(int i=0;i<2;i++)
> is effectively more than one piece of code.  One of those pieces of code wasn't executed.  If you put a newline after every ; and rerun gcov, the results may make more sense.  But exactly attributing counts for some complex statements like a for loop header is tricky, so it may always be a little misleading.  Better is to just use the counts of the statements inside the block and not worry about the for loop header.
> 
> Jim
> 


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Question about the coverage statistics of Gcov
  2021-04-06 15:34   ` heng zhang
@ 2021-04-07 20:35     ` Jim Wilson
  2021-04-09  5:35       ` heng zhang
  0 siblings, 1 reply; 5+ messages in thread
From: Jim Wilson @ 2021-04-07 20:35 UTC (permalink / raw)
  To: heng zhang; +Cc: gcc-help

On Tue, Apr 6, 2021 at 8:34 AM heng zhang <byone.heng@gmail.com> wrote:

> As you said, the 8th line has some unexecuted parts, i.e., “ i++ ” so why
> is not the execution time of the 8th line 1*?
>

The process of mapping source lines to object file basic blocks and back
again is very complicated, depends on compiler optimizations and the source
code, and we don't always do a perfect job of it.  The gcov output should
always be considered reasonable estimates.  If you want better answers, try
lowering the optimization level, or adding more newlines to your code so
you have fewer statements on each source line.

Jim

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Question about the coverage statistics of Gcov
  2021-04-07 20:35     ` Jim Wilson
@ 2021-04-09  5:35       ` heng zhang
  0 siblings, 0 replies; 5+ messages in thread
From: heng zhang @ 2021-04-09  5:35 UTC (permalink / raw)
  To: Jim Wilson; +Cc: gcc-help



> 在 2021年4月8日,上午4:35,Jim Wilson <jimw@sifive.com> 写道:
> 
> On Tue, Apr 6, 2021 at 8:34 AM heng zhang <byone.heng@gmail.com <mailto:byone.heng@gmail.com>> wrote:
> As you said, the 8th line has some unexecuted parts, i.e., “ i++ ” so why is not the execution time of the 8th line 1*?
> 
> The process of mapping source lines to object file basic blocks and back again is very complicated, depends on compiler optimizations and the source code, and we don't always do a perfect job of it.  The gcov output should always be considered reasonable estimates.  If you want better answers, try lowering the optimization level, or adding more newlines to your code so you have fewer statements on each source line.
 
Actually, I am testing the latest gcov and want to confirm whether this situation is a bug. I don't optimize my program(-O0) when compiling it. The gcov output makes me confused. So Don't you think it is a bug? It is a feature?

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2021-04-09  5:35 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-02  8:50 Question about the coverage statistics of Gcov heng zhang
2021-04-02 23:15 ` Jim Wilson
2021-04-06 15:34   ` heng zhang
2021-04-07 20:35     ` Jim Wilson
2021-04-09  5:35       ` heng zhang

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).