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

Johannes Doerfert via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed May 8 11:11:54 PDT 2019


jdoerfert added a comment.

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?

To recap: What we need to verify a pointer comparison agains `null` is `noescape` would be:

1. A dereferenceable pointer (see Value::getPointerDereferenceableBytes), **or**
2. A dereferenceable_or_null pointer Ptr (see Value::getPointerDereferenceableBytes) in a scope (=function) in which null is not a valid pointer (see NullPointerIsDefined(Function *, unsigned AddrSpace))


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