[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