[Bug gcov-profile/96622] New: gcov misses to count break statement

[Bug gcov-profile/96622] New: gcov misses to count break statement

[roland.illig at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96622

            Bug ID: 96622
           Summary: gcov misses to count break statement
           Product: gcc
           Version: 10.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: gcov-profile
          Assignee: unassigned at gcc dot gnu.org
          Reporter: roland.illig at gmx dot de
                CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 49064
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49064&action=edit
demonstration project

Run gcov on the attached project.
Examine the coverage count of the break statement.
It should be 1, but is '-'.

[Bug gcov-profile/96622] gcov misses to count break statement

[roland.illig at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96622

--- Comment #1 from Roland Illig <roland.illig at gmx dot de> ---
In my own code coverage measurer for Go programs, I took the approach of
creating a coverage counter for every true and false branch of a boolean
condition.

https://github.com/rillig/gobco/blob/6be01424/instrumenter.go#L126

I had expected gcov to work in the same way, but it seems to me that gcov takes
a different approach.

Or is it that the break statement is converted to a direct jump too early to be
seen by the --coverage option, discarding the basic block for it?  That reminds
me of what I consider a bug in the OpenJDK Java compiler (as well as the
Eclipse Java compiler):

https://mail.openjdk.java.net/pipermail/compiler-dev/2020-February/014290.html

[Bug gcov-profile/96622] gcov misses to count break statement

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96622

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
Please use -O0 for more precise gcov instrumentation:

        -:    0:Source:my_strndup.c
        -:    1:#include <assert.h>
        -:    2:#include <stdlib.h>
        -:    3:#include <string.h>
        -:    4:
        3:    5:void *my_strndup(const char *s, size_t n)
        -:    6:{
        3:    7:    size_t len = 0;
       23:    8:    for (len = 0; len < n; len++)
       22:    9:        if (s[len] == '\0')
        2:   10:            break;
        -:   11:
        3:   12:    char *p = malloc(len + 1);
       3*:   13:    assert(p);
        -:   14:
        3:   15:    memcpy(p, s, len);
        3:   16:    p[len] = '\0';
        -:   17:
        3:   18:    return p;
        -:   19:}

[Bug gcov-profile/96622] gcov misses to count break statement

[roland.illig at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96622

--- Comment #3 from Roland Illig <roland.illig at gmx dot de> ---
Ah, thanks for the pointer.

I thought I had used -O0 in the larger project as well, but I hadn't.

Just as a suggestion, would it make sense to apply the coverage at the source
code level (before any optimizations) instead of optimizing first and then
adding the counters?  It would feel more predictable to me.

https://gcc.gnu.org/onlinedocs/gcc/Gcov-Intro.html#Gcov-Intro

At least for the "discover untested parts of your program", that would make
sense to me since in my code, the "break" statement has an effect, independent
of any optimization level.

https://gcc.gnu.org/onlinedocs/gcc/Invoking-Gcov.html#Invoking-Gcov

In this section, the string "tim" occurs often, but only in "number of times",
"each time", but not in "measured wall time".  Therefore I think gcov is more
about counting that about measuring time.

[Bug gcov-profile/96622] gcov misses to count break statement

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96622

--- Comment #4 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Roland Illig from comment #3)
> Ah, thanks for the pointer.
> 
> I thought I had used -O0 in the larger project as well, but I hadn't.
> 
> Just as a suggestion, would it make sense to apply the coverage at the
> source code level (before any optimizations) instead of optimizing first and
> then adding the counters?  It would feel more predictable to me.

Note that it's not possible as some optimizations happen in folding even in
front-end. Intrumentation happens as soon as possible in optimization pipeline.