Re: [PATCH] Fix PR21082 for C++

[Richard Guenther <richard dot guenther at gmail dot com>]

On 4/25/05, Richard Henderson <rth@redhat.com> wrote:
> On Mon, Apr 25, 2005 at 11:11:20AM +0200, Richard Guenther wrote:
> > Well, I neither see pointers nor multiplication involved here ;)
> 
> Um, multiplication certainly is: (i-j)*sizeof(T).

Uh, yes, sorry.  I missed that ;)

> 
> And you're saying that you've already got the ptrdiff_t, and are
> not in fact looking at the type of &a[i], which is still a pointer?

>From what I saw as trees coming in, I concluded that the middle-end does
not do pointer arithmetic for pointer difference, but only arithmetic on
appropriate integer types.  So, yes, I'm not looking at the type of
&a[i], but directly take i and j and cast them to the result type which
will be a signed integer type.

> If so, then that's fine, but I wouldn't have expected that to be true.

Well, pointer arithmetic is restricted to pointer difference in C, and this
results in a signed integer type.  Both C and C++ seem to "lower"
&a[i] - &a[j] to ((int)&a[i] - (int)&a[j]) / 4.  Wether the middle-end should
cope with &a[i]-&a[j] directly is beyond me - at least the result type
would have to be a pointer and then I question the semantics of the
operation.

> > ... is TYPE_DOMAIN guaranteed to exist?
> 
> No.  It'll be missing for "extern int a[];".

So just castsing to TYPE_DOMAIN is not going to work either.  For
further optimization purposes one could avoid casting the operands
of the MINUS_EXPR if the types match, likewise for the MULT_EXPR
and only cast the return values.  But this wouldn't change anything
from the correctness perspective.

richard.