[Bug c/31878] Spurious warnings generated due to not optimizing first
--- Comment #5 from manu at gcc dot gnu dot org 2007-05-11 11:38 --- (In reply to comment #4) So obviously it knows, at the level of the code generator, it's just a question of propagating that information back to the frontend. I wrote: yes, as far as GCC knows when it emits the warning, f() may return without a value. So obviously, code generation happens way after the warning is emitted. There is no propagating back information to the front-end. Sorry. This is not how GCC works. So, yes, fixing this may require rewriting GCC. But even if it were trivial, that is, even if when using optimisation we could detect that no warning is needed, there is the current policy of giving (in general) the same warnings with and without optimisation. Thus, GCC may still decide to give a warning. So I still don't think this is worthy to be called a bug, at best it is WONTFIX. But, hey!, if you want to keep it open in case some brave volunteer developer appears from the void and decides to contribute some magical patch... who knows, the hero might be you. ;-) Speaking of the same warnings with-or-without optimizations - should I then file a bug about: [snip] No warning about y being used uninitialized unless I compile with optimizations... Currently, -Wuninitialized needs optimisation to do any work. This may change in the future, though. You chose one of the few exceptions to illustrate your point. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31878
[Bug c/31878] Spurious warnings generated due to not optimizing first
--- 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
[Bug c/31878] Spurious warnings generated due to not optimizing first
--- Comment #4 from lloyd at randombit dot net 2007-05-10 17:51 ---
Manuel,
For your example code, GCC _is_ aware that the function always returns, since
the code it generates for it (with optimization) is:
f:
movl%edi, %eax
ret
So obviously it knows, at the level of the code generator, it's just a question
of propagating that information back to the frontend.
Speaking of the same warnings with-or-without optimizations - should I then
file a bug about:
int f(int x)
{
int y;
if(x)
return y;
return 0;
}
No warning about y being used uninitialized unless I compile with
optimizations...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31878
[Bug c/31878] Spurious warnings generated due to not optimizing first
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-09 22:07 --- We should get the same warning while compiling with optimizations and while compiling without so I don't think this is a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31878
[Bug c/31878] Spurious warnings generated due to not optimizing first
--- Comment #2 from lloyd at randombit dot net 2007-05-09 22:16 --- 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. (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) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31878
