This is the mail archive of the
mailing list for the GCC project.
Re: Is this a bug in the folder?
- From: Roger Sayle <roger at eyesopen dot com>
- To: Diego Novillo <dnovillo at redhat dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Richard Henderson <rth at redhat dot com>
- Date: Tue, 21 Sep 2004 09:27:30 -0600 (MDT)
- Subject: Re: Is this a bug in the folder?
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.
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.