[Bug middle-end/68570] [6 Regression] ICE on valid code at -O1, -O2 and -O3 on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68570

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, we have:
basic block 13, loop depth 1
 pred:       11
_24 = (int) m_23(D);
i_lsm.22_91 = _24;
i_lsm.23_92 = 1;
_43 = _24 <= 0;
_45 = (int) _43;
 succ:       14

basic block 14, loop depth 1
 pred:       19
             13
# prephitmp_42 = PHI <pretmp_52(19), _24(13)>
# i_lsm.22_58 = PHI <i_lsm.22_57(19), i_lsm.22_91(13)>
# i_lsm.23_60 = PHI <i_lsm.23_59(19), i_lsm.23_92(13)>
if (prephitmp_42 != 0)
  goto <bb 20>;
else
  goto <bb 15>;
 succ:       20
             15

and #line 2164 "../../gcc/match.pd is applied, we get:
# prephitmp_42 = PHI <pretmp_52(19), _24(13)>
# i_lsm.22_58 = PHI <i_lsm.22_57(19), i_lsm.22_91(13)>
# i_lsm.23_60 = PHI <i_lsm.23_59(19), i_lsm.23_92(13)>
if (_24 != 0)
  goto <bb 20>;
else
  goto <bb 15>;
 succ:       20
             15

which is wrong IL, as _24 is is used in a bb not dominated by its definition.
Perhaps it is optimized this way because match.pd sees that bb19 is unreachable
or something similar, lots of the conditions are folded into 1 != 0 or 0 != 0.