lcov does not report files with 0% coverage

[hramrach]

If a piece of code is not executed there is no .gcda file.

This means that the coverage is 0% but the file is not included in the report at all.

[henry2cox]

Yes. You got it. If your executable is not executed at least once - then no .gcda files (runtime coverage information) are generated, and there is nothing for lcov to report. Similarly, if your object file is not included in your executable (...the linker discovered it was not needed) - then there will be no data produced for that compilation unit.

This isn't a bug; this is how the coverage tools work. I'm not quite sure what you would like to see happen.

You can try the lcov --initial flag which will try to process the .gcno files (compile time coverage data) - and will mark all coverpoints as 'not hit'. I can't remember if this is supported for only certain gcc/llvm versions.

[hramrach]

This isn't a bug; this is how the coverage tools work. I'm not quite sure what you would like to see happen.

To report the test coverage. In particular to not inflate the coverage numbers by auto-excluding files not tested at all.

You can try the lcov --initial flag which will try to process the .gcno files (compile time coverage data) - and will mark all coverpoints as 'not hit'. I can't remember if this is supported for only certain gcc/llvm versions.

It does list all the files but does not make any difference. Perhaps at the capture time the captured data overwrites the initial data unless some other special option is used.

In any case all this sounds quite redundant. The gcno files do not go anywhere, they are still there for the capture step, except lcov is like "I know this file was not tested but I will not include in the report because I feel like it". There are options to exclude files that are intentionally not tested, I don't see any need for this auto-exclude of files that were not tested, perhaps by accident or test design problem.

[henry2cox]

Two suggestions:

• you are asking for free help from volunteers. Civility/politeness goes a long way.
• a testcase as well as a description of your environment (platform, compiler version, perl version, lcov version, etc) would help. When I try this locally (gcc/10.2.0, fairly generic linux), it appears to do what I expect

You can also take a look at llvm-cov - and see if its lcov-format output contains what you want. Once again, though: I suspect that, if you code is not linked into your executable and/or your executable is not run at least once, then you will not see data related to the unused code.

[hramrach]

cat a.c

int main() {
    return 0;
}

ln -s a.c b.c gcc -Wall -fprofile-arcs -ftest-coverage a.c -o a gcc -Wall -fprofile-arcs -ftest-coverage b.c -o b ./a lcov --capture --branch-coverage --base $(pwd) --no-external --directory . --output-file coverage0.info

geninfo cmd: '/usr/bin/geninfo . --output-filename coverage0.info --base-directory /home/hramrach/test --no-external --memory 0 --branch-coverage'
Found gcov version: 7.5.0
Using intermediate gcov format
Writing temporary data to /tmp/geninfo_datdan9
Scanning . for .gcda files ...
Found 1 data files in .
Processing ./a.gcda
Finished .info-file creation

lcov --capture --initial --branch-coverage --base $(pwd) --no-external --directory . --output-file coverage1.info

Found gcov version: 7.5.0
Using intermediate gcov format
Writing temporary data to /tmp/geninfo_datJ1JU
Scanning . for .gcno files ...
Found 2 graph files in .
Processing ./a.gcno
Processing ./b.gcno
Finished .info-file creation

lcov --branch-coverage --add-tracefile coverage0.info --add-tracefile coverage1.info --output-file coverage.info

Combining tracefiles.
.. found 2 files to aggregate.
Merging coverage0.info..1 remaining
Merging coverage1.info..0 remaining
Writing data to coverage.info
Summary coverage rate:
  lines......: 50.0% (2 of 4 lines)
  functions..: 50.0% (1 of 2 functions)
  branches...: no data found

lcov --list coverage0.info

           |Lines       |Functions  |Branches    
Filename    |Rate     Num|Rate    Num|Rate     Num
==================================================
[/home/hramrach/test/]
a.c         |50.0%      2| 0.0%     1|    -      0
==================================================
      Total:|50.0%      2| 0.0%     1|    -      0

lcov --list coverage1.info

            |Lines       |Functions  |Branches    
Filename    |Rate     Num|Rate    Num|Rate     Num
==================================================
[/home/hramrach/test/]
a.c         |    -      0|    -     0|    -      0
b.c         |    -      0|    -     0|    -      0
==================================================
      Total:|    -      0|    -     0|    -      0

lcov --list coverage.info

            |Lines       |Functions  |Branches    
Filename    |Rate     Num|Rate    Num|Rate     Num
==================================================
[/home/hramrach/test/]
a.c         |50.0%      2| 0.0%     1|    -      0
b.c         |    -      0|    -     0|    -      0
==================================================
      Total:| 100%      2| 0.0%     1|    -      0

The gcno file is right there, it does not go anywhere but is ignored by capture unless --initial is specified, forcing additional capture and merge steps, for no apparent reason.

lcov 2.0

[henry2cox]

As it turns out, while your interpersonal skills are a bit weak, your suggestion is a reasonable one. I went ahead and implemented it - though perhaps not exactly as you want:

• (backward compatibility): with no command or configuration changes, you get the same capture behaviour as before (lcov --capture ... looks at .gcda files, lcov --capture --initial ... looks at .gcno files - aggregate in a separate step, if you wish)
• (new behaviour): lcov --capture --all ... will look at both .gcda files and otherwise unmatched .gcno files. The --all flag is equivalent to lcov --capture --rc geninfo_capture_all=1 ... (lcovrc configuration file setting). The --all flag is ignored if you specify --initial.

I am not entirely certain that I have tested all possible error combinations.

This should slightly simply the use model in cases that you really want to capture otherwise unused code, while not breaking any existing usage.

I will push the enhancement next week or the week after.

[hramrach]

That sounds reasonable, thanks

[henry2cox]

Enhancement should be available in f9b156155.

Please go ahead and close the issue if this indeed solves the problem. If not: please include a detailed description of the issue, and include a testcase which illustrates the bug. Thanks Henry

[hramrach]

Looks reasonable, thanks.