This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: should MEM tracking be able to optimize this?
On Sun, Nov 18, 2001 at 04:50:59PM -0200, Alexandre Oliva wrote:
> On Nov 18, 2001, Zack Weinberg <zack@codesourcery.com> wrote:
>
> > On Sun, Nov 18, 2001 at 12:30:11PM -0200, Alexandre Oliva wrote:
> >> On Nov 18, 2001, kenner@vlsi1.ultra.nyu.edu (Richard Kenner) wrote:
> >>
> >> > struct foo { float a[2048], b[2048]; }
> >>
> >> > It's obvious statically that X.a[i] and Y.b[j] can never conflict for any
> >> > expressions X and Y of type struct foo. But there needs to be a way to
> >> > represent this.
> >>
> >> Err... Isn't it valid to assume that &X.a[2048] == &X.b[0], which
> >> would be the reason why both fields must be in the same alias set?
>
> > No. &X.a[2048] is a legitimate pointer for purpose of comparing it
> > with another pointer *into the same array* (X.a) but dereferencing it,
> > or comparing it to a pointer into a different array (such as X.b) is
> > undefined behavior.
>
> C99 6.5.8/#5 hints that such pointers may be valid:
>
> If the objects pointed to are members of the same aggregate
> object, pointers to structure members declared later compare
> greater than pointers to members declared earlier in the
> structure [...]
> In all other cases, the behavior is undefined.
Hmm, okay, but I'm still pretty confident that dereferencing a pointer to
&X.a[i] for i>=2048 is undefined, which is the important thing for this
optimization.
zw