On 19/04/2019, Jakub Jelinek <ja...@redhat.com> wrote: > On Fri, Apr 19, 2019 at 10:19:28AM +0200, Jens Gustedt wrote: >> > OTOH GCC transforms >> > (uintptr_t)&a != (uintptr_t)(&b+1) >> > into &a != &b + 1 (for equality compares) and then >> > doesn't follow this C rule anyways. >> >> Actually our proposal we are discussing here goes exactly the other >> way around. It basically reduces >> >> &a != &b + 1 >> >> to >> >> (uintptr_t)&a != (uintptr_t)(&b+1) >> >> with only an exception for null pointers, but which probably don't >> matter for a platform where null pointers are just all bits 0. > > That penalizes quite a few optimizations though. > If you have > ptr != ptr2 > and points-to analysis finds a set of variables ptr as well as ptr2 points > to and the sets would be disjoint, it would be nice to be able to optimize > that comparison away (gcc does); similarly, if one of the pointers is > &object or &object + sizeof (object). > By requiring what you request above, it can be pretty much never optimized, > unless the points-to analysis is able to also record if the pointer points > to the start, middle or end of object and only if it is known to be in the > middle it can safely optimize, for start or end it would need to prove the > other pointer is to end or start and only non-zero sized objects are > involved.
A possible compromise position might be to make it implementation-defined whether round-trip casts of a one-past pointer into integer and back preserve provenance. I don't know whether that corner case crops up in real code... best, Peter
