On Tue, Aug 4, 2009 at 4:25 AM, Andrew Pinski<pins...@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 >
