[Bug tree-optimization/106884] ifcombine may move shift so it shifts more than bitwidth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106884 --- Comment #7 from Andrew Pinski --- PR 111000 was similar one but for LIM.
[Bug tree-optimization/106884] ifcombine may move shift so it shifts more than bitwidth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106884 --- Comment #6 from Krister Walfridsson --- One more similar case (that may be the same as comment #3): int g; void foo(int a, int b, int c, int d, int e) { if ((10 + a) * b) { g = (c || (g >> d)) << 1; } } In this case, reassoc1 optimizes the IR for c || (g >> d) to do (c | (g >> d)) != 0 and we are now always doing the shift, even when c is true.
[Bug tree-optimization/106884] ifcombine may move shift so it shifts more than bitwidth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106884 --- Comment #5 from Andrew Pinski --- (In reply to Richard Biener from comment #4) > But yes, since we now unconditionally compute 1< GCC could assume b is in range. We are lacking a way to compute 1< optimally without that undefined behavior. phiopt will almost definitely run into a similar thing though right now, it has not.
[Bug tree-optimization/106884] ifcombine may move shift so it shifts more than bitwidth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106884 --- Comment #4 from Richard Biener --- To clarify for the original testcase, ifcombine combines the two bit tests (x & (1<
[Bug tree-optimization/106884] ifcombine may move shift so it shifts more than bitwidth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106884 --- Comment #3 from Krister Walfridsson --- A similar case is int r1, r2; int foo(int a, int s1, int s2) { if (a & (1 << s1)) return r1; if (a & (1 << s2)) return r1; return r2; } where reassoc2 optimizes this to always shift by s2.
[Bug tree-optimization/106884] ifcombine may move shift so it shifts more than bitwidth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106884 --- Comment #2 from Krister Walfridsson --- This optimization is invalid if (int)1 << 33 is _not_ undefined behavior in GIMPLE! Consider an architecture where (int)1 << 33 evaluates to 0. foo(2, 1, 33) evaluates to 0 for the original GIMPLE, but it evaluates to 2 in the optimized IR.
[Bug tree-optimization/106884] ifcombine may move shift so it shifts more than bitwidth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106884 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Keywords||wrong-code Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-09-08 Depends on||106811 --- Comment #1 from Richard Biener --- Confirmed. r13-131-gc2a0d2e6f636c6 addressed some issues, but leaves others such as shifts seen here. It's not clear if (int)1 << 33 is undefined behavior in GIMPLE, see PR106811. Note that ifcombine doesn't simply transform this to (x & c) & (x & (1 << b)), thus removing the short-circuiting, instead it computes tem = c | (1