------- Comment #3 from manu at gcc dot gnu dot org 2007-05-10 15:50 -------
(In reply to comment #2)
> So are you saying that it is the case that the f() function below might return
> without a value? Since that is what the warning suggests.
assert() does not return a value and it is the last . So, yes, as far as GCC
knows when it emits the warning, f() may return without a value. Another
example:
int f(int x)
{
int y = 1;
if(y)
return x;
}
> (My interpretation re the optimizer may be completely off, I don't know GCC
> internals, but I have a hard time believing that GCC warning about something
> that cannot possibly happen is not a bug)
You may know that it cannot possibly happen but GCC may not know it. In the
general case, it is the halting problem. In practice, there should be a limit
to how much effort GCC should do. The current limit is that warnings (in
general) are given by front-ends and should be the same with and without
optimisation. But even if that weren't the case, the warning currently comes
before optimisation and changing this is not simple at all. Finally, you could
always build a testcase where GCC is not smart enough.
I agree with Andrew: this is not a bug. At most, it is an enhancement request
that conflicts with the current general rule that front-end warnings should be
the same with and without optimisation.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31878
