public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/33925] New: gcc -Waddress lost some useful warnings
@ 2007-10-27 17:17 mec at google dot com
2008-01-31 2:46 ` [Bug c++/33925] " manu at gcc dot gnu dot org
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: mec at google dot com @ 2007-10-27 17:17 UTC (permalink / raw)
To: gcc-bugs
gcc -Waddress got a little bit worse between gcc 4.0.4 and gcc 4.1.2. It would
be useful to get this warning, especially for C++ inline methods.
mec@hollerith:~/exp-address$ cat z2.cc
extern bool Alpha();
inline bool Beta(bool b) { return b; }
class MyClass { public: static bool MyMethod(bool b) { return b; } };
bool Gamma() {
if (Alpha) {
if (Beta) {
if (MyClass::MyMethod) {
return true;
}
}
}
return false;
}
mec@hollerith:~/exp-address$ /home/mec/gcc-4.0.4/install/bin/g++ -Wall -O2 -S
z2.cc
z2.cc: In function 'bool Gamma()':
z2.cc:6: warning: the address of 'bool Alpha()', will always evaluate as 'true'
z2.cc:7: warning: the address of 'bool Beta(bool)', will always evaluate as
'true'
z2.cc:8: warning: the address of 'static bool MyClass::MyMethod(bool)', will
always evaluate as 'true'
mec@hollerith:~/exp-address$ /home/mec/gcc-4.1.2/install/bin/g++ -Wall -O2 -S
z2.cc
z2.cc: In function 'bool Gamma()':
z2.cc:6: warning: the address of 'bool Alpha()', will always evaluate as 'true'
mec@hollerith:~/exp-address$ /home/mec/gcc-4.2.2/install/bin/g++ -Wall -O2 -S
z2.cc
z2.cc: In function 'bool Gamma()':
z2.cc:6: warning: the address of 'bool Alpha()' will always evaluate as 'true'
mec@hollerith:~/exp-address$ /home/mec/gcc-4.3-20071019/install/bin/g++ -Wall
-O2 -S z2.cc
z2.cc: In function 'bool Gamma()':
z2.cc:6: warning: the address of 'bool Alpha()' will always evaluate as 'true'
mec@hollerith:~/exp-address$
--
Summary: gcc -Waddress lost some useful warnings
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mec at google dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33925
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug c++/33925] gcc -Waddress lost some useful warnings
2007-10-27 17:17 [Bug c++/33925] New: gcc -Waddress lost some useful warnings mec at google dot com
@ 2008-01-31 2:46 ` manu at gcc dot gnu dot org
2009-07-31 15:13 ` manu at gcc dot gnu dot org
2009-07-31 16:04 ` mec at google dot com
2 siblings, 0 replies; 4+ messages in thread
From: manu at gcc dot gnu dot org @ 2008-01-31 2:46 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from manu at gcc dot gnu dot org 2008-01-31 01:32 -------
I am not sure if this is actually a bug, since I think functions with weak
linkage can actually have a null-address if they are not instantiated.
Nonetheless, a regression hunt identifies this patch as the cause:
r104103 | mmitchel | 2005-09-09 20:56:16 +0200 (Fri, 09 Sep 2005) | 15 lines
PR c++/22252
* decl.c (start_preparsed_function): Do not pay attention to
#pragma interface for implicitly-defined methods.
* decl2.c (cp_finish_file): Do not complain about uses of inline
functions that have bodies, even if we decided not to emit the
body in this translation unit.
* semantics.c (note_decl_for_pch): Do not mess with linkage.
(expand_or_defer_fn): Make inline, non-template functions COMDAT
at this point.
PR c++/22252
* g++.dg/ext/interface1.C: New test.
* g++.dg/ext/interface1.h: Likewise.
* g++.dg/ext/interface1a.cc: Likewise.
--
manu at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |manu at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33925
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug c++/33925] gcc -Waddress lost some useful warnings
2007-10-27 17:17 [Bug c++/33925] New: gcc -Waddress lost some useful warnings mec at google dot com
2008-01-31 2:46 ` [Bug c++/33925] " manu at gcc dot gnu dot org
@ 2009-07-31 15:13 ` manu at gcc dot gnu dot org
2009-07-31 16:04 ` mec at google dot com
2 siblings, 0 replies; 4+ messages in thread
From: manu at gcc dot gnu dot org @ 2009-07-31 15:13 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from manu at gcc dot gnu dot org 2009-07-31 15:13 -------
Is this really a bug or not?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33925
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug c++/33925] gcc -Waddress lost some useful warnings
2007-10-27 17:17 [Bug c++/33925] New: gcc -Waddress lost some useful warnings mec at google dot com
2008-01-31 2:46 ` [Bug c++/33925] " manu at gcc dot gnu dot org
2009-07-31 15:13 ` manu at gcc dot gnu dot org
@ 2009-07-31 16:04 ` mec at google dot com
2 siblings, 0 replies; 4+ messages in thread
From: mec at google dot com @ 2009-07-31 16:04 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from mec at google dot com 2009-07-31 16:04 -------
Subject: Re: gcc -Waddress lost some useful warnings
Yes, I think this is a bug, because the behavior of gcc doesn't match
its documentation.
First, I think the C++ standard forbids a function from having a null
address:
[conv.ptr] 4.10 -1- A null pointer constant is an integral constant
expression (5.19) rvalue of integer type that evalutes to zero. A null
pointer constant can be converted to a pointer type; the result is the
null pointer value of that type and is distinguishable from every other
value of pointer to object or pointer to function type.
Even if you break this to allow for weak pointers to functions, the
documentation for -Waddress says:
http://gcc.gnu.org/onlinedocs/gcc-4.4.1/gcc/Warning-Options.html#Warning-Options
"Warn about suspicious uses of memory addresses. These include the
address of a function in a conditional expression such as void
func(void); if (func) ... such uses typically indicate a programmer
error: the address of a function always evaluates to true, so their use
in a conditional usually indicate that the programmer forgot the
parentheses in a function call ...".
This documentation repeats the claim that "the address of a function is
always true".
More than that: "warnings are diagnostic messages that report
constructions which are not inherently erroneous but which are risky or
suggest there may have been an error". By enabling -Waddress, I believe
the user intends to report all instances of "if (func)" with the
expectation that most of them are mistaken versions of "if (func())" or
"if (func(some_parameters ...))". If the user is building
(non-standard) code where the addresses of some functions may be null
and "if (func)" is likely the intended meaning, then they can decline to
turn on -Waddress. If such code is common, you may want to re-think the
inclusion of -Waddress in -Wall.
As it is, -Waddress sometimes prints the message that it is documented
to print, and sometimes does not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33925
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2009-07-31 16:04 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-10-27 17:17 [Bug c++/33925] New: gcc -Waddress lost some useful warnings mec at google dot com
2008-01-31 2:46 ` [Bug c++/33925] " manu at gcc dot gnu dot org
2009-07-31 15:13 ` manu at gcc dot gnu dot org
2009-07-31 16:04 ` mec at google dot com
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).