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

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> ---
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).