https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123107
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rguenth at gcc dot gnu.org
Priority|P3 |P2
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
#1 0x000000000180dcb8 in prepare_cmp_insn (x=0x7ffff6649330,
y=0x7ffff6809c60, mask=0x0, comparison=LT, size=0x0, unsignedp=0,
methods=OPTAB_LIB_WIDEN, ptest=0x7fffffffab28, pmode=0x7fffffffaa88,
optab=cbranch_optab) at ../../src/gcc/gcc/optabs.cc:4589
4589 gcc_assert (libfunc);
(gdb) p debug_rtx (x)
(reg/v:V16HI 100 [ BS_TEMP_206 ])
$1 = void
(gdb) p debug_rtx (y)
(const_vector:V16HI [
(const_int 0 [0]) repeated x16
])
expanded from
_36 = BS_TEMP_206_34(D) < { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
We start having vector operations in FRE5 which transforms
_40 = .REDUC_IOR (_39);
_32 = _40;
_36 = _32 != 0;
into
_1 = BS_TEMP_206_34(D) >> 15;
_36 = _1 != { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
with some match.pd pattern. Later forwprop4 turns this into
_36 = BS_TEMP_206_34(D) < { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
but not with a match.pd pattern. Disabling forwprop4 fixes this so this
simplification is invalid as not supported by the target.
