Am Donnerstag, den 18.04.2019, 14:42 +0200 schrieb Richard Biener: > 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.
I know this would be the best option from the point of view of a compiler write. My concern is that this adds a trap for programmers. You can then compare arbitrary pointers except in this specific special case. > > 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) I think a direct mapping from addresses to integer is the only thing which is feasible in most cases. But maybe the compiler could actually move 'a' and 'b' away from each other? > > 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. I am not sure everybody would agree. > 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... Don't strip it then? The FE could add a marker. Best, Marti > 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.
