This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: C provenance semantics proposal
On Thu, Apr 18, 2019 at 3:42 PM Jeff Law <law@redhat.com> wrote:
>
> On 4/18/19 6:20 AM, Uecker, Martin wrote:
> > Am Donnerstag, den 18.04.2019, 11:45 +0100 schrieb Peter Sewell:
> >> On Thu, 18 Apr 2019 at 10:32, Richard Biener <richard.guenther@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)
> I know this will hit DOM and CSE. I wouldn't be surprised if it touches
> VRP as well, maybe PTA. It seems simple enough though :-)
Also touches fundamental PHI-OPT transforms like
if (a == b)
...
# c = PHI <a, b>
where we'd lose eliding such a conditional. IMHO that's bad
and very undesirable.
> >
> > 2.) We make pointer comparison between a pointer
> > and a one-after pointer of a different object
> > undefined behaviour.
> I generally like this as well, though I suspect it probably makes a lot
> of currently well defined code undefined.
>
> >
> > 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).
> This could have some interesting effects on PTA. Richi?
I played with this and doing this in an incomplete way like
just handling
if (a == b)
as two-way assignment during constraint building is possible.
But that's not enough of course since every call is implicitely
producing equivalences between everything [escaped] ...
which makes points-to degrade to a point where it is useless.
So I think we need a working scheme where points-to doesn't
degrade from equivalencies being computed and the compiler
being free to introduce equivalences as well as copy-propagate
those.
Honestly I can't come up with a working solution to this
problem.
>
> >
> > 4.) Compilers make sure that exposed objects never
> > are allocated next to each other (as Jens proposed).
> Ugh. Not sure how you enforce that. Consider that the compiler may
> ultimately have no control over layout of data in static storage.
Make everything 1 byte larger.
> jeff