On Tue, 15 Feb 2005, Richard Guenther wrote:
> Hi!
>
> I have isolated the patch (attached) that caused the previously reported
> build ICE and a testcase. The patch enables folding of
> &a[i] + cst to &a[i+cst] in addition to &a[i] + cst*j -> &a[i+j].
> If enabled, this transformation triggeres two times in the
> testcase derived from libiberty/sort.c:
>
> #define UCHAR_MAX ((unsigned char)(-1))
> #define DIGIT_MAX (UCHAR_MAX + 1)
>
> void sort_pointers (void)
> {
> unsigned int count[DIGIT_MAX];
> unsigned int *countp;
>
> for (countp = count + 1; countp < count + DIGIT_MAX; ++countp)
> ;
> }
Ok, stepping through PRE is seems that folding of &count[1]+1 at
tree-ssa-pre:1622 by calling fully_constant_expression on it
will get us &count[2] (obviously) and this one does not have a
value handle, and such we ICE. Wether fully_constant_expression
is in error, or the assert, I do not know. But I guess other
kind of folding could trigger this, too.
One could work around this either by removing the call to
fully_constant_expression or by wrapping this in sth like
tmp = fully_constant_expression (eprime);
vprime = get_value_handle (tmp);
if (!vprime)
vprime = get_value_handle (eprime);
else
eprime = tmp;
gcc_assert(vprime);
at least, this fixes the ICE.
Any ideas?
Thanks,
Richard.
--
Richard Guenther <richard dot guenther at uni-tuebingen dot de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
