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