[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
