Re: latent bug in PRE?

[Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>]

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/