[PATCH] restore ancient -Waddress for weak symbols [PR33925]

Martin Sebor msebor@gmail.com
Tue Nov 2 18:51:16 GMT 2021

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.


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

More information about the Gcc-patches mailing list