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 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.
Further support to my impression is given by J.2/#1:
The behavior is undefined in the following
circumstances:
[...]
-- Pointers that do not point to the same aggregate or
union (nor just beyond the same array object) are
compared using relational operators (6.5.8).
I admit it doesn't guarantee my previously-posted assertion is true,
even though I'd expect it to be guaranteed by layout rules I can't
find in the Standard right now. But still, it implies there is some
difference between two unrelated arrays and two arrays that are
members of the same aggregate.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist *Please* write to mailing lists, not to me