https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
--- Comment #29 from Peter Sewell <Peter.Sewell at cl dot cam.ac.uk> --- On 8 May 2018 at 08:22, rguenth at gcc dot gnu.org <gcc-bugzi...@gcc.gnu.org > wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 > > --- Comment #25 from Richard Biener <rguenth at gcc dot gnu.org> --- > (In reply to Harald van Dijk from comment #22) > > (In reply to Andrew Pinski from comment #21) > > > Invalid as mentioned a few times already but never actually closed > until now. > > > > I posted a strictly conforming program that with GCC does not behave as > > required by the standard. The issue is valid, even if the original test > case > > is not. > > If you are talking about the one in comment#12 then this is the same issue > as present in a few other "similar" bugs where GCC propagates conditional > equivalences (for example the linked PR65752): > > v = &y; > p = v; > x = 2, y = 1; > if (p == &x + 1) > *p = 2; > > is turned into > > v = &y; > p = v; > x = 2, y = 1; > if (p == &x + 1) > *(&x + 1) = 2; > > by GCC and the store is then no longer possibly aliasing y. > > Conditional equivalences are a difficult thing to exploit for optimization > and there's some work in progress for the standard regarding to pointer > provenance which IIRC says that the comparison result of &y == &x + 1 > returns an unspecified value. Not sure if that helps us FYI, the current state of that work in progress is here: https://cdn.rawgit.com/C-memory-object-model-study-group/c-mom-sg/master/notes/cmom-0001-2018-05-04-sewell-clarifying-provenance-v4.html and comments from a GCC perspective would be much appreciated. It's been informed by useful discussion at the recent WG14 and EuroLLVM meetings. Our current proposal indeed makes that comparison an unspecified value - more generally, allowing any pointer equality comparison to either take provenance into account or not - exactly because we see GCC do so in some cases. If that isn't important for optimisation, returning to a fully concrete semantics for == would be a simpler choice. but then the > only way our for GCC for this particular issue would be to never actually > propagate conditional equivalences. > (Conceivably it could be allowed where the compiler can see that the two have the same provenance. We've no idea how useful that would be.) > > Sth that might be worth investigating, but within the current structure of > the optimization passes that apply this transform it's impossible to decide > whether a value resulted from conditional equivalences or not... I'm also > not sure to what extent simplification results using a conditional > predicate > like p == &x + 1 are affected as well. > > IMHO it's a defect in the language if > > p = &y; > if (p == &x + 1) > *p = 2; > > is valid but > > p = &y; > if (p == &x + 1) > *(&x + 1) = 2; > > is invoking undefined behavior. Or at least a very uncomfortable situation > for a compiler writer. IMHO the pointer provenance work making the > comparison having unspecified result doesn't really help since that doesn't > make it invoke undefined behavior. > It's not clear how this could be resolved. For the source-language semantics, if one wants to be able to do provenance-based alias analysis, we don't see any clean way in which the second could be allowed. And forbidding the first would need one to make == of pointers with different provenances UB, which we imagine would break a lot of C code. That said, in general the intermediate-language semantics might be quite different from the C-source-language semantics (as we discover in discussion with Nuno Lopes and his colleagues about their LLVM semantics), so long as it implements the source semantics. Peter, Kayvan, Victor > > -- > You are receiving this mail because: > You reported the bug. >
