------- 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