On 03/21/2017 07:39 PM, Nathan Sidwell wrote:
> Martin, Richard,
> I've read up on the thread, but I'm not sure where you guys are with an
> actual patch. From what I Richard nailed it in BZ with the comment that the
> BB should not be associated with any source line. That's a new thing, so I
> think the gcov format needs extending (at least).
>
> gcov must associate every BB with source line, so that it can present data to
> users. That's a conflict with the above observation.
Hi.
Well, discussion shows that currently gcov is based on mapping between basic
blocks and source lines. More precisely, when
a basic block is reached than we know that a bunch of source lines is executed.
We also assume that all basic blocks must belong
to a line in a source code (counter example triggered this discussion). I
believe the proper approach should be more focused on
edges to cover situations like:
int main()
{
foo (); goto baz; lab: bar ();
baz:
if (a == 1)
goto lab;
}
Moreover, there are 2 uncovered situations:
a) creation of a deleting constructor maps counters from 2 functions to a
single line of code (PR 48463).
b) multi-versioning of a function can do very similar stuff; I know that it's
rare that one has a valid profile
compound of 2 runs on a different machine
I'm planning to come back the these in next stage1. I would be happy for any
feedback.
Martin
>
> I don't understand why gcov does NOT think the line is executed when -a is
> not used:
>
> -: 29: /* Following line falsely marked as
> covered when parameter "--rc lcov_branch_coverage=1" is set */
> #####: 30: ReturnStatus_t = 0;
>
> At least one block associated with line 30 is executed. Why's it not being
> counted?
>
> But that does seem to be the right output -- we shouldn't count this
> 'artificial' block. So then the question morphs into the -a case:
>
> 1: 30: ReturnStatus_t = 0;
> $$$$$: 30-block 0
> 1: 30-block 1
>
> We do count the artificial block. Which is inconsistent.
>
> Sorry, at this point I'm lost as to what is being suggested as a solution.
>
> nathan
>
