On 7/10/24 21:54, Jeff Law wrote:
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.
I might be misunderstanding, but I don't think a sibling call would be
affected by this, or rather, I don't think there's a change in line
association here, and it should not affect the line counts. Line 7, for
example, is not executed even though it is printed with --include. A
(sibling) call would still be associated with a block anyway, right?
Thanks,
Jørgen
jeff
Thanks,
Jørgen
