[PATCH] D90708: [LangRef] Clarify GEP inbounds wrapping semantics
Jessica Clarke via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Nov 11 11:51:41 PST 2020
jrtc27 added inline comments.
================
Comment at: llvm/docs/LangRef.rst:9782
+ means that it points into an allocated object, or to its end (which is one
+ byte past the last byte contained in the object). The only *in bounds*
+ address for a null pointer in the default address-space is the null pointer
----------------
nlopes wrote:
> I still don't like the current writing. I would need to see some evidence from language standards that they require pointers past the end of objects.
> If both the pointer operand and the result point to elements of the same array object, or one past the last element of the array object, the evaluation shall not produce an overflow; otherwise, the behavior is undefined.
https://port70.net/~nsz/c/c11/n1570.html#6.5.6p8
================
Comment at: llvm/docs/LangRef.rst:9789
+ index type in a signed sense (``nsw``).
+* The successive addition of offsets (without adding the base address) does
+ not wrap the pointer index type in a signed sense (``nsw``).
----------------
nlopes wrote:
> It's a bit stronger than that. The addition of each offset to the preceding pointer should not overflow. You can't do e.g.:
> gep inbounds %p, -1, 1
>
> because %p-1 is OOB, even though the result is in bounds (because %p must be in bounds).
It's more nuanced than that, no? `%p` could be a pointer part-way through (or one past the end of) an object, in which case `%p-1` would still be in bounds?
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D90708/new/
https://reviews.llvm.org/D90708
More information about the llvm-commits
mailing list