This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Tree aliasing


On Tue, Aug 4, 2009 at 4:25 AM, Andrew Pinski<pinskia@gmail.com> wrote:
> I was improving tree aliasing for pointers by adding support a+1 and a
> not aliasing. ?But I ran into a bug in the aliasing where:
> ?/* If both references are through the same type, they do not alias
> ? ? if the accesses do not overlap. ?This does extra disambiguation
> ? ? for mixed/pointer accesses but requires strict aliasing. ?*/
> ?if (same_type_for_tbaa (TREE_TYPE (TREE_TYPE (ptr1)),
> ? ? ? ? ? ? ? ? ? ? ? ? ?TREE_TYPE (TREE_TYPE (ptr2))) == 1)
> ? ?return ranges_overlap_p (offset1, max_size1, offset2, max_size2);
>
> Would return false even. ?I can't see how this can be true if one
> pointer is defined as an offset as the other and the offset1 or
> offset2 are non zero.
>
> Can someone explain why this is true?

This is true because if you have two pointers pointing to the indentical
type T then with strict-aliasing you either have a full overlap
(ptr1 == ptr2) or no overlap.  I can see one mistake here in that
the offsets (I need to think about the max-sizes) need to be modulo
the size of the pointed-to type, but
other than that it's ok.  A fix for that is appreciated (together with
a testcase of course).

Richard.

> Even nonaliasing_component_refs_p looks to have the same issue if the
> types are the same, they could be an extra offset from each other,
> even though the compiler cannot figure that out. ?I am thinking of
> when storing the pointer in an array and then accessing that pointer.
>
> gcc.dg/20030324-1.c is the testcase where I am running into this bug too.
>
> Thanks,
> Andrew Pinski
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]