https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122478
--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Artemiy Volkov from comment #7)
> FWIW, I have
>
> diff --git a/gcc/match.pd b/gcc/match.pd
> index 00493d6ad99..88216c7ee53 100644
> --- a/gcc/match.pd
> +++ b/gcc/match.pd
> @@ -5658,10 +5658,10 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
>
> /* Squash view_converts of BFRs if no precision is lost. */
> (simplify
> - (view_convert (BIT_FIELD_REF @1 @2 @3))
> + (view_convert (BIT_FIELD_REF@0 @1 @2 @3))
> (if (is_gimple_reg_type (type)
> && (!INTEGRAL_TYPE_P (type)
> - || type_has_mode_precision_p (type)))
> + || TYPE_PRECISION (type) == TYPE_PRECISION (TREE_TYPE (@0))))
> (BIT_FIELD_REF:type @1 @2 @3)))
>
> /* For integral conversions with the same precision or pointer
>
> spinning on everything at the moment. (As you say, this will provide
> type_has_mode_precision_p (TREE_TYPE (@0)) implicitly.)
I am thinking if this could fail. For an example extracting a vector from a
vector could cause TYPE_PRECISION to ICE.
That is:
```
#define vect4 __attribute__((vector_size(4)))
#define vect8 __attribute__((vector_size(8)))
int f(vect8 int a)
{
vect4 int b = __builtin_shufflevector (a, a, 0);
return (int)b;
}
```
Which gives us:
```
b_2 = BIT_FIELD_REF <a_1(D), 32, 0>;
_3 = VIEW_CONVERT_EXPR<int>(b_2);
```
