Is this a bug in the folder?

[Roger Sayle]

On Tue, 21 Sep 2004, Diego Novillo wrote:
> With a local patch, I am triggering an ice in NUMERICAL_TYPE_CHECK
> because it is trying to get the lower bound on a VECTOR_TYPE.
>
>       /* If we are widening one operand of an integer comparison,
>          see if the other operand is similarly being widened.  Perhaps we
>          can do the comparison in the narrower type.  */
>       else if (TREE_CODE (TREE_TYPE (arg0)) == INTEGER_TYPE
>                && TREE_CODE (arg0) == NOP_EXPR
>                && (tem = get_unwidened (arg0, NULL_TREE)) != arg0
>                && (code == EQ_EXPR || code == NE_EXPR
>                    || TYPE_UNSIGNED (TREE_TYPE (arg0))
>                       == TYPE_UNSIGNED (TREE_TYPE (tem)))
>               && (t1 = get_unwidened (arg1, TREE_TYPE (tem))) != 0
>                && (TREE_TYPE (t1) == TREE_TYPE (tem)
>                    || (TREE_CODE (t1) == INTEGER_CST
>                        && int_fits_type_p (t1, TREE_TYPE (tem)))))


Clearly this is a bug in the above logic.  Possible solutions are:

(1) Check that TREE_CODE (TREE_TYPE (tem)) == INTEGER_TYPE after
    the assignment of tem.

(2) Check that TREE_CODE (TREE_TYPE (tem)) == INTEGER_TYPE in
    the final condition immediately before the call to int_fits_type_p.

or slightly more effort

(3) Fix get_unwidened such that t1 is a VECTOR_CST of the approriate
    type and not an INTEGER_CST.  Unfortunately, fold_convert doesn't
    yet know how to convert an integer_cst into a vector_cst for values
    other than zero, however it would be useful functionality to have.
    See http://gcc.gnu.org/ml/gcc-patches/2004-09/msg00773.html

I suspect (2) is the safest short term solution to get your code working,
but ultimately (3) [and the reciprocal vector_cst to integer_cst] would
allow for better optimizations, for example, to enable constant folding
of your example comparison at compile-time.

Roger
--