[Bug tree-optimization/101912] -Wmaybe-uninitialized false alarm in tzdb localtime.c

["aldyh at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at gcc dot gnu.org

--- Comment #6 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #5)
> On Tue, 30 Nov 2021, eggert at cs dot ucla.edu wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101912
> > 
> > --- Comment #4 from eggert at cs dot ucla.edu ---
> > (In reply to Aldy Hernandez from comment #3)
> > > >               && !(leapcnt == 0
> > > >                    || (prevcorr < corr
> > > >                        ? corr == prevcorr + 1
> > > >                        : (corr == prevcorr
> > > >                           || corr == prevcorr - 1)))))
> > > > 
> > > 
> > > I guess the question is whether language rules allow us to read prevcorr
> > > when leapcnt== 0?
> > 
> > The C language rules do not allow that. When leapcnt is zero, behavior must be
> > as if the prevcorr expression is not evaluated.
> > 
> > Although the compiler can generate machine code that evaluates prevcorr at the
> > machine level (so long as the observable behavior is the same, which is the
> > case as prevcorr is not volatile and no untoward behavior can result from
> > evaluating the prevcorr expression), it's incorrect if the compiler warns the
> > programmer that prevcorr is used uninitialized.
> 
> Correct.  I think we have quite some duplicates around this issue
> of making short-circuiting conditionals not short-circuiting (we do
> that even early during GENERIC folding).  "Proving" that all participating
> sub-expressions are fully initialized is impossible so the only
> reasonable way to "fix" the issue (the uninit warnings) might be
> to mark the now unconditionally evaluated sub-expressions with
> -Wno-uninitialized (aka no-warning or suppress uninit warnings).

If this isn't something we are going to fix then by all means, mark them all as
-Wno-uninitialized.  I'm for whatever reduces the false positive rates in this
area :).