This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Tree aliasing
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: Andrew Pinski <pinskia at gmail dot com>
- Cc: GCC Mailing List <gcc at gcc dot gnu dot org>
- Date: Tue, 4 Aug 2009 10:47:52 +0200
- Subject: Re: Tree aliasing
- References: <de8d50360908031925p6ed5c821p365e2411ad9e6373@mail.gmail.com>
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
>