On 10/4/21 4:39 PM, Eric Gallager wrote:
On Mon, Oct 4, 2021 at 2:43 PM Martin Sebor via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:

While resolving the recent -Waddress enhancement request (PR
PR102103) I came across a 2007 problem report about GCC 4 having
stopped warning for using the address of inline functions in
equality comparisons with null.  With inline functions being
commonplace in C++ this seems like an important use case for
the warning.

The change that resulted in suppressing the warning in these
cases was introduced inadvertently in a fix for PR 22252.

To restore the warning, the attached patch enhances
the decl_with_nonnull_addr_p() function to return true also for
weak symbols for which a definition has been provided.

Tested on x86_64-linux and by comparing the GCC output for new
test cases to Clang's which diagnoses all but one instance of
these cases with either -Wtautological-pointer-compare or
-Wpointer-bool-conversion, depending on context.

Would it make sense to use the same names as clang's flags here, too,
instead of dumping them all under -Waddress? I think the additional
granularity could be helpful for people who only want some warnings,
but not others.

In general I agree.  In this case I'm not sure.  The options
that control these warnings in neither compiler make perfect
sense to me.  Here's a breakdown of the cases:

                   Clang                            GCC
array == array     -Wtautological-compare           -Warray-compare
&decl == null      -Wtautological-pointer-compare   -Waddress
&decl1 == &decl2   N/A                              N/A

GCC has recently diverged from Clang by introducing the new
-Warray-compare option, and we don't have
-Wtautological-pointer-compare.  So while I think it makes
sense to use the same names for new features as those they
are controlled by in Clang, the argument to do the same for
simple enhancements to existing features is quite a bit less
compelling.  We'd likely end up diagnosing different subsets
of the same problem under different options.

Martin


The one case where Clang doesn't issue a warning but GCC
with the patch does is for a symbol explicitly declared with
attribute weak for which a definition has been provided.
I believe the address of such symbols is necessarily nonnull and
so issuing the warning is helpful
(both GCC and Clang fold such comparisons to a constant).

Martin

Reply via email to