[Bug tree-optimization/106063] [13 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 with -O2 -fno-tree-forwprop --param=evrp-mode=legacy-first

amacleod at redhat dot com gcc-bugzilla@gcc.gnu.org
Thu Jun 23 14:22:13 GMT 2022


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?


More information about the Gcc-bugs mailing list