On 7/10/24 1:30 PM, Jørgen Kvalsvik wrote:
Thanks you -- before I move forward, I would like some feedback on
adding this diff to the patch:
diff --git a/gcc/gcov.cc b/gcc/gcov.cc
index 9cdef19c461..055fa7e78ba 100644
--- a/gcc/gcov.cc
+++ b/gcc/gcov.cc
@@ -1613,6 +1613,12 @@ process_all_functions (void)
}
}
+ /* Make sure to include the last line for this function even
when it
+ is not directly covered by a basic block, for example
when } is on
+ its own line. */
+ if (sources[fn->src].lines.size () <= fn->end_line)
+ sources[fn->src].lines.resize (fn->end_line + 1);
+
All gcov.exp still pass (for C, C++), and it doesn't seem to have any
negative effects. The point is to include the last line of the function,
even if it is not touched by a basic block (which it won't be, for the
most part, because the function return happens before }). For filtering,
the effect is positive because the full function is actually included,
note the final }:
$ gcov -t sum --include=sub
sum.gcda:cannot open data file, assuming not executed
-: 0:Source:sum.cc
-: 0:Graph:sum.gcno
-: 0:Data:-
-: 0:Runs:0
#####: 5:int sub (int a, int b) {
#####: 6: return a - b;
-: 7:}
Thoughts?
It seems reasonable. This is all a bit fuzzy.
You could return via the epilogue and we could conceptually mark the
epilogue as being on the close curley from a line number standpoint.
But then what do we do with sibling calls which are both calls and
returns at the same time. Those we probably wouldn't want to associate
with the close curley and that could be the only return path. Point
being including that line even though it's not always associated with a
basic block seems reasonable to me.
jeff
Thanks,
Jørgen
