On Thu, Apr 18, 2019 at 2:20 PM Uecker, Martin <martin.uec...@med.uni-goettingen.de> wrote: > > Am Donnerstag, den 18.04.2019, 11:45 +0100 schrieb Peter Sewell: > > On Thu, 18 Apr 2019 at 10:32, Richard Biener <richard.guent...@gmail.com> > > wrote: > > > > An equality test of two pointers, on the other hand, doesn't necessarily > > mean that they are interchangeable. I don't see any good way to > > avoid that in a provenance semantics, where a one-past > > pointer might sometimes compare equal to a pointer to an > > adjacent object but be illegal for accessing it. > > As I see it, there are essentially four options: > > 1.) Compilers do not use conditional equivalences for > optimizations of pointers (or only when additional > conditions apply which make it safe) > > 2.) We make pointer comparison between a pointer > and a one-after pointer of a different object > undefined behaviour.
Yes please! 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. > 3.) We make comparison have the side effect that > afterwards any of the two pointers could have any > of the two provenances. (with disambiguitation > similar to what we have for casts). > > 4.) Compilers make sure that exposed objects never > are allocated next to each other (as Jens proposed). 5.) While the standard guarantees that (int *)(uintptr_t)p == p it does not guarantee that (uintptr_t)&a and (uintptr_t)&b have a specific relation to each other. To me this means that (uintptr_t)(&b + 1) - (uintptr_t)&b is not necessarily equal to sizeof(b). (of course it's a QOI issue if that doesn't hold) > None of these options is great. Indeed. But you are now writing down one specific variant (which isn't great either). Sometimes no written down variant is better than a not so great one, even if there isn't any obviously greater one. That said, GCCs implementation of the proposal might be to require -fno-tree-pta to follow it. And even that might not fully rescue us because of that (int *)(uintptr_t) stripping... At least I see no way to make use of the "exposed"ness and thus we have to assume every variable is exposed. Of course similar if the address-taken variant would be written down in the standard given the standard applies to the source form and not some intermediate (optimized) compiler language. Richard. > > > Best, > Martin
