https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 45411
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45411&action=edit
gcc9-pr88775-2.patch

The following incremental patch (untested except for this testcase and
comparisons_pointer.cc) fixes that.  Unfortunately there is still
ptrs_compare_unequal routine that would need similar treatment, and I'm afraid
it will result in less optimized code.

This patch alone though could be useful even without the other patch, perhaps
if we for pointers like before optimize always.  The previous case where we
optimized for integral equality comparisons of pointers only if the offsets are
the same is both incorrect (for zero sized objects) and in many cases not
optimizing enough (it is fine if both offsets are different, all we care is
that the problematic cases where one pointer points to the beginning of one
object and the other points to one past last byte of another one aren't
optimized, everything else can).

C99 says:
"Tw o pointers compare equal if and only if both are null pointers, both are
pointers to the same object (including a pointer to an object and a subobject
at its beginning) or function, both are pointers to one past the last element
of the same array object, or one is a pointer to one past the end of one array
object and the other is a pointer to the start of a different array object that
happens to immediately follow the first array object in the address space."
so I think we have to be conservative and need to treat pointer equality the
same as equality of pointers cast to integral types, the question is if we are
prepared for this for GCC9.

Note, in ptrs_compare_unequal for the one obj, one ptr case (the only
interesting one it handles), we could check if the pointer to the obj is known
to be into the middle of the object (if size is constant and offset too, that
is trivial, other cases might be harder and need more discussions) and in that
case we can do whatever it does now.  Otherwise, either punt, or e.g. check if
obj is a global var and the other ptr points to only automatic vars (or if obj
is automatic and ptr points to only global vars).  Something else we could do?

Reply via email to