[Bug analyzer/105961] New: -Wanalyzer-use-of-uninitialized-value false positive after "= {0}"

[Bug analyzer/105961] New: -Wanalyzer-use-of-uninitialized-value false positive after "= {0}"

[eggert at cs dot ucla.edu]

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

            Bug ID: 105961
           Summary: -Wanalyzer-use-of-uninitialized-value false positive
                    after "= {0}"
           Product: gcc
           Version: 12.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: analyzer
          Assignee: dmalcolm at gcc dot gnu.org
          Reporter: eggert at cs dot ucla.edu
  Target Milestone: ---

This is gcc (GCC) 12.1.1 20220507 (Red Hat 12.1.1-1) on x86-64. I do not
observe the bug with gcc-12 (Ubuntu 12-20220319-1ubuntu1) 12.0.1 20220319
(experimental) [master r12-7719-g8ca61ad148f] on x86-64.

Compile the attached program (derived from bleeding-edge Emacs) with:

gcc -O2 -S -fanalyzer t.i

GCC complains:

In function ‘dump_mmap_release’,
    inlined from ‘pdumper_load’ at t.i:50527:5:
t.i:49512:10: warning: use of uninitialized value ‘sections[i].release’
[CWE-457] [-Wanalyzer-use-of-uninitialized-value]
49512 |   if (map->release)
      |       ~~~^~~~~~~~~
  ‘pdumper_load’: events 1-9
    |
    |50318 | pdumper_load (const char *dump_filename, char *argv0)
    |      | ^~~~~~~~~~~~
    |      | |
    |      | (1) entry to ‘pdumper_load’
    |......
    |50331 |   struct dump_memory_map sections[NUMBER_DUMP_SECTIONS] = { 0 };
    |      |                          ~~~~~~~~
    |      |                          |
    |      |                          (2) region created on stack here
    |......


The region is obviously initialized, via the "= { 0 }" at the end. The
following change pacifies GCC, but should not be necessary.

--- t.i 2022-06-13 13:06:59.000000000 -0700
+++ u.i 2022-06-13 13:09:18.000000000 -0700
@@ -50329,6 +50329,7 @@
   struct dump_header header_buf = { 0 };
   struct dump_header *header = &header_buf;
   struct dump_memory_map sections[NUMBER_DUMP_SECTIONS] = { 0 };
+  memset (sections, 0, sizeof sections);

   const struct timespec start_time = current_timespec ();
   char *dump_filename_copy;

[Bug analyzer/105961] -Wanalyzer-use-of-uninitialized-value false positive after "= {0}"

[dmalcolm at gcc dot gnu.org]

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

--- Comment #1 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
(In reply to eggert from comment #0)

[...snip...]

> Compile the attached program (derived from bleeding-edge Emacs) with:

I'm not seeing an attachment - do you still have this file, and can you try
attaching it again please?

Thanks!

[...snip...]

[Bug analyzer/105961] -Wanalyzer-use-of-uninitialized-value false positive after "= {0}"

[eggert at cs dot ucla.edu]

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

--- Comment #2 from eggert at cs dot ucla.edu ---
Created attachment 53131
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53131&action=edit
reproducer for the bug (compressed with xz)

The uncompressed t.i was too large for bugzilla, so here's the same file,
compressed with xz.

[Bug analyzer/105961] -Wanalyzer-use-of-uninitialized-value false positive after "= {0}"

[dmalcolm at gcc dot gnu.org]

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

David Malcolm <dmalcolm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2022-06-13
     Ever confirmed|0                           |1

--- Comment #3 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Thanks - I can see the reproduce the bug with that (tested with trunk).

[Bug analyzer/105961] -Wanalyzer-use-of-uninitialized-value false positive after "= {0}"

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
As well as the false positive, the diagnostic path is rather unreadable due to
inlining.  I've filed a separate bug about this (PR 105962).

[Bug analyzer/105961] -Wanalyzer-use-of-uninitialized-value false positive after "= {0}"

[dmalcolm at gcc dot gnu.org]

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

David Malcolm <dmalcolm at gcc dot gnu.org> changed:

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

--- Comment #5 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
I tried this again on Compiler Explorer, but I'm now not seeing any output on
the reproducer:

Trunk: https://godbolt.org/z/G8fravbbT
GCC 13.2: https://godbolt.org/z/8aj7zTssG
GCC 12.3: https://godbolt.org/z/6v15Es3nc
GCC 11.4: https://godbolt.org/z/hxPdxGTr9

Marking as RESOLVED WORKSFORME.  Feel free to reopen if you're still able to
reproduce this.