[Bug c/97100] New: -Wformat checks all arms of _Generic leading to irrelevant type expectation warnings

[Bug c/97100] New: -Wformat checks all arms of _Generic leading to irrelevant type expectation warnings

[sherzberg+gcc at freeshell dot org]

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

            Bug ID: 97100
           Summary: -Wformat checks all arms of _Generic leading to
                    irrelevant type expectation warnings
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: sherzberg+gcc at freeshell dot org
  Target Milestone: ---

Created attachment 49238
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49238&action=edit
preprocessed output

The Wformat printf/scanf checker will produce warnings for all arms of a
generic expression, even those which will not be included in the program. This
can produce a fairly large number of warnings, since the macro below will
produce a warning for many of its arms for each use of the macro.

This is sort of code used in _Generic tutorials, and mostly nowhere else, that
can produce a large number of irrelevant warnings:

#define DISPLAY(x) \
    _Generic(x, int: printf("%d\r\n", x), \
                char: printf("%c\r\n", x), \
                float: printf("%.3f\r\n", x))


$ gcc-10 -v -save-temps -Wall generic_test.c 
Using built-in specs.
COLLECT_GCC=gcc-10
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
10-20200411-0ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-10
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none,amdgcn-amdhsa,hsa --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.1 20200411 (experimental) [master revision
bb87d5cc77d:75961caccb7:f883c46b4877f637e0fa5025b4d6b5c9040ec566] (Ubuntu
10-20200411-0ubuntu1) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/10/cc1 -E -quiet -v -imultiarch x86_64-linux-gnu
generic_test.c -mtune=generic -march=x86-64 -Wall -fpch-preprocess
-fasynchronous-unwind-tables -fstack-protector-strong -Wformat-security
-fstack-clash-protection -fcf-protection -o generic_test.i
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/10/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/10/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-linux-gnu/10/include
 /usr/local/include
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/10/cc1 -fpreprocessed generic_test.i -quiet
-dumpbase generic_test.c -mtune=generic -march=x86-64 -auxbase generic_test
-Wall -version -fasynchronous-unwind-tables -fstack-protector-strong
-Wformat-security -fstack-clash-protection -fcf-protection -o generic_test.s
GNU C17 (Ubuntu 10-20200411-0ubuntu1) version 10.0.1 20200411 (experimental)
[master revision
bb87d5cc77d:75961caccb7:f883c46b4877f637e0fa5025b4d6b5c9040ec566]
(x86_64-linux-gnu)
        compiled by GNU C version 10.0.1 20200411 (experimental) [master
revision bb87d5cc77d:75961caccb7:f883c46b4877f637e0fa5025b4d6b5c9040ec566], GMP
version 6.2.0, MPFR version 4.0.2, MPC version 1.1.0, isl version
isl-0.22.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C17 (Ubuntu 10-20200411-0ubuntu1) version 10.0.1 20200411 (experimental)
[master revision
bb87d5cc77d:75961caccb7:f883c46b4877f637e0fa5025b4d6b5c9040ec566]
(x86_64-linux-gnu)
        compiled by GNU C version 10.0.1 20200411 (experimental) [master
revision bb87d5cc77d:75961caccb7:f883c46b4877f637e0fa5025b4d6b5c9040ec566], GMP
version 6.2.0, MPFR version 4.0.2, MPC version 1.1.0, isl version
isl-0.22.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: d7d6d629e7a95e97eb10596483b5a39e
generic_test.c: In function ‘main’:
generic_test.c:10:32: warning: format ‘%d’ expects argument of type ‘int’, but
argument 2 has type ‘double’ [-Wformat=]
   10 |     DISPLAY(1.0f);
      |                                ^             
      |                                          |
      |                                          double
generic_test.c:10:62: warning: format ‘%c’ expects argument of type ‘int’, but
argument 2 has type ‘double’ [-Wformat=]
   10 |     DISPLAY(1.0f);
      |                                                              ^          
      |                                                                       
|
      |                                                                       
double
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-mtune=generic' '-march=x86-64'
 as -v --64 -o generic_test.o generic_test.s
GNU assembler version 2.34 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.34
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/10/:/usr/lib/gcc/x86_64-linux-gnu/10/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/10/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/10/:/usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/10/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/10/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/10/collect2 -plugin
/usr/lib/gcc/x86_64-linux-gnu/10/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper
-plugin-opt=-fresolution=generic_test.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id
--eh-frame-hdr -m elf_x86_64 --hash-style=gnu --as-needed -dynamic-linker
/lib64/ld-linux-x86-64.so.2 -pie -z now -z relro
/usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/Scrt1.o
/usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/crti.o
/usr/lib/gcc/x86_64-linux-gnu/10/crtbeginS.o -L/usr/lib/gcc/x86_64-linux-gnu/10
-L/usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu
-L/usr/lib/gcc/x86_64-linux-gnu/10/../../../../lib -L/lib/x86_64-linux-gnu
-L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib
-L/usr/lib/gcc/x86_64-linux-gnu/10/../../.. generic_test.o -lgcc --push-state
--as-needed -lgcc_s --pop-state -lc -lgcc --push-state --as-needed -lgcc_s
--pop-state /usr/lib/gcc/x86_64-linux-gnu/10/crtendS.o
/usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/crtn.o
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-mtune=generic' '-march=x86-64'

[Bug c/97100] -Wformat checks all arms of _Generic leading to irrelevant type expectation warnings

[Hi-Angel at yandex dot ru]

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

Konstantin Kharlamov <Hi-Angel at yandex dot ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Hi-Angel at yandex dot ru

--- Comment #1 from Konstantin Kharlamov <Hi-Angel at yandex dot ru> ---
Still relevant. Just stumbled upon it in 13.1.1, was about to report a bug.

[Bug c/97100] -Wformat checks all arms of _Generic leading to irrelevant type expectation warnings

[muecker at gwdg dot de]

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

Martin Uecker <muecker at gwdg dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |muecker at gwdg dot de

--- Comment #2 from Martin Uecker <muecker at gwdg dot de> ---
PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626319.html

[Bug c/97100] -Wformat checks all arms of _Generic leading to irrelevant type expectation warnings

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:54be338589ea93ad4ff53d22adde476a0582537b

commit r14-3004-g54be338589ea93ad4ff53d22adde476a0582537b
Author: Martin Uecker <uecker@tugraz.at>
Date:   Fri Aug 4 07:48:21 2023 +0200

    c: _Generic should not warn in non-active branches
[PR68193,PR97100,PR110703]

    To avoid false diagnostics, use c_inhibit_evaluation_warnings when
    a generic association is known to not match during parsing.  We may
    still generate false positives if the default branch comes earler than
    a specific association that matches.

    PR c/68193
    PR c/97100
    PR c/110703

    gcc/c/:
            * c-parser.cc (c_parser_generic_selection): Inhibit evaluation
            warnings branches that are known not be taken during parsing.

    gcc/testsuite/ChangeLog:
            * gcc.dg/pr68193.c: New test.

[Bug c/97100] -Wformat checks all arms of _Generic leading to irrelevant type expectation warnings

[uecker at gcc dot gnu.org]

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

uecker at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.0
      Known to fail|                            |4.9.0
                 CC|                            |uecker at gcc dot gnu.org
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #4 from uecker at gcc dot gnu.org ---
Fixed on trunk.

[Bug c/97100] -Wformat checks all arms of _Generic leading to irrelevant type expectation warnings

[alx at kernel dot org]

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

Alejandro Colomar <alx at kernel dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alx at kernel dot org

--- Comment #5 from Alejandro Colomar <alx at kernel dot org> ---
I can still reproduce it, using gcc-14 from Debian RC-Buggy.


alx@debian:~/tmp/c$ gcc-14 -Wall -Wextra g.c -S
g.c: In function ‘main’:
g.c:96:21: error: passing argument 1 of ‘a2si_c’ from incompatible pointer type
[-Wincompatible-pointer-types]
   96 |         a2i(time_t, &t, "42", NULL, 0, 0, 10);
      |                     ^~
      |                     |
      |                     time_t * {aka long int *}
g.c:30:11: note: in definition of macro ‘a2si’
   30 |         )(n, s, endp, base, min, max)                                  
      \
      |           ^
g.c:96:9: note: in expansion of macro ‘a2i’
   96 |         a2i(time_t, &t, "42", NULL, 0, 0, 10);
      |         ^~~
g.c:54:22: note: expected ‘int * restrict’ but argument is of type ‘time_t *’
{aka ‘long int *’}
   54 | a2si_c(int *restrict n, const char *s,
      |        ~~~~~~~~~~~~~~^
alx@debian:~/tmp/c$ gcc-14 --version
gcc-14 (Debian 14-20240330-1) 14.0.1 20240330 (experimental) [master
r14-9728-g6fc84f680d0]
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug c/97100] -Wformat checks all arms of _Generic leading to irrelevant type expectation warnings

[alx at kernel dot org]

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

--- Comment #6 from Alejandro Colomar <alx at kernel dot org> ---
Oh well, in my case it is -Wincompatible-pointer-types.  Maybe the fix was only
for -Wformat.

[Bug c/97100] -Wformat checks all arms of _Generic leading to irrelevant type expectation warnings

