[PATCH] D90708: [LangRef] Clarify GEP inbounds wrapping semantics

Nuno Lopes via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Nov 4 01:03:51 PST 2020


nlopes added a comment.

LGTM modulo the two comments. Thanks for writing this down!



================
Comment at: llvm/docs/LangRef.rst:9772
+*  The base pointer is an *in bounds* address of an allocated object, which
+   means that it points into or one byte past the end of an allocated object.
+   The only *in bounds* address for a null pointer in the default
----------------
I think the "one byte past" can be misleading. A pointer can point to the end of an object, or as the C++ standard puts it, it may point to a hypothetical next element n if the object has n elements.
http://eel.is/c++draft/basic.compound#3.4


================
Comment at: llvm/docs/LangRef.rst:9782
+   applies to each of the computations element-wise.
+
+As a corollary, the following two properties follow:
----------------
one more case is that offsets must fit (signed-wise) in the address space's size. So a GEP with 64 bits offsets on a 32-bit address space is OK as long as those offsets fit in 32 bits.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90708



More information about the llvm-commits mailing list