https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69207
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> --- 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. 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.
