https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106063
Andrew Macleod <amacleod at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amacleod at redhat dot com
--- Comment #1 from Andrew Macleod <amacleod at redhat dot com> ---
That option enables legacy EVRP, and will be going away soon. however, looking
at the IL, the difference out of EVRP is that legacy doesnt touch the code. The
IL is:
vector(1) __int128 _1;
vector(1) <signed-boolean:128> _2;
V _4;
<bb 2> :
_1 = v_3(D) & { 15 };
_2 = v_3(D) == _1;
_4 = VEC_COND_EXPR <_2, { -1 }, { 0 }>;
return _4;
Ranger ends up triggering a simplification :
Folding statement: _2 = v_3(D) == _1;
gimple_simplified to _6 = v_3(D) & { -16 };
_2 = _6 == { 0 };
Folded into: _2 = _6 == { 0 };
producing:
_1 = v_3(D) & { 15 };
_6 = v_3(D) & { -16 };
_2 = _6 == { 0 };
_4 = VEC_COND_EXPR <_2, { -1 }, { 0 }>;
return _4;
Which ends up not causing the ICE seen in this PR.
However, if we completely disable EVRP, we also get the trap.
-O2 -fno-tree-forwprop --disable-tree-evrp
So it would seem the problem probably lies with vector expansion?
