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

2023-06-17 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment

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

2023-06-17 Thread slyfox at gcc dot gnu.org via Gcc-bugs
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.

2023-06-17 Thread pinskia at gcc dot gnu.org via Gcc-bugs
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

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

2023-06-17 Thread pinskia at gcc dot gnu.org via Gcc-bugs
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

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

2023-06-16 Thread pinskia at gcc dot gnu.org via Gcc-bugs
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

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

2023-06-16 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228 Andrew Pinski changed: What|Removed |Added CC||shaohua.li at inf dot ethz.ch ---

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

2023-06-14 Thread pinskia at gcc dot gnu.org via Gcc-bugs
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 :

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

2023-06-12 Thread pinskia at gcc dot gnu.org via Gcc-bugs
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

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

2023-06-12 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill