public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/31878] New: Spurious warnings generated due to not optimizing first
@ 2007-05-09 13:12 lloyd at randombit dot net
2007-05-09 21:07 ` [Bug c/31878] " pinskia at gcc dot gnu dot org
` (9 more replies)
0 siblings, 10 replies; 11+ messages in thread
From: lloyd at randombit dot net @ 2007-05-09 13:12 UTC (permalink / raw)
To: gcc-bugs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1735 bytes --]
$ cat return.c
#include <assert.h>
int f(int x) {
if(x)
return x;
assert(x);
}
$ gcc -O2 -c -Wall -W return.c
return.c: In function int f(int):
return.c:9: warning: control reaches end of non-void function
The call to assert expands to (glibc 2.4):
(static_cast<void> ((x) ? 0 : (__assert_fail ("x", "return.c", 8,
__PRETTY_FUNCTION__), 0)));
So unless I'm missing something f() is equivalent to:
if(x)
return x;
else
__assert_fail(/* etc */);
However when explicitly written in this way, we don't get a warning:
$ cat return2.c
#include <assert.h>
int f(int x)
{
if(x)
return x;
else
__assert_fail ("x", __FILE__, __LINE__, __PRETTY_FUNCTION__);
}
$ gcc -O2 -Wall -c return2.c
$
Looking at the produced assembly on an x86-64 system, GCC is only performing
the comparison once (when optimizing), so it should see that there is no
codepath that doesn't either return or call a noreturn function. However I'm
guessing warnings are generated prior to the optimizer running and thus don't
see this?
Marked as Severity: trivial because one can always insert a dummy return after
the assert. Which is good because AFAICT fixing this would require rewriting
GCC. :)
--
Summary: Spurious warnings generated due to not optimizing first
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lloyd at randombit dot net
GCC build triplet: x86_64-redhat-linux
GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31878
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/31878] Spurious warnings generated due to not optimizing first
2007-05-09 13:12 [Bug c/31878] New: Spurious warnings generated due to not optimizing first lloyd at randombit dot net
@ 2007-05-09 21:07 ` pinskia at gcc dot gnu dot org
2007-05-09 21:16 ` lloyd at randombit dot net
` (8 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2007-05-09 21:07 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/31878] Spurious warnings generated due to not optimizing first
2007-05-09 13:12 [Bug c/31878] New: Spurious warnings generated due to not optimizing first lloyd at randombit dot net
2007-05-09 21:07 ` [Bug c/31878] " pinskia at gcc dot gnu dot org
@ 2007-05-09 21:16 ` lloyd at randombit dot net
2007-05-10 14:50 ` manu at gcc dot gnu dot org
` (7 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: lloyd at randombit dot net @ 2007-05-09 21:16 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/31878] Spurious warnings generated due to not optimizing first
2007-05-09 13:12 [Bug c/31878] New: Spurious warnings generated due to not optimizing first lloyd at randombit dot net
2007-05-09 21:07 ` [Bug c/31878] " pinskia at gcc dot gnu dot org
2007-05-09 21:16 ` lloyd at randombit dot net
@ 2007-05-10 14:50 ` manu at gcc dot gnu dot org
2007-05-10 16:51 ` lloyd at randombit dot net
` (6 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: manu at gcc dot gnu dot org @ 2007-05-10 14:50 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/31878] Spurious warnings generated due to not optimizing first
2007-05-09 13:12 [Bug c/31878] New: Spurious warnings generated due to not optimizing first lloyd at randombit dot net
` (2 preceding siblings ...)
2007-05-10 14:50 ` manu at gcc dot gnu dot org
@ 2007-05-10 16:51 ` lloyd at randombit dot net
2007-05-11 10:38 ` manu at gcc dot gnu dot org
` (5 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: lloyd at randombit dot net @ 2007-05-10 16:51 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/31878] Spurious warnings generated due to not optimizing first
2007-05-09 13:12 [Bug c/31878] New: Spurious warnings generated due to not optimizing first lloyd at randombit dot net
` (3 preceding siblings ...)
2007-05-10 16:51 ` lloyd at randombit dot net
@ 2007-05-11 10:38 ` manu at gcc dot gnu dot org
2008-11-14 23:39 ` [Bug middle-end/31878] " pinskia at gcc dot gnu dot org
` (4 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: manu at gcc dot gnu dot org @ 2007-05-11 10:38 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug middle-end/31878] Spurious warnings generated due to not optimizing first
2007-05-09 13:12 [Bug c/31878] New: Spurious warnings generated due to not optimizing first lloyd at randombit dot net
` (4 preceding siblings ...)
2007-05-11 10:38 ` manu at gcc dot gnu dot org
@ 2008-11-14 23:39 ` pinskia at gcc dot gnu dot org
2009-02-12 14:59 ` [Bug middle-end/31878] Spurious warnings with -Wreturn-type due to not performing CCP/VRP in the front-end manu at gcc dot gnu dot org
` (3 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2008-11-14 23:39 UTC (permalink / raw)
To: gcc-bugs
------- Comment #6 from pinskia at gcc dot gnu dot org 2008-11-14 23:38 -------
This needs VRP really to be run at -O0 which I don't think is going to happen
any time soon.
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|trivial |enhancement
Component|c |middle-end
GCC build triplet|x86_64-redhat-linux |
GCC host triplet|x86_64-redhat-linux |
GCC target triplet|x86_64-redhat-linux |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31878
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug middle-end/31878] Spurious warnings with -Wreturn-type due to not performing CCP/VRP in the front-end
2007-05-09 13:12 [Bug c/31878] New: Spurious warnings generated due to not optimizing first lloyd at randombit dot net
` (5 preceding siblings ...)
2008-11-14 23:39 ` [Bug middle-end/31878] " pinskia at gcc dot gnu dot org
@ 2009-02-12 14:59 ` manu at gcc dot gnu dot org
2009-12-29 6:07 ` sabre at nondot dot org
` (2 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: manu at gcc dot gnu dot org @ 2009-02-12 14:59 UTC (permalink / raw)
To: gcc-bugs
------- Comment #7 from manu at gcc dot gnu dot org 2009-02-12 14:59 -------
Updating the description. Although anyone would agree that not warning is the
right thing to do, there doesn't seem to be any practical solution for this
problem, so I leave it as unconfirmed.
I wonder if clang/llvm gets this right.
--
manu at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |manu at gcc dot gnu dot org
Summary|Spurious warnings generated |Spurious warnings with -
|due to not optimizing first |Wreturn-type due to not
| |performing CCP/VRP in the
| |front-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31878
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug middle-end/31878] Spurious warnings with -Wreturn-type due to not performing CCP/VRP in the front-end
2007-05-09 13:12 [Bug c/31878] New: Spurious warnings generated due to not optimizing first lloyd at randombit dot net
` (6 preceding siblings ...)
2009-02-12 14:59 ` [Bug middle-end/31878] Spurious warnings with -Wreturn-type due to not performing CCP/VRP in the front-end manu at gcc dot gnu dot org
@ 2009-12-29 6:07 ` sabre at nondot dot org
2009-12-30 1:43 ` manu at gcc dot gnu dot org
2009-12-30 1:46 ` sabre at nondot dot org
9 siblings, 0 replies; 11+ messages in thread
From: sabre at nondot dot org @ 2009-12-29 6:07 UTC (permalink / raw)
To: gcc-bugs
------- Comment #8 from sabre at nondot dot org 2009-12-29 06:07 -------
Clang does not produce diagnostics from the optimizer. We intentionally do not
want to do this, because of the fragility of the diagnostics as the optimizer
evolves. IMO it is much better to produce a consistent and predictable set of
diagnostics rather than trying to avoid all false positives by relying on the
optimizer to be tricky.
--
sabre at nondot dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sabre at nondot dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31878
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug middle-end/31878] Spurious warnings with -Wreturn-type due to not performing CCP/VRP in the front-end
2007-05-09 13:12 [Bug c/31878] New: Spurious warnings generated due to not optimizing first lloyd at randombit dot net
` (7 preceding siblings ...)
2009-12-29 6:07 ` sabre at nondot dot org
@ 2009-12-30 1:43 ` manu at gcc dot gnu dot org
2009-12-30 1:46 ` sabre at nondot dot org
9 siblings, 0 replies; 11+ messages in thread
From: manu at gcc dot gnu dot org @ 2009-12-30 1:43 UTC (permalink / raw)
To: gcc-bugs
------- Comment #9 from manu at gcc dot gnu dot org 2009-12-30 01:43 -------
(In reply to comment #8)
So the answer is that Clang also warns. I was wondering whether the minimal ccp
propagation that Clang does in the front-end would catch this. I guess the
answer is no.
As for GCC, the general wisdom is to not move more warnings to the middle-end
unless really awful false positives/negatives, and to not perform any expensive
optimizations at -O0. So unless someone comes up with a more convincing
testcase, or an inexpensive way to detect this at -O0, this won't be fixed.
Closing then, we have far enough real bugs to worry about.
--
manu at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |WONTFIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31878
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug middle-end/31878] Spurious warnings with -Wreturn-type due to not performing CCP/VRP in the front-end
2007-05-09 13:12 [Bug c/31878] New: Spurious warnings generated due to not optimizing first lloyd at randombit dot net
` (8 preceding siblings ...)
2009-12-30 1:43 ` manu at gcc dot gnu dot org
@ 2009-12-30 1:46 ` sabre at nondot dot org
9 siblings, 0 replies; 11+ messages in thread
From: sabre at nondot dot org @ 2009-12-30 1:46 UTC (permalink / raw)
To: gcc-bugs
------- Comment #10 from sabre at nondot dot org 2009-12-30 01:46 -------
Yes, clang warns:
$ clang t.c
t.c:7:1: warning: control may reach end of non-void function [-Wreturn-type]
}
^
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31878
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2009-12-30 1:46 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-05-09 13:12 [Bug c/31878] New: Spurious warnings generated due to not optimizing first lloyd at randombit dot net
2007-05-09 21:07 ` [Bug c/31878] " pinskia at gcc dot gnu dot org
2007-05-09 21:16 ` lloyd at randombit dot net
2007-05-10 14:50 ` manu at gcc dot gnu dot org
2007-05-10 16:51 ` lloyd at randombit dot net
2007-05-11 10:38 ` manu at gcc dot gnu dot org
2008-11-14 23:39 ` [Bug middle-end/31878] " pinskia at gcc dot gnu dot org
2009-02-12 14:59 ` [Bug middle-end/31878] Spurious warnings with -Wreturn-type due to not performing CCP/VRP in the front-end manu at gcc dot gnu dot org
2009-12-29 6:07 ` sabre at nondot dot org
2009-12-30 1:43 ` manu at gcc dot gnu dot org
2009-12-30 1:46 ` sabre at nondot dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).