On Tue, Nov 02, 2021 at 12:51:16PM -0600, Martin Sebor via Gcc-patches wrote: > 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
That's not exactly true: -Warray-compare is not meant to be -Wtautological-compare. I introduced -Warray-compare because the C++ standard now says that array == array is deprecated, but -Wtautological-compare comes from a different angle: it warns because the comparison always evaluates to a constant. > -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. Yeah, in this particular case I think it'd be better to simple enhance -Waddress rather than to invent a new option. Marek
