http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334
--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-11-16
14:17:00 UTC ---
(In reply to comment #12)
> so a "better" c case is
> float * mem;
> void sumN(int n) {
> float * a=mem;
> /*const*/ float * b=mem+n;
> /*const*/ float * c=mem+2*n;
> for (int i=0;i!=n;++i)
> a[i]=b[i]+c[i];
> }
Without const and with constant n GCC already does the right thing. With
non-constant n it is a different thing, then we have
base_object: *&mem + (long unsigned int) n_3(D) * 4
base_object: *&mem + (long unsigned int) (n_3(D) * 2) * 4
base_object: MEM[(float *)&mem]
and obviously it doesn't operand_equal_p either. Not sure if in that case
we couldn't move (long unsigned int) n_3(D) * 4 resp. (long unsigned int)
(n_3(D) * 2) * 4 from the base object to the access function, so it would be
instead of
Access function 0: {0B, +, 4}_1
say
Access function 0: {n_3(D) * 4, +, 4}_1
and whether rest of data-ref etc. code would handle that properly.
