On Tue, 21 Jan 2020, Alexander Monakov wrote: > On Mon, 20 Jan 2020, Joseph Myers wrote: > > > On Mon, 20 Jan 2020, Alexander Monakov wrote: > > > > > Hi, > > > > > > we have this paragraph in the documentation that attempts to prohibit > > > something that is allowed by the language. Instead, I think we should > > > say that this generally should work and explain that a problem in GCC > > > implementation breaks this. > > > > Is this based on the proposals to adopt a PNVI model (as described in > > N2362 / N2363 / N2364) for C2x? Do you have a more detailed analysis of > > exactly which issues would need changes in GCC to follow the proposed > > PNVI-ae-udi semantics? Setting up a meta-bug in Bugzilla with > > dependencies on such issues might be useful, for example - I know there > > are existing bugs you've filed or commented on, but it would help to have > > a list in a single place of issues for implementing PNVI-ae-udi. > > > > It's not obvious that documentation relating to things that are > > implementation-defined in existing C standard versions, where detailed > > memory model questions were not defined, is an appropriate place to > > discuss questions of how some optimizations might not follow a more > > precise definition proposed for C2x. > > My intent was more basic. I observed that the paragraph can be interpreted as > saying that if you have a cast 'I1 = (intptr_t) P1', then perform some > computations on I1 that do not in any way depend on values of other pointers, > then casting the result back can not point to a different object than P1. > But that is not very helpful, because this is the case where the user might > have > used normal pointer arithmetic in the first place. The important cases > involve computations that depend on multiple pointers to unrelated objects. > > I think that the case discussed in the proposed patch is already not ambiguous > and does not need further clarifications to the standard. > > I also think we should provide the users with rationale when imposing such > restrictions, and, as Sandra noted, offer a way to work around the problem. > > However I don't mind dropping the patch if it's not appropriate. Richard, > can you share your opinion here?
Let me say a few things here. First I always thought the only thing C guarantees is that you can convert a pointer to an integer and back (the same value!) then you get the same pointer if the integer type has sufficient size. The C standard nowhere specifies semantics of the case where you modify the integer "representation" and then convert that to a pointer. But that may have changed. Second. Fact is RTL does not distinguish between pointers and integers and thus any attempt to make something valid when you use integers and invalid when you use pointers is not going to work. Third. GCC tracks pointed to things through integers. That means it a) assumes the integer representation cannot "leave" an object as the current documentation states b) it handles "mixing" pointers to different objects in their integer representation correctly as to that it assumes the result converted to a pointer might point to either object the tracking implementation details also track pieces and funneling pointers through FP values. Fourth. That PNVI (I assume it's the whole pointer-provenance stuff) wants to get the "best" of both which can never be done since a compiler needs to have a way to be conservative - in this area it's conflicting conservative treatment which is impossible. Fifth. GCC has issues involving equivalences and when (implicitely) turning control into data dependences. The C standard seems to have conflicting (to GCC) wording with regard to equivalences of pointers vs. integers (well, not actually sure). For all these issues I usually point at the second issue above because trying to plug holes without addressing that very thing isn't going to work (unless you want to plug the "hole" for integer code as well). And yeah, a meta-bug or even better a single WIKI page listing issues (and maybe referencing the various partially redundant and partially mixing different issues bugzillas) would be helpful here. To be the entry-point in bugzilla is PR49330, see comment#7 for the fundamental RTL representation issue. Thanks, Richard.