On Thu, Jul 11, 2019 at 12:52 PM Eric Botcazou <ebotca...@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
