> I see.  So I misremember seeing aggregate typed BIT_FIELD_REFs
> (that was probably VIEW_CONVERTs then...).  Still the GIMPLE verifier
> only has
> 
>           else if (!INTEGRAL_TYPE_P (TREE_TYPE (expr))
>                    && TYPE_MODE (TREE_TYPE (expr)) != BLKmode
>                    && maybe_ne (GET_MODE_BITSIZE (TYPE_MODE (TREE_TYPE
> (expr))),
>                                 size))
>             {
>               error ("mode size of non-integral result does not "
>                      "match field size of %qs",
>                      code_name);
>               return true;
>             }
> 
> it doesn't verify that besides integral typed expressions only
> vector typed expressions are allowed.

I think that the !INTEGRAL_TYPE_P is simply the opposite of the first case:

          if (INTEGRAL_TYPE_P (TREE_TYPE (t))
              && maybe_ne (TYPE_PRECISION (TREE_TYPE (t)), size))
            {
              error ("integral result type precision does not match "
                     "field size of BIT_FIELD_REF");
              return t;
            }

> Anyhow - the original patch succeeded bootstrapping and testing.
> The way I proposed it:
> 
>       /* For vector types, with the correct size of access, use the mode
> of
>          inner type.  */
>       if (((TREE_CODE (TREE_TYPE (TREE_OPERAND (exp, 0))) == VECTOR_TYPE
>             && TREE_TYPE (exp) == TREE_TYPE (TREE_TYPE (TREE_OPERAND (exp,
> 0))))
> 
>            || !INTEGRAL_TYPE_P (TREE_TYPE (exp)))
> 
>           && tree_int_cst_equal (size_tree, TYPE_SIZE (TREE_TYPE (exp))))
>         mode = TYPE_MODE (TREE_TYPE (exp));
> 
> matches in sofar that we only restrict integer types (not modes) and
> for integer types allow extracts from vectors (the preexisting
> check for a matching component type is a bit too strict I guess).

IMO if the !VECTOR_TYPE case cannot be covered, changes in this delicate area 
ought to be restricted to VECTOR_TYPE.

-- 
Eric Botcazou

Reply via email to