https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69207
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #4)
> Seems there is a mismatch in between fold_convertible_p and
> verify_gimple_assign_unary (and also the gimplifier).
> E.g. for this special case fold_convertible_p has some weird exception:
> 2188 return (TREE_CODE (orig) == VECTOR_TYPE
> 2189 && tree_int_cst_equal (TYPE_SIZE (type), TYPE_SIZE
> (orig)));
> But verify_gimple_assign_unary certainly doesn't allow that. It has also
> various other restrictions, e.g. on pointer conversions etc.
> So, Richard, do we or should we have another predicate that says for outer
> and inner type if it is ok to use GIMPLE_ASSIGN with NOP_EXPR?
> Most of the uses that use fold_convertible_p in the middle-end actually
> perform fold_convert or fold_build1 (... NOP_EXPR, ...), which creates a
> NOP_EXPR from the VECTOR_TYPE to same sized integral type.
But that's invalid. fold_convert does
case VECTOR_TYPE:
if (integer_zerop (arg))
return build_zero_vector (type);
gcc_assert (tree_int_cst_equal (TYPE_SIZE (type), TYPE_SIZE (orig)));
gcc_assert (INTEGRAL_TYPE_P (orig) || POINTER_TYPE_P (orig)
|| TREE_CODE (orig) == VECTOR_TYPE);
return fold_build1_loc (loc, VIEW_CONVERT_EXPR, type, arg);
thus always creates a VCE.
Note that fold_build1 (... NOP_EXPR ...) is _not_ equivalent to
fold_convert (...)!
> Strangely, when
> trying to gimplify that it just creates a NOP_EXPR GIMPLE_ASSIGN, which then
> fails verification.
> So, what is the above mentioned 2188/2189 there for and corresponding
> fold_convert_loc:
> 2246 gcc_assert (TREE_CODE (orig) == VECTOR_TYPE
> 2247 && tree_int_cst_equal (TYPE_SIZE (type), TYPE_SIZE
> (orig)));
> 2248 return fold_build1_loc (loc, NOP_EXPR, type, arg);
> Shall it not create a VCE instead?
> Or shall it at least not gimplify to a VCE instead of a NOP_EXPR?
> For the tree-vect-slp.c case it is of course enough to just replace
> fold_convertible_p with INTEGRAL_TYPE_P && INTEGRAL_TYPE_P check, but I
> really think we should figure out what we want and have proper predicates
> for it.
I think on gimple we can't simply use fold_convertible_p because that has
special handling for a lot of cases where it doesn't end up generating
a NOP_EXPR. That is, if fold_convertible_p you can call fold_convert
without ICEing, you can't just build a NOP_EXPR gimple assign.
