[patch] Small improvements to coverage info (4/n)

Richard Biener richard.guenther@gmail.com
Thu Jul 11 13:41:00 GMT 2019


On Thu, Jul 11, 2019 at 12:52 PM Eric Botcazou <ebotcazou@adacore.com> wrote:
>
> > Hmm.  So for
> >
> > int baz;
> > int foo()
> > {
> >   int i;
> >   goto skip;
> > done:
> >   return i;
> > skip:
> >   i = 1;
> >   if (baz)
> >     return baz;
> >   /* ... */
> >   goto done;
> > } /* (*) */
> >
> > we'd assign (*) to the return?  It might be better to record
> > (in struct function?) the location of any actually existing
> > return location and use that?  In fact, similar kludgy would
> > be to simply not clear the GIMPLE_RETURN location
> > but kludge it up right away?
>
> As I mentioned, this leads to various diagnostics regressions.
>
> > Can you explain how diagnostics regress when doing that?
>
> For example gcc.dg/uninit-17.c:
>
> /* { dg-do compile } */
> /* { dg-options "-O -Wuninitialized" } */
>
> typedef _Complex float C;
> C foo(int cond)
> {
>   C f;
>   __imag__ f = 0;
>   if (cond)
>     {
>       __real__ f = 1;
>       return f;
>     }
>   return f;     /* { dg-warning "may be used" "unconditional" } */
> }
>
> The warning is not emitted on the expected line, but on the final } line.

It's odd that we pick up this location w/o a location on the return stmt ...
and probably luck on which one we warn.

> There are a couple of other similar cases in the C and C++ testsuites.
>
> > Does coverage somehow treat the function end locus specially
> > so you chose that?  Will it show the alternate returns as
> > covered at all?  I presume stuff like cross-jumping or
> > GIMPLE tail-merging also wrecks coverage info in similar
> > ways (well, not by injecting random locations but by
> > not covering taken paths).
>
> Simple things first please. :-)  The function's end locus is sort of a kitchen
> sink, you cannot have wrong coverage info when you use it, but only a possibly
> incomplete info.

After your patch does behavior change when trying to break on a line
with a return stmt inside a debugger?

Thanks,
Richard.

> --
> Eric Botcazou



More information about the Gcc-patches mailing list