https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68413
--- Comment #6 from Ilya Enkovich <ienkovich at gcc dot gnu.org> --- I checked what is happening and seems the reason is in different STMT_VINFO_VEC_REDUCTION_TYPE (stmt_info) on analysis and transform phases. During analysis it is INTEGER_INDUC_COND_REDUCTION, for transformation it is COND_REDUCTION. Thus we have different flow for if-statement at tree-vect-loop.c:5653 whose branches have two major differences. 1. Different types are used to get optab. For analysis we get reduc_smax_scal_optab, for transformation we get reduc_umax_scal_optab. 2. Only 'true path' checks old optabs (with no _scal_) This bug was 'fixed' by r230423 which switched i386 target to new optabs, but problem still exist. Currently I see on trunk: Analysis: #0 optab_handler (op=reduc_smax_scal_optab, mode=V8SImode) at gcc/optabs-query.h:31 #1 0x0000000001023d5d in vectorizable_reduction (stmt=0x7ffff7f20660, gsi=0x0, vec_stmt=0x0, slp_node=0x0) at gcc/tree-vect-loop.c:5643 Transformation: #0 optab_handler (op=reduc_umax_scal_optab, mode=V8SImode) at gcc/optabs-query.h:31 #1 0x0000000001023fb1 in vectorizable_reduction (stmt=0x7ffff7f20660, gsi=0x7fffffffb600, vec_stmt=0x7fffffffb558, slp_node=0x0) at gcc/tree-vect-loop.c:5691 Note the same statements but different optabs used. Also we my still have ICE on targets not using new reduction optabs.