[PATCH] D60047: [CaptureTracking] Don't let comparisons against null escape inbounds pointers

Sanjoy Das via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu May 9 21:42:47 PDT 2019


sanjoy added a comment.

In D60047#1495488 <https://reviews.llvm.org/D60047#1495488>, @jdoerfert wrote:

> In D60047#1495432 <https://reviews.llvm.org/D60047#1495432>, @aqjune wrote:
>
> > Hello,
> >
> > > One mode of reasoning that could invalidate this example is that p *could have been* something other than 2^64-4 which would invoke UB. This UB would both let us pretend that foo does not escape p, and also print 2^64-4 even though p was not 2^64-4 in the execution we chose. This seems a bit subtle though, and I'm not entirely sure this is sound reasoning.
> >
> > (sorry for my sudden interruption :)
>
>
> That is what I did to re-start the discussion on this thread as well...
>
> > I think this reasoning makes sense, but to say why it makes sense a few minor details should be explained.
> >  [...]
> >  I think the story is similar here. We can define that the address of allocation is nondeterministically chosen (like the case of a racy program), so LLVM can pick the most problematic one, and say that the source program already has undefined behavior. :)
>
> Cool. @sanjoy, are we in agreement?


Yes, this sounds fine.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D60047/new/

https://reviews.llvm.org/D60047





More information about the llvm-commits mailing list