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 rguent...@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 :).
