https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106884
--- Comment #7 from Andrew Pinski ---
PR 111000 was similar one but for LIM.
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,
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.
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<
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
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,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106884
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
