https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122850
--- Comment #8 from Robin Dapp <rdapp at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #7) > --- gcc/tree-ssa-forwprop.cc.jj 2025-11-25 10:03:25.000000000 +0100 > +++ gcc/tree-ssa-forwprop.cc 2025-11-26 18:59:32.759692439 +0100 > @@ -4193,14 +4193,15 @@ simplify_vector_constructor (gimple_stmt > /* ??? See if we can convert the vector to the original type. */ > converted_orig1 = conv_code != ERROR_MARK; > unsigned n = converted_orig1 ? nelts : refnelts; > - tree_vector_builder vec (converted_orig1 > - ? type : perm_type, n, 1); > + tree vectype = converted_orig1 ? type : perm_type; > + tree eltype = TREE_TYPE (vectype); > + tree_vector_builder vec (vectype, n, 1); > for (unsigned i = 0; i < n; ++i) > if (i < nelts && constants[i]) > - vec.quick_push (constants[i]); > + vec.quick_push (fold_convert (eltype, constants[i])); > else > /* ??? Push a don't-care value. */ > - vec.quick_push (one_constant); > + vec.quick_push (fold_convert (eltype, one_constant)); > orig[1] = vec.build (); > } > tree blend_op2 = NULL_TREE; > fixes this exact ICE, but I really think the whole function needs careful > inspection on what will happen in type mismatches. > E.g. can't the r16-5561 changes make it possible for one_nonconstant to have > previously unexpected type and so shouldn't e.g. > orig[1] = gimple_build_vector_from_val (&stmts, UNKNOWN_LOCATION, > converted_orig1 > ? type : perm_type, > one_nonconstant); > deal with that? Or other spots? Yes, I'm on it. The control-flow isn't really obvious, though.
