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).
