I'm using gcov to metric testing coverage on a c++ library I contribute to. For some reason, gcov isn't recognizing lines in many of the files as executable. Out of 160-some lines in a given file it'll say that 40 of them are executable. For example:
-: 0:Source:../evo/NK.h
-: 0:Graph:test_driver.gcno
-: 0:Data:test_driver.gcda
-: 0:Runs:1
-: 0:Programs:1
-: 1:// This file is part of Empirical, https://github.com/devosoft/Empirical
-: 2:// Copyright (C) Michigan State University, 2016.
-: 3:// Released under the MIT Software license; see doc/LICENSE
-: 4://
-: 5://
-: 6:// This file provides code to build NK-based algorithms.
-: 7:
-: 8:#ifndef EMP_EVO_NK_H
-: 9:#define EMP_EVO_NK_H
-: 10:
-: 11:#include <array>
-: 12:
-: 13:#include "../tools/BitVector.h"
-: 14:#include "../tools/const_utils.h"
-: 15:#include "../tools/Random.h"
-: 16:#include "../tools/vector.h"
-: 17:
-: 18:namespace emp {
-: 19:namespace evo {
-: 20:
-: 21: class NKLandscape {
-: 22: private:
-: 23: const uint32_t N;
-: 24: const uint32_t K;
-: 25: const uint32_t state_count;
-: 26: const uint32_t total_count;
-: 27: emp::vector< emp::vector<double> > landscape;
-: 28:
-: 29: public:
-: 30: NKLandscape() = delete;
-: 31: NKLandscape(const NKLandscape &) = delete;
-: 32: NKLandscape(int _N, int _K, emp::Random & random)
-: 33: : N(_N), K(_K)
-: 34: , state_count(emp::constant::IntPow<uint32_t>(2,K+1))
-: 35: , total_count(N * state_count)
-: 36: , landscape(N)
-: 37: {
-: 38: for ( auto & ltable : landscape) {
-: 39: ltable.resize(state_count);
-: 40: for (double & pos : ltable) {
-: 41: pos = random.GetDouble();
-: 42: }
-: 43: }
-: 44: }
-: 45: ~NKLandscape() { ; }
-: 46: NKLandscape & operator=(const NKLandscape &) = delete;
-: 47:
-: 48: int GetN() const { return N; }
-: 49: int GetK() const { return K; }
-: 50: int GetStateCount() const { return state_count; }
-: 51: int GetTotalCount() const { return total_count; }
-: 52:
-: 53: double GetFitness(int n, uint32_t state) const {
-: 54: emp_assert(state < state_count, state, state_count);
-: 55: return landscape[n][state];
-: 56: }
-: 57: double GetFitness( std::vector<uint32_t> states ) const {
-: 58: emp_assert(states.size() == N);
-: 59: double total = landscape[0][states[0]];
-: 60: for (int i = 1; i < N; i++) total += GetFitness(i,states[i]);
-: 61: return total;
-: 62: }
-: 63: double GetFitness(BitVector genome) const {
-: 64: emp_assert(genome.GetSize() == N);
-: 65:
-: 66: // Use a double-length genome to easily handle wrap-around.
-: 67: genome.Resize(N*2);
-: 68: genome |= (genome << N);
-: 69:
-: 70: double total = 0.0;
-: 71: uint32_t mask = emp::constant::MaskLow<uint32_t>(K+1);
-: 72: for (int i = 0; i < N; i++) {
-: 73: const uint32_t cur_val = (genome >> i).GetUInt(0) & mask;
-: 74: const double cur_fit = GetFitness(i, cur_val);
-: 75: total += cur_fit;
-: 76: }
-: 77: return total;
-: 78: }
-: 79: };
-: 80:
-: 81:}
3: 82:}
-: 83:
-: 84:#endif
Here, gcov marks nearly all the lines in the file as non-executable, but tracks 3 executions of line 82: a single closing bracket.
This makes no sense to me and I haven't been able to find anything about this issue on the web. Any help would be greatly appreciated.
Here's a rough flowchart for the behaviour of gcov (and related software like gcovr and lcov):
Figure: gcov data flow
When the compiler (GCC) generates the object code and was asked to insert coverage/profiling instrumentation, it does two extra things:
The gcov utility then parses the .gcda and .gcno files to calculate coverage metrics. For the annotated source report, it also reads the source file.
Because it is the compiler that determines which part of the object code corresponds to a particular line, the report you've shown is correct: that line doesn't exist. More precisely: no object code was generated for those source code lines. This is generally the expected behaviour, since many source code lines are just compile-time declarations.
In your case you have a C++ class with inline functions (any function definitions within a class definition are implicitly inline). The compiler need not generate code for inline functions that are not used. This would be different if you use non-inline functions, i.e. declare the functions in a header file and provide implementations in a .cpp file.
So what's up with the three executions of a closing brace? The compiler often needs to emit some code associated with the initialization and cleanup of static objects. This code is not really associated with a specific line, and therefore appears as part of the last line in your compilation unit.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With