> 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.
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.
--
Eric Botcazou
