https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93301
--- Comment #3 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 17 Jan 2020, ch3root at openwall dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93301 > > --- Comment #2 from Alexander Cherepanov <ch3root at openwall dot com> --- > The problem is much more serious. It's not that C has some guarantees about > two > values of `y` while gcc doesn't provide them. It's that one part of gcc > assumes > there are some guarantees about two values of `y` while another part of gcc > doesn't provide such guarantees. > > There were many discussions about "wobbly" values (DR 260, DR 451 etc.) and I > don't expect gcc to give the same values for two `y`s at all. The second value > is taken in the `else` branch, which we don't care about (at least while this > branch doesn't invoke UB). Given that `b` is `1` we know that the `then` > branch > is taken. > > It's surely possible to make this testcase undefined. If I understand them > correctly, llvm folks claim that "real compilers" (gcc included I assume) > follow rules that are more like C++ than C (see the linked clang bug report). > The C++ rules are much more strict and make `x == y` undefined if `y` is > uninitialized. > > But my guess is that the C++ rules will not help. The problem is the internal > inconsistency so everything will blow up independently of any external rules. But the first use of the undefined value in the comparison makes everything wobbly. GCC cannot definitely know the "definedness" unless it can track down an initialization chain to something definitely "defined" like a constant. What happens here is that GCC converts control dependence to data dependence which makes the "undefinedness" more appearant. But undefined behavior really means anything can happen, including wobbling.