[uecker at gcc dot gnu.org]

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

--- Comment #7 from uecker at gcc dot gnu.org ---

The fix suppresses certain warnings which are guarded by a flag, but it is not
always clear whether a specific warning should be suppressed or not in dead
code. 

You could also always add a cast.

Fundamentally, the program is that _Generic is not ideally designed for this
use case. One could consider an extension

_Generic(x, int i: f(i), long l: g(l));

that allows referring to the first argument with the type it would have in each
branch.

[Bug c/97100] -Wformat checks all arms of _Generic leading to irrelevant type expectation warnings

[Hi-Angel at yandex dot ru]

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

--- Comment #8 from Konstantin Kharlamov <Hi-Angel at yandex dot ru> ---
(In reply to uecker from comment #7)
> Fundamentally, the program is that _Generic is not ideally designed for this
> use case. 

Why?

> One could consider an extension
> 
> _Generic(x, int i: f(i), long l: g(l));
> 
> that allows referring to the first argument with the type it would have in
> each branch.

Unless I'm missing something, a compiler already knows if `x` is an `int` or
`long`. I see no benefit in devising such extension.

[Bug c/97100] -Wformat checks all arms of _Generic leading to irrelevant type expectation warnings

[uecker at gcc dot gnu.org]

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

--- Comment #9 from uecker at gcc dot gnu.org ---

x is - according to the C standard - always whatever it is in the controlling
expression.   Some warnings are then even required to be standard compliant.

Note that this also does not have to be an identifier, but could be a complex
expression.  So there seems no simply algorithm  for a compiler to do the right
thing in general regarding warnings.

[Bug c/97100] -Wformat checks all arms of _Generic leading to irrelevant type expectation warnings

[Hi-Angel at yandex dot ru]

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

--- Comment #10 from Konstantin Kharlamov <Hi-Angel at yandex dot ru> ---
(In reply to uecker from comment #9)
> Some warnings are then even required to be standard compliant.

I just searched through the C standard and no warnings seem to be required by
it. The only place where word "warning" is mentioned is in the Annex Ⅰ, which
tilted as "informative" and only serves as an example of where warnings might
be useful.

> x is - according to the C standard - always whatever it is in the controlling
> expression.

With the prev. paragraph in mind, compiler is free to warn or not to about
anything. The only (arguable) limitation is being useful. So nothing holds a
compiler off from considering for the warning purposes the `x` to have
different types on the outside of _Generic() compared to the inside.

> Note that this also does not have to be an identifier, but could be a complex
> expression. So there seems no simply algorithm for a compiler to do the right thing
> in general regarding warnings.

Idk why complexity matters, it's not like `x` is dynamically typed, so no
solving halting problem requried. For me it looks simple: if `x` entered either
branch of _Generic, just consider it to have a type different from what it was
and produce correct warnings 😊

[Bug c/97100] -Wformat checks all arms of _Generic leading to irrelevant type expectation warnings

[muecker at gwdg dot de]

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

--- Comment #11 from Martin Uecker <muecker at gwdg dot de> ---

A conforming C compiler has to diagnose all violations of constraints with the
same correct type of x in all branches (not the type it would have in another
context where a different is taken).

[Bug c/97100] -Wformat checks all arms of _Generic leading to irrelevant type expectation warnings

[Hi-Angel at yandex dot ru]

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

--- Comment #12 from Konstantin Kharlamov <Hi-Angel at yandex dot ru> ---
(In reply to Martin Uecker from comment #11)
> A conforming C compiler has to diagnose all violations of constraints with
> the same correct type of x in all branches (not the type it would have in
> another context where a different is taken).

As mentioned in my prev. comment, a conforming C compiler don't have to
diagnose anything at all. And in fact, GCC doesn't even diagnose anything, well
not unless you explicitly pass a -Wfoo. Which doesn't make GCC any less
conforming. Thus, I see no constraints to printing warnings that are useful.

[Bug c/97100] -Wformat checks all arms of _Generic leading to irrelevant type expectation warnings

[muecker at gwdg dot de]

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

--- Comment #13 from Martin Uecker <muecker at gwdg dot de> ---
A C compiler has to diagnose all constraint violations. Alternatively, it could
also reject the program with an error.

[Bug c/97100] -Wformat checks all arms of _Generic leading to irrelevant type expectation warnings

[alx at kernel dot org]

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

--- Comment #14 from Alejandro Colomar <alx at kernel dot org> ---
Hi Martin,

For the discussion of my -Wincompatible-pointer-types reproducer, please visit
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114731>.  I'll reply to you
there, since it's more on-topic, and also, I posted there the full reproducer.

Have a lovely day!
Alex