[LLVMbugs] [Bug 22084] New: gcov coverage data produced by clang is different from corresponding data produced by gcc

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=22084

            Bug ID: 22084
           Summary: gcov coverage data produced by clang is different from
                    corresponding data produced by gcc
           Product: new-bugs
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: simon.gardener at arcor.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13621
  --> http://llvm.org/bugs/attachment.cgi?id=13621&action=edit
test.cpp, test.sh

Consider the C++ program 'test.cpp':

int foo()
{
   return 0;
}

int main()
{
   foo();
}

We are generating and comparing coverage data using g++ and clang++ together
with gcov:

g++ --coverage test.cpp:

        -:    0:Source:test.cpp
        -:    0:Graph:test.gcno
        -:    0:Data:test.gcda
        -:    0:Runs:1
        -:    0:Programs:1
function _Z3foov called 1 returned 100% blocks executed 100%
        1:    1:int foo()
        -:    2:{
        1:    3:   return 0;
        -:    4:}
        -:    5:
function main called 1 returned 100% blocks executed 100%
        1:    6:int main()
        -:    7:{
        1:    8:   foo();
call    0 returned 100%
        1:    9:}


clang++ --coverage -Xclang -coverage-cfg-checksum -Xclang
-coverage-no-function-names-in-data -Xclang -coverage-version='409*':

        -:    0:Source:test.cpp
        -:    0:Graph:test.gcno
        -:    0:Data:test.gcda
        -:    0:Runs:0
        -:    0:Programs:1
function _Z3foov called 1 returned 100% blocks executed 100%
        -:    1:int foo()
        -:    2:{
        1:    3:   return 0;
        -:    4:}
        -:    5:
function main called 1 returned 100% blocks executed 100%
        -:    6:int main()
        -:    7:{
        1:    8:   foo();
        1:    9:}


diff:

4c4
<         -:    0:Runs:1
---
>         -:    0:Runs:0
7c7
<         1:    1:int foo()
---
>         -:    1:int foo()
13c13
<         1:    6:int main()
---
>         -:    6:int main()
16d15
< call    0 returned 100%


Particularly, function heads are considered as covered lines of code when using
gcc but not when using clang.

Practical problem: lcov seems to rely on gcc-style. Generating initial zero
coverage data using 'lcov -c -i' considers function heads. This leads to wrong
results when combined with actual clang-style coverage data which does not
consider function heads.

Above data can be reproduced using the script 'test.sh' contained in the
attached archive.

Output of 'test.sh' on my machine:

g++ (GCC) 4.9.2 20141224 (prerelease)
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


clang version 3.5.0 (tags/RELEASE_350/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix

gcov (GCC) 4.9.2 20141224 (prerelease)
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or 
FITNESS FOR A PARTICULAR PURPOSE.


File 'test.cpp'
Lines executed:100.00% of 5
No branches
Calls executed:100.00% of 1
Creating 'test.cpp.gcov'

test.gcno:'_Z3foov' has arcs from exit block
test.gcno:'main' has arcs from exit block
File 'test.cpp'
Lines executed:100.00% of 3
No branches
No calls
Creating 'test.cpp.gcov'

4c4
<         -:    0:Runs:1
---
>         -:    0:Runs:0
7c7
<         1:    1:int foo()
---
>         -:    1:int foo()
13c13
<         1:    6:int main()
---
>         -:    6:int main()
16d15
< call    0 returned 100%

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20150103/6a4b6e27/attachment.html>