[Bug tree-optimization/110461] [14 regression] ICE when building openh264 with new vector_type checking

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110461

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #4)
> Yes it is that pattern, specifically :
> /* Try to fold (type) X op CST -> (type) (X op ((type-x) CST))
>    when profitable.
>    For bitwise binary operations apply operand conversions to the
>    binary operation result instead of to the operands.  This allows
>    to combine successive conversions and bitwise binary operations.
>    We combine the above two cases by using a conditional convert.  */
> (for bitop (bit_and bit_ior bit_xor)
>  (simplify
>   (bitop (convert@2 @0) (convert?@3 @1))
>   (if (((TREE_CODE (@1) == INTEGER_CST
>          && INTEGRAL_TYPE_P (TREE_TYPE (@0))
>          && (int_fits_type_p (@1, TREE_TYPE (@0))
>              || tree_nop_conversion_p (TREE_TYPE (@0), type)))
>         || types_match (@0, @1))
>        && !POINTER_TYPE_P (TREE_TYPE (@0))
>        && TREE_CODE (TREE_TYPE (@0)) != OFFSET_TYPE
>        /* ???  This transform conflicts with fold-const.cc doing
>           Convert (T)(x & c) into (T)x & (T)c, if c is an integer
>           constants (if x has signed type, the sign bit cannot be set
>           in c).  This folds extension into the BIT_AND_EXPR.
>           Restrict it to GIMPLE to avoid endless recursions.  */
>        && (bitop != BIT_AND_EXPR || GIMPLE)
>        && (/* That's a good idea if the conversion widens the operand, thus
>               after hoisting the conversion the operation will be narrower.
>               It is also a good if the conversion is a nop as moves the
>               conversion to one side; allowing for combining of the
> conversions.  */
>            TYPE_PRECISION (TREE_TYPE (@0)) < TYPE_PRECISION (type)
>            /* The conversion check for being a nop can only be done at the
> gimple
>               level as fold_binary has some re-association code which can
> conflict
>               with this if there is a "constant" which is not a full
> INTEGER_CST.  */
>            || (GIMPLE && TYPE_PRECISION (TREE_TYPE (@0)) == TYPE_PRECISION
> (type))
> 
> Those 2 above TYPE_PRECISION .

For vectors this also lacks a check the resulting bit operation is supported.
I'm testing a patch.