[Bug libstdc++/109418] New: -Werror=maybe-uninitialized triggered by /usr/include/c++/12.2.1/bits/random.tcc

[Bug libstdc++/109418] New: -Werror=maybe-uninitialized triggered by /usr/include/c++/12.2.1/bits/random.tcc

[gareth-anthony-hulse at posteo dot net]

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

            Bug ID: 109418
           Summary: -Werror=maybe-uninitialized triggered by
                    /usr/include/c++/12.2.1/bits/random.tcc
           Product: gcc
           Version: 12.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gareth-anthony-hulse at posteo dot net
  Target Milestone: ---

Created attachment 54812
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54812&action=edit
Output of `make -B 2> /tmp/errors.txt`

`/usr/include/c++/12.2.1/bits/random.tcc` has variables that are possibly
uninitialised. The two culprits being line 1577: `double __x;` and line 1600:
`double __v;`. initialising them with a value such as 0, stops the complaints
from the compiler.

This bug triggers for me when compiling ImHex with commit version
89aee456c6cd897ea7e998340ded2004d3638412. The commit mentioned was supposed to
work around this issue, but had no effect. Attached log 'errors.txt' which is
an output from `make -B 2> /tmp/errors.txt`.

Specs: https://linux-hardware.org/?probe=201a4578ea

FLAGS:
 - CPPFLAGS = -D_FORTIFY_SOURCE=2
 - CXXFLAGS = -O3 -ftree-vectorize -floop-interchange -ftree-loop-distribution
-ftree-loop-linear -floop-parallelize-all -fgraphite-identity
-ftree-parallelize-loops=24 -floop-strip-mine -floop-block -fPIC
-ffat-lto-objects -flto-compression-level=9 -pipe -fno-signed-zeros
-fno-trapping-math -fno-plt -frename-registers -fstack-protector-all -flto=24
-pthread -DNDEBUG -fstack-clash-protection -fcf-protection=full
 - $LDFLAGS =
-Wl,-O3,-flto,--strip-all,--sort-common,--as-needed,-z,relro,-z,now,-z,defs
-pthread

[Bug libstdc++/109418] -Werror=maybe-uninitialized triggered by /usr/include/c++/12.2.1/bits/random.tcc

[xry111 at gcc dot gnu.org]

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

--- Comment #1 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Gareth Anthony Hulse from comment #0)
> Created attachment 54812 [details]
> Output of `make -B 2> /tmp/errors.txt`
> 
> `/usr/include/c++/12.2.1/bits/random.tcc` has variables that are possibly
> uninitialised. The two culprits being line 1577: `double __x;` and line
> 1600: `double __v;`. initialising them with a value such as 0, stops the
> complaints from the compiler.

No it's not the culprit.  It's obvious __x and __v are not used uninitialized
so it's a false warning.

But -Wmaybe-uninitialized creates false warnings in the nature (so it's named
*maybe*-uninitialized).  To me -Werror=maybe-uninitialized does not make any
sense.

[Bug libstdc++/109418] -Werror=maybe-uninitialized triggered by /usr/include/c++/12.2.1/bits/random.tcc

[xry111 at gcc dot gnu.org]

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

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|easyhack                    |
                 CC|                            |xry111 at gcc dot gnu.org

--- Comment #2 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
Remove "easyhack" to prevent anyone from submitting a patch zero-initializing
these variables to paper over the issue.

[Bug libstdc++/109418] -Werror=maybe-uninitialized triggered by /usr/include/c++/12.2.1/bits/random.tcc

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2023-04-11

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Waiting for a testcase, can you attach preprocessed source of the translation
unit exhibiting the issue (it's not clear from the build log which one that
is).