This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] gcov: Mark BBs that do not correspond to a line in source code (PR gcov-profile/79891).


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
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]