Bug 102867 - [12 Regression] -Waddress from macro expansion in readelf.c
Summary: [12 Regression] -Waddress from macro expansion in readelf.c
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 12.0
: P3 normal
Target Milestone: 12.0
Assignee: Martin Sebor
URL:
Keywords: diagnostic, patch
Depends on:
Blocks:
 
Reported: 2021-10-21 04:53 UTC by Alan Modra
Modified: 2021-11-19 16:50 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2021-10-21 00:00:00


Attachments
preprocessed source (229.95 KB, application/gzip)
2021-10-21 04:55 UTC, Alan Modra
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alan Modra 2021-10-21 04:53:23 UTC
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.
Comment 1 Alan Modra 2021-10-21 04:55:15 UTC
Created attachment 51641 [details]
preprocessed source
Comment 2 Richard Biener 2021-10-21 06:32:22 UTC
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.
Comment 3 Alan Modra 2021-10-21 06:58:41 UTC
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.
Comment 4 Martin Sebor 2021-10-21 16:16:23 UTC
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.
Comment 6 GCC Commits 2021-11-19 16:48:28 UTC
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.
Comment 7 Martin Sebor 2021-11-19 16:50:10 UTC
Fixed.