Am Freitag, den 19.04.2019, 10:35 +0100 schrieb Peter Sewell: > On 19/04/2019, Jens Gustedt <jens.gust...@inria.fr> wrote: > > Hello Peter, > > > > On Fri, 19 Apr 2019 10:11:43 +0100 Peter Sewell > > <peter.sew...@cl.cam.ac.uk> wrote: > > > > > On 19/04/2019, Jakub Jelinek <ja...@redhat.com> wrote: > > > > On Fri, Apr 19, 2019 at 10:19:28AM +0200, Jens Gustedt wrote: [...] > I was conflating two things, sorry. I meant an adaption of PNVI-ae-udi > that would let implementations turn off the udi part if they wish. Then > for those, casting a one-past pointer into integer and back would give an > empty-provenance pointer that couldn't be used for accesses, which helps > with the p[-1] examples that Richard was thinking of. As we think this > roundtrip casting of a one-past pointer might be an exotic corner case, > this might be reasonable.
The point of making such corner cast "just work" from a programmer's point of view is to not have him need to know about and always worry about it just to not accidentally write broken code. Making it implementation-defined just makes it more complicated to understand when it might work or not. So in my opinion we should either make it work always or we remove it completely and make the limitations of one-after pointers very explicit. But my preference is still the first. > > This: > > > > 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) BTW: This is always true. Just that the one-after case means that the sets of addresses overlap in some cases where one may (incorrectly) assume they don't when only considering provenance. > seems to be an argument to keep pointer == nondeterministically > provenance-sensitive or not, though whether it outweighs the > simplicity gain of making == just examine the address isn't clear to me. > My inclination would still be to the latter. This would be my preference too. In fact, I believe that most optimizations could still be implemented. Certainly, this adds complexity to the compiler because it then also has do more sophisticated checks and maybe also have some rules about which objects could be adjacent to each other. And as a last resort, there could be a compiler flag which is off by default that enables optimizations based on the assumption that one-after pointers are never compared to pointers pointing to different objects. Best, Martin
