https://bugs.kde.org/show_bug.cgi?id=381326
--- Comment #7 from John Reiser <jrei...@bitwagon.com> --- (In reply to Julian Seward from comment #6) > In particular I am trying to figure out if this can somehow be used to avoid > the problems shown at > https://bugs.llvm.org//show_bug.cgi?id=12319 > and > https://github.com/rust-lang/rust/issues/11710 The 0x45600000123 case (https://bugs.llvm.org//show_bug.cgi?id=12319#c2) is not related. Instead, it is "not-equal in any bit position where both operands have valid bits, implies not-equal for the whole word." As *presented*, the main Description for " if (!h(&a, &b) || a == 42 || b == 33)", namely https://bugs.llvm.org//show_bug.cgi?id=12319#c0 , is a bug in gcc. The code for h() is not shown, so it and its post-conditions are *unknown*. Therefore gcc must evaluate the if-expression according to the rules of C, namely left-to-right; but gcc evaluated the a==42 before the !result_of_h(). Besides, the dcache has latency, so it would be 1 to 3 cycles faster (and 3 bytes larger) to fetch 'a' first: call h mov 4(%rsp),%ecx // overlap cache latency; result might be unused testb %al,%al; je .LBB0_3 cmpl $42,%ecx; je .LBB0_3 The 'rust' case https://github.com/rust-lang/rust/issues/11710#issuecomment-33315140 is similarly muddled by imprecise presentation. "LLVM is allowed to generate undefined reads if it can not change the program behavior." memcheck does not complain about the Read, but about the Compare. -- You are receiving this mail because: You are watching all bug changes.
