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.
