On 7/10/24 23:59, Jeff Law wrote:
On 7/10/24 3:18 PM, Jørgen Kvalsvik wrote:
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?
Sorry I wasn't clear. My point was that that there's not a hard and
fast rule we can follow for handling of the final close curley in gcov.
So, if including the last line even if it's not covered by a block works
well in practice, then it seems fine to me.
I see, that makes sense. I'll install it as two commits just to make
sure bisecting and reverting is easier, just in case it has unintended
consequences, before applying.
Thanks,
Jørgen
