[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