Using built-in specs. COLLECT_GCC=/usr/bin/gcc-4.6 COLLECT_LTO_WRAPPER=/usr/lib/gcc/i486-linux-gnu/4.6.1/lto-wrapper Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.0-2' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default --with-plugin-ld --enable-objc-gc --enable-targets=all --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.6.1 20110329 (prerelease) (Debian 4.6.0-2) Consider this test file: #include <stdlib.h> typedef struct buf { size_t len; char *stuff; } buf; #define buflen(b) ((b) == NULL ? 0 : (b)->len) int func() { buf b; b.len = 5; b.stuff = malloc(5); if (buflen(&b) > 0) return 1; else return 0; } This compiles without warnings with -Wall on gcc <=4.5. But gcc-4.6 -c -Waddress test.c test.c: In function ‘func’: test.c:18:12: warning: the comparison will always evaluate as ‘false’ for the address of ‘b’ will never be NULL [-Waddress] I don't think this is really helpful. Macros like in the above example are not uncommon, and there is no obvious way to write the code better.
Maybe we should disable some warnings when they come from macros. Or have an option to do that.
We have the capability to do this now since GCC 4.7, but someone needs to implement it for this case.
I have a simple patch. Probably GCC7 material anyway.
(In reply to Peter Eisentraut from comment #0) > I don't think this is really helpful. Macros like in the above example are > not uncommon, and there is no obvious way to write the code better. A better way (in that it doesn't elicit the warning) to write buflen() is as an inline function, perhaps while leaving the buflen macro in place: #define buflen(b) ((b) == NULL ? 0 : (b)->len) static inline size_t (buflen)(const buf *b) { return buflen (b); } Then users of buflen have a choice of calling either the function (by parenthesizing the name) or the macro (without the parentheses). This practice is codified in the C standard where C library functions may be (also) defined as macros this way. I would rather not compromise the GCC warning since it's possible to make the opposite argument: that not issuing the warning for macros is unhelpful.
Author: mpolacek Date: Wed May 4 13:46:15 2016 New Revision: 235878 URL: https://gcc.gnu.org/viewcvs?rev=235878&root=gcc&view=rev Log: PR c/48778 * c-typeck.c (build_binary_op): Don't issue -Waddress warnings for macro expansions. * gcc.dg/Waddress-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/Waddress-2.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/testsuite/ChangeLog
Fixed, for some definition of "fixed".