From: Peter Sewell <Peter.Sewell@cl.cam.ac.uk>
To: Richard Biener <richard.guenther@gmail.com>
Cc: "Uecker, Martin" <Martin.Uecker@med.uni-goettingen.de>,
"gcc@gcc.gnu.org" <gcc@gcc.gnu.org>,
"law@redhat.com" <law@redhat.com>,
"cl-c-memory-object-model@lists.cam.ac.uk"
<cl-c-memory-object-model@lists.cam.ac.uk>
Subject: Re: C provenance semantics proposal
Date: Thu, 18 Apr 2019 10:48:00 -0000 [thread overview]
Message-ID: <CAHWkzRRPKR1ewbFva476U=Dtq_ymX3_-B-bokpdxgHarXUZ=Bg@mail.gmail.com> (raw)
In-Reply-To: <CAFiYyc0KZfuhwtKKwcyVZuJ6w-metirM-VNYVs5D2_AqU6ZrHg@mail.gmail.com>
On Thu, 18 Apr 2019 at 10:56, Richard Biener <richard.guenther@gmail.com> wrote:
>
> On Thu, Apr 18, 2019 at 11:31 AM Richard Biener
> <richard.guenther@gmail.com> wrote:
> >
> > On Wed, Apr 17, 2019 at 4:12 PM Uecker, Martin
> > <Martin.Uecker@med.uni-goettingen.de> wrote:
> > >
> > > Am Mittwoch, den 17.04.2019, 15:34 +0200 schrieb Richard Biener:
> > > > On Wed, Apr 17, 2019 at 2:56 PM Uecker, Martin
> > > > <Martin.Uecker@med.uni-goettingen.de> wrote:
> > > > >
> > > > > Am Mittwoch, den 17.04.2019, 14:41 +0200 schrieb Richard Biener:
> > > > > > On Wed, Apr 17, 2019 at 1:53 PM Uecker, Martin
> > > > > > <Martin.Uecker@med.uni-goettingen.de> wrote:
> > > > > > >
> > > > > > > > Since
> > > > > > > > your proposal is based on an abstract machine there isn't anything
> > > > > > > > like a pointer with multiple provenances (which "anything" is), just
> > > > > > > > pointers with no provenance (pointing outside of any object), right?
> > > > > > >
> > > > > > > This is correct. What the proposal does though is put a limit
> > > > > > > on where pointers obtained from integers are allowed to point
> > > > > > > to: They cannot point to non-exposed objects. I assume GCC
> > > > > > > "anything" provenances also cannot point to all possible
> > > > > > > objects.
> > > > > >
> > > > > > Yes. We exclude objects that do not have their address taken
> > > > > > though (so somewhat similar to your "exposed").
> > > > >
> > > > > Also if the address never escapes?
> > > >
> > > > Yes.
> > >
> > > Then with respect to "expose" it seems GCC implements
> > > a superset which means it allows some behavior which
> > > is undefined according to the proposal. So all seems
> > > well with respect to this part.
> > >
> > >
> > > With respect to tracking provenance through integers
> > > some changes might be required.
> > >
> > > Let's consider this example:
> > >
> > > int x;
> > > int y;
> > > uintptr_t pi = (uintptr_t)&x;
> > > uintptr_t pj = (uintptr_t)&y;
> > >
> > > if (pi + 4 == pj) {
> > >
> > > int* p = (int*)pj; // can be one-after pointer of 'x'
> > > p[-1] = 1; // well defined?
> > > }
> > >
> > > If I understand correctly, a pointer obtained from
> > > pi + 4 would have a "anything" provenance (which is
> > > fine). But the pointer obtained from 'pj' would have the
> > > provenance of 'y' so the access to 'x' would not
> > > be allowed.
> >
> > Correct. This is the most difficult case for us to handle
> > exactly also because (also valid for the proposal?)
> >
> > int x;
> > int y;
> > uintptr_t pi = (uintptr_t)&x;
> > uintptr_t pj = (uintptr_t)&y;
> >
> > if (pi + 4 == pj) {
> >
> > int* p = (int*)(pi + 4); // can be one-after pointer of 'x'
> > p[-1] = 1; // well defined?
> > }
> >
> > while well-handled by GCC in the written form (as you
> > say, pi + 4 yields "anything" provenance), GCC itself
> > may tranform it into the first variant by noticing
> > the conditional equivalence and substituting pj for
> > pi + 4.
> >
> > > But according to the preferred version of
> > > our proposal, the pointer could also be used to
> > > access 'x' because it is also exposed.
> > >
> > > GCC could make pj have a "anything" provenance
> > > even though it is not modified. (This would break
> > > some optimization such as the one for Matlab.)
> > >
> > > Maybe one could also refine this optimization to check
> > > for additional conditions which rule out the case
> > > that there is another object the pointer could point
> > > to.
> >
> > The only feasible solution would be to not track
> > provenance through non-pointers and make
> > conversions of non-pointers to pointers have
> > "anything" provenance.
> >
> > The additional issue that appears here though
> > is that we cannot even turn (int *)(uintptr_t)p
> > into p anymore since with the conditional
> > substitution we can then still arrive at
> > effectively (&y)[-1] = 1 which is of course
> > undefined behavior.
> >
> > That is, your proposal makes
> >
> > ((int *)(uintptr_t)&y)[-1] = 1
> >
> > well-defined (if &y - 1 == &x) but keeps
> >
> > (&y)[-1] = 1
> >
> > as undefined which strikes me as a little bit
> > inconsistent. If that's true it's IMHO worth
> > a defect report and second consideration.
>
> Similarly that
>
> int x;
> int y;
> uintptr_t pj = (uintptr_t)&y;
>
> if (&x + 1 == &y) {
>
> int* p = (int*)pj; // can be one-after pointer of 'x'
> p[-1] = 1; // well defined?
> }
>
> is undefined but when I add a no-op
>
> (uintptr_t)&x;
>
> it is well-defined is undesirable. Can this no-op
> stmt appear in another function? Or even in
> another translation unit (if x and y are global variables)?
> And does such stmt have to be present (in another
> TU) to make the example valid in this case?
yes to all that - again, in the variant in which
roundtrips of a one-past pointer are supported.
> To me all this makes requiring exposal through a cast
> to a non-pointer (or accessing its representation) not
> in any way more "useful" for an optimizing compiler than
> modeling exposal through address-taking.
interesting, thanks
best,
Peter
> Richard.
>
> > Richard.
> >
> > > Best,
> > > Martin
next prev parent reply other threads:[~2019-04-18 10:48 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-02 8:11 Peter Sewell
2019-04-12 14:51 ` Jeff Law
2019-04-12 15:31 ` Peter Sewell
2019-04-17 9:06 ` Richard Biener
2019-04-17 9:15 ` Peter Sewell
2019-04-17 9:41 ` Richard Biener
2019-04-17 11:53 ` Uecker, Martin
2019-04-17 12:41 ` Richard Biener
2019-04-17 12:56 ` Uecker, Martin
2019-04-17 13:35 ` Richard Biener
2019-04-17 14:12 ` Uecker, Martin
2019-04-17 17:31 ` Peter Sewell
2019-04-18 9:32 ` Richard Biener
2019-04-18 9:56 ` Richard Biener
2019-04-18 10:48 ` Peter Sewell [this message]
2019-04-18 11:57 ` Uecker, Martin
2019-04-18 12:31 ` Richard Biener
2019-04-18 13:25 ` Uecker, Martin
2019-04-18 10:45 ` Peter Sewell
2019-04-18 12:20 ` Uecker, Martin
2019-04-18 12:42 ` Richard Biener
2019-04-18 12:47 ` Jakub Jelinek
2019-04-18 12:51 ` Jakub Jelinek
2019-04-18 13:29 ` Jeff Law
2019-04-24 10:12 ` Richard Biener
2019-04-18 13:49 ` Uecker, Martin
2019-04-19 8:19 ` Jens Gustedt
2019-04-19 8:49 ` Jakub Jelinek
2019-04-19 9:09 ` Jens Gustedt
2019-04-19 9:34 ` Jakub Jelinek
2019-04-21 8:15 ` Jens Gustedt
2019-04-24 10:24 ` Richard Biener
2019-04-24 18:43 ` Jeff Law
2019-04-24 19:21 ` Jens Gustedt
2019-04-19 9:11 ` Peter Sewell
2019-04-19 9:15 ` Jens Gustedt
2019-04-19 9:35 ` Peter Sewell
2019-04-19 10:35 ` Uecker, Martin
2019-04-19 10:01 ` Uecker, Martin
2019-04-18 13:42 ` Jeff Law
2019-04-18 13:54 ` Uecker, Martin
2019-04-18 14:49 ` Peter Sewell
2019-04-18 15:09 ` Uecker, Martin
2019-04-24 10:19 ` Richard Biener
2019-04-24 18:41 ` Jeff Law
2019-04-24 19:30 ` Philipp Klaus Krause
2019-04-24 19:55 ` Uecker, Martin
2019-04-24 19:33 ` Jakub Jelinek
2019-04-24 21:19 ` Peter Sewell
2019-04-25 12:42 ` Richard Biener
2019-04-25 13:03 ` Peter Sewell
2019-04-25 13:13 ` Richard Biener
2019-04-25 13:20 ` Peter Sewell
2019-04-29 14:31 ` Joseph Myers
2019-04-25 12:39 ` Richard Biener
2019-05-09 11:26 ` Ralf Jung
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAHWkzRRPKR1ewbFva476U=Dtq_ymX3_-B-bokpdxgHarXUZ=Bg@mail.gmail.com' \
--to=peter.sewell@cl.cam.ac.uk \
--cc=Martin.Uecker@med.uni-goettingen.de \
--cc=cl-c-memory-object-model@lists.cam.ac.uk \
--cc=gcc@gcc.gnu.org \
--cc=law@redhat.com \
--cc=richard.guenther@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).