[Bug middle-end/110228] [14 Regression] llvm-16 miscompiled due to an maybe uninitialized and optimizations saying that the uninitialized has a nonzero bits of 1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #15 from Jakub Jelinek --- (In reply to Andrew Pinski from comment #13) > has undefined behavior in it? Right now we remove the whole `!= 0` if we use > with -O2. Yes, it is UB. You'd need first array element of 0 to make it valid.
[Bug middle-end/110228] [14 Regression] llvm-16 miscompiled due to an maybe uninitialized and optimizations saying that the uninitialized has a nonzero bits of 1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228 --- Comment #14 from Sergei Trofimovich --- > LookupFlags = LookupFlags | t; That makes `LookupFlags` to guarantee to contain uninitialized bits. Did you mean `LookupFlags = t;`?
[Bug middle-end/110228] [14 Regression] llvm-16 miscompiled due to an maybe uninitialized and optimizations saying that the uninitialized has a nonzero bits of 1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228
--- Comment #13 from Andrew Pinski ---
The big question is this code here:
```
unsigned a[4] = {1,1,1,1};
__attribute__((noipa))
void sink(int){}
__attribute__((noipa))
static void bug(unsigned & p, unsigned *t, int n) {
bool LookupFlags ;
for(int i = 0; i < n; i++) {
unsigned v = t[i];
if (v == 0)
LookupFlags = 0;
else {
bool t = v == 1;
LookupFlags = LookupFlags | t;
}
sink(LookupFlags);
p = LookupFlags;
}
}
int main() {
unsigned r = 42;
bug(r,a, sizeof(a)/sizeof(a[0]));
__builtin_printf("%u\n", r);
if (r != 1) __builtin_abort();
}
```
has undefined behavior in it? Right now we remove the whole `!= 0` if we use
with -O2.
[Bug middle-end/110228] [14 Regression] llvm-16 miscompiled due to an maybe uninitialized and optimizations saying that the uninitialized has a nonzero bits of 1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228 --- Comment #12 from Andrew Pinski --- I should note my reduced testcase does not even need the ranger to tell me that the range is [0,1] because it uses a bool which has a PRECISION of 1. If an expand solution is not implemented in a few months, I will submit a patch which disables the `bit_ior` case and leave a comment there on referencing PR 71762 and this bug.
[Bug middle-end/110228] [14 Regression] llvm-16 miscompiled due to an maybe uninitialized and optimizations saying that the uninitialized has a nonzero bits of 1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228 --- Comment #11 from Andrew Pinski --- >From the duplicate bug report analysis: # RANGE [irange] short int [0, 1] NONZERO 0x1 # n_lsm.35_15 = PHI <_10(9), n_lsm.35_45(12)> ... # RANGE [irange] short int [0, 1] NONZERO 0x1 # n_lsm.35_45 = PHI # RANGE [irange] short int [0, 1] NONZERO 0x1 _10 = (short intD.17) _9; But the range of _69(D) is really undefined There is nothing phiopt/match is doing incorrectly due to the above, rather it is ranger that might be considering the wrong/incorrect information for uninitialized variables ...
[Bug middle-end/110228] [14 Regression] llvm-16 miscompiled due to an maybe uninitialized and optimizations saying that the uninitialized has a nonzero bits of 1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228 Andrew Pinski changed: What|Removed |Added CC||shaohua.li at inf dot ethz.ch --- Comment #10 from Andrew Pinski --- *** Bug 110286 has been marked as a duplicate of this bug. ***
[Bug middle-end/110228] [14 Regression] llvm-16 miscompiled due to an maybe uninitialized and optimizations saying that the uninitialized has a nonzero bits of 1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228 --- Comment #9 from Andrew Pinski --- That is these exports: 2->3 (T) c.5_7 : [irange] int [1334323000, +INF] NONZERO 0x7fff 2->3 (T) _8 : [irange] long unsigned int [1334323000, 2147483647] NONZERO 0x7fff 2->3 (T) b.6_9 : [irange] int [1334323000, +INF] NONZERO 0x7fff 2->3 (T) _10 : [irange] long unsigned int [1334323000, 2147483647] NONZERO 0x7fff 2->3 (T) _11 : [irange] long unsigned int [3481806647, 3481806649] NONZERO 0xcf88273f 2->3 (T) _12 : [irange] long unsigned int [0, 2] NONZERO 0x3 seems wrong. We originally had: c.5_7 = c; _8 = (long unsigned int) c.5_7; b.6_9 = b; _10 = (long unsigned int) b.6_9; _11 = _8 + _10; _12 = _11 + 18446744070227744969; if (_12 <= 2) so _11 export seems correct but _8 and _10 added together needs to be make _11. Since it is unsigned, the whole range for both numbers can make _11's range; that is we can't say anything about _8 or _10. Even if _11 is signed, I don't see how _8 and _10 could be described at all ... since _8 could be 0 and _10 could be 3481806647 and the range that is exported for _8 does not even include 0. Unless I am missing something obvious here.
[Bug middle-end/110228] [14 Regression] llvm-16 miscompiled due to an maybe uninitialized and optimizations saying that the uninitialized has a nonzero bits of 1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228 --- Comment #8 from Andrew Pinski --- So the `&` case with r14-1597-g64d90d06d2db43538c8a45 should be ok always I think as you are anding with a known non-uninitialized variable (that is always 0 or 1) that will produce a value which is known to be 0 or 1. It is one that produces `|` that exposes the issue here. Even if gimple level says it is 0/1, doing a `|` will produce an uninitialized value still and the upper bits are not defined and things go off in the weeds then.
[Bug middle-end/110228] [14 Regression] llvm-16 miscompiled due to an maybe uninitialized and optimizations saying that the uninitialized has a nonzero bits of 1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=71762 --- Comment #7 from Andrew Pinski --- bug 71762 comment #7 is very much related to the issue here (and maybe even the same).
