[cfe-dev] Remove code coverage counter for "empty" lines

Calixte Denizet via cfe-dev cfe-dev at lists.llvm.org
Wed Oct 10 10:16:54 PDT 2018


@reid, Currently, the GCNO/GCDA format are the same as in gcc 4.2 (
https://llvm.org/docs/CommandGuide/llvm-cov.html)
So adding extra data will break the compatibility with gcc 4.2.

@vedant, an example of what we've currently with a code similar to yours:
-:    0:Source:d.c
-:    0:Graph:d.gcno
-:    0:Data:d.gcda
-:    0:Runs:1
-:    0:Programs:1
-:    1:int foo(int x) {
3:    2:    if (x == 0) {
1:    3:       return 1;
2:    4:    } else if (x == 1) {
1:    5:       return 2;
-:    6:    }
-:    7:
1:    8:   return 3;
3:    9:}
-:   10:
-:   11:int main(int argc, char ** argv) {
1:   12:    foo(0);
1:   13:    foo(1);
1:   14:    foo(2);
-:   15:
1:   16:    return 3;
-:   17:}

I'm not sure that the 3 on line 9 is so useful because finally it relies on
how it's implemented behind (in the IR we only have one final ret
instruction).
>From my point of view, a code coverage report should be easily
understandable (I mean no need to do maths) and not rely on compiler
details.
I agree with you on the fact that having two modes is painful and from my
point of view when I made this patch (reverted) in clang, I had the impress
to fix a bug and not to add a feature.
So what could we do to go ahead ?


Le lun. 1 oct. 2018 à 23:14, Reid Kleckner <rnk at google.com> a écrit :

> I have no understanding of any of the file formats involved, but it seems
> like it would be the kind of thing we'd record in the information about the
> source location, and then the tool that generates text or HTML can display
> it how it likes at the end. That's why I support putting the info in the
> LLVM IR format, since we'll need to track the bit through instrumentation.
>
> If the file format is too hard to extend, then I wouldn't mind adding an
> extra option for people who want to tweak our instrumentation.
>
> On Wed, Sep 26, 2018 at 3:10 PM Vedant Kumar <vsk at apple.com> wrote:
>
>> Hi,
>>
>> On Sep 25, 2018, at 12:46 PM, David Blaikie <dblaikie at gmail.com> wrote:
>>
>> (+ a few folks who've been involved in the reviews, etc)
>>
>> On Mon, Sep 24, 2018 at 12:34 PM Calixte Denizet via cfe-dev <
>> cfe-dev at lists.llvm.org> wrote:
>>
>>> Hi,
>>>
>>> When making code coverage, there are some counters on closing braces.
>>> In some case it's due to "return void" with a debugloc corresponding to
>>> '}' (see line 4) or due to cleanup stuff put at the end of a scope (see
>>> line 20, aaa's dtor is called).
>>> Especially with c++, some "implicit" code (i.e. not written explicitly
>>> by the user) could be added at the beginning of a scope and at the end.
>>> Here are two example of outputs produced by clang and gcc.
>>>
>>> With clang 7:
>>> -:    1:struct A {
>>> -:    2:
>>> 1:    3:    A() {}
>>> -:    4:
>>> -:    5:    ~A() {
>>> 1:    6:    }
>>> -:    7:};
>>> -:    8:
>>> -:    9:void foo(int K) {
>>> 1:   10:}
>>> -:   11:
>>> -:   12:int main() {
>>> 1:   13:    A aaa;
>>> 1:   14:    int x = 1;
>>> 1:   15:    foo(x);
>>> 1:   16:    x = x + 2;
>>> -:   17:
>>> 1:   18:    return x;
>>> 1:   19:}
>>>
>>> With gcc 8:
>>> -:    1:struct A {
>>> -:    2:
>>> 1:    3:    A() {}
>>> -:    4:
>>> 1:    5:    ~A() {
>>> 1:    6:    }
>>> -:    7:};
>>> -:    8:
>>> 1:    9:void foo(int K) {
>>> 1:   10:}
>>> -:   11:
>>> 1:   12:int main() {
>>> 1:   13:    A aaa;
>>> 1:   14:    int x = 1;
>>> 1:   15:    foo(x);
>>> 1:   16:    x = x + 2;
>>> -:   17:
>>> 1:   18:    return x;
>>> -:   19:}
>>>
>>> So I'd like to have coverage for lines which contain only "explicit"
>>> code to have a clear information to give to different kinds of people (I
>>> spent myself some time to understand why I had coverage on line like "} //
>>> namespace foo”).
>>>
>>
>> Makes sense, although I’ll note that there are cases where hiding
>> coverage stats on closing braces might be doing a disservice, like:
>>
>> void foo() {
>>   if (…)
>>     return;
>>   if (…)
>>     return;
>> } //< The coverage here might be interesting if you care about how often
>> you don’t return early.
>>
>> You can figure it out by subtracting the coverage counts on return
>> statements from the function entry count, but that’s work the coverage tool
>> could do for you.
>>
>> So we could add an option in clang (no idea of the name right now) to
>>> allow user to have coverage for explicit code.
>>>
>>
>> I’d rather not have a flag to control this behavior. I imagine that most
>> users of a coverage tool will never change its default behavior. From a
>> maintenance perspective, it’s easier to test one coverage mode than two.
>>
>> You’re making a compelling argument that hiding coverage stats on
>> implicit code is the right thing to do (if for no other reason than “it’s
>> what gcc does”). If most others agree with you, I’d rather have such a
>> change made unconditionally even though it’s not my personal preference.
>>
>> Just my 2 cents — happy to defer to others maintaining/using gcov.
>>
>> thanks,
>> vedant
>>
>>
>> And so have this output:
>>> -:    1:struct A {
>>> -:    2:
>>> 1:    3:    A() {}
>>> -:    4:
>>> 1:    5:    ~A() {
>>> -:    6:    }
>>> -:    7:};
>>> -:    8:
>>> 1:    9:void foo(int K) {
>>> -:   10:}
>>> -:   11:
>>> 1:   12:int main() {
>>> 1:   13:    A aaa;
>>> 1:   14:    int x = 1;
>>> 1:   15:    foo(x);
>>> 1:   16:    x = x + 2;
>>> -:   17:
>>> 1:   18:    return x;
>>> -:   19:}
>>>
>>> Calixte
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181010/b53dcd26/attachment-0001.html>


More information about the cfe-dev mailing list