[Bug c/102867] New: Waddress complaint in readelf.c

[Bug c/102867] New: Waddress complaint in readelf.c

[amodra at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102867

            Bug ID: 102867
           Summary: Waddress complaint in readelf.c
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: amodra at gmail dot com
  Target Milestone: ---

Compiling the attached readelf.i with -Wall -Werror -O2 using today's gcc
mainline on x86_64-linux results in complaints like

/home/alan/src/binutils-gdb/binutils/readelf.c: In function ‘find_section’:
/home/alan/src/binutils-gdb/binutils/readelf.c:762:42: error: the comparison
will always evaluate as ‘true’ for the pointer operand in
‘filedata->section_headers + (sizetype)((long unsigned int)i * 80)’ must not be
NULL [-Werror=address]
  762 |     if (SECTION_NAME_VALID (filedata->section_headers + i)

The warning is true, but annoying when coming from a macro expansion
#define SECTION_NAME_VALID(X) \
  ((X) != NULL                                                          \
   && filedata->string_table != NULL                                    \
   && (X)->sh_name < filedata->string_table_length)

In current readelf.c it looks like it may be possible to remove "(X) != NULL"
from this macro, but that doesn't seem like a good solution.  Another macro
with similar complaints
#define SECTION_NAME_PRINT(X) \
  ((X) == NULL ? _("<none>")                                            \
   : filedata->string_table == NULL ? _("<no-strings>")                 \
   : (X)->sh_name >= filedata->string_table_length ? _("<corrupt>")     \
   : filedata->string_table + (X)->sh_name)
can be called with X NULL.

[Bug c/102867] Waddress complaint in readelf.c

[amodra at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102867

--- Comment #1 from Alan Modra <amodra at gmail dot com> ---
Created attachment 51641
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51641&action=edit
preprocessed source

[Bug c/102867] [12 Regression] Waddress complaint in readelf.c

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102867

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Waddress complaint in       |[12 Regression] Waddress
                   |readelf.c                   |complaint in readelf.c
   Target Milestone|---                         |12.0
           Keywords|                            |diagnostic

[Bug c/102867] [12 Regression] Waddress complaint in readelf.c

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102867

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2021-10-21

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.  I wonder if it is possible to omit the warning from chained
conditions that are from the same macro expansion.  That is, warn when
the macro is just

#define SECTION_NAME_VALID(X) ((X) != NULL)

but not when there's additional conditions on it.

[Bug c/102867] [12 Regression] Waddress complaint in readelf.c

[amodra at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102867

--- Comment #3 from Alan Modra <amodra at gmail dot com> ---
Not that I'm really complaining about this, note also that the error message
referencing "filedata->section_headers + (sizetype)((long unsigned int)i * 80)"
is a little bit too much of compiler internal representation leaking out. 
Nowhere in the source is such an expression used.  It's simply
"filedata->section_headers + i".

BTW, the warnings can be avoided by converting the readelf.c macros to inline
functions.

[Bug c/102867] [12 Regression] Waddress complaint in readelf.c

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102867

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |msebor at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #4 from Martin Sebor <msebor at gcc dot gnu.org> ---
The warning for macros was most likely inadvertently enabled in the change for
pr102103.  In hindsight, I'm guessing it's what triggered the instance in Glibc
(since fixed):
https://sourceware.org/pipermail/libc-alpha/2021-September/131241.html
and I think it might have also been what prompted the change below (I meant to
follow up there but got busy with other things):
https://gcc.gnu.org/pipermail/gcc-patches/2021-October/580786.html

I have a follow-on patch out for review for pr33925.  I'll look into the macro
suppression at the same time, although I'm not too keen on that idea in general
if it can be easily avoided in user code (e.g., inlining).  I'd rather get away
from it if it's not too painful.

The poor format of the expression in the warning is an independent issue worth
addressing separately.

[Bug c/102867] [12 Regression] -Waddress from macro expansion in readelf.c

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102867

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[12 Regression] Waddress    |[12 Regression] -Waddress
                   |complaint in readelf.c      |from macro expansion in
                   |                            |readelf.c
           Keywords|                            |patch

--- Comment #5 from Martin Sebor <msebor at gcc dot gnu.org> ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582415.html

[Bug c/102867] [12 Regression] -Waddress from macro expansion in readelf.c

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102867

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Martin Sebor <msebor@gcc.gnu.org>:

https://gcc.gnu.org/g:16137fbb9256ef365dd498d39024eb33de1a4cd8

commit r12-5410-g16137fbb9256ef365dd498d39024eb33de1a4cd8
Author: Martin Sebor <msebor@redhat.com>
Date:   Fri Nov 19 09:44:31 2021 -0700

    Restore ancient -Waddress for weak symbols [PR33925].

    Resolves:
    PR c/33925 - gcc -Waddress lost some useful warnings
    PR c/102867 - -Waddress from macro expansion in readelf.c

    gcc/c-family/ChangeLog:

            PR c++/33925
            PR c/102867
            * c-common.c (decl_with_nonnull_addr_p): Call maybe_nonzero_address
            and improve handling tof defined symbols.

    gcc/c/ChangeLog:

            PR c++/33925
            PR c/102867
            * c-typeck.c (maybe_warn_for_null_address): Suppress warnings for
            code resulting from macro expansion.

    gcc/cp/ChangeLog:

            PR c++/33925
            PR c/102867
            * typeck.c (warn_for_null_address): Suppress warnings for code
            resulting from macro expansion.

    gcc/ChangeLog:

            PR c++/33925
            PR c/102867
            * doc/invoke.texi (-Waddress): Update.

    gcc/testsuite/ChangeLog:

            PR c++/33925
            PR c/102867
            * g++.dg/warn/Walways-true-2.C: Adjust to avoid a valid warning.
            * c-c++-common/Waddress-5.c: New test.
            * c-c++-common/Waddress-6.c: New test.
            * g++.dg/warn/Waddress-7.C: New test.
            * gcc.dg/Walways-true-2.c: Adjust to avoid a valid warning.
            * gcc.dg/weak/weak-3.c: Expect a warning.

[Bug c/102867] [12 Regression] -Waddress from macro expansion in readelf.c

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102867

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #7 from Martin Sebor <msebor at gcc dot gnu.org> ---
Fixed.