[PATCH] D114988: [IR] `GetElementPtrInst`: per-index `inrange` support

Bruno De Fraine via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Apr 8 03:41:55 PDT 2022


brunodf added a comment.

In D114988#3437219 <https://reviews.llvm.org/D114988#3437219>, @efriedma wrote:

>> Could you clarify how the C standard guarantees this will return 1?
>
> "Two pointers compare equal if [...] one is a pointer to one past the end of one array object and the other is a pointer to the start of a different array object that happens to immediately follow the first array object in the address space."
>
>> I think the standard allows padding between struct members a and b (even though I see very little reason to add padding here)
>
> The relevant rule says that if there isn't any padding, the pointers compare equal.  And we don't insert padding in practice.  It doesn't matter that some other compiler could theoretically add padding.

OK, got it. The cited sentence has footnote: "Two objects may be adjacent in memory because they are adjacent elements of a larger array or adjacent members of a structure with no padding between them, or because the implementation chose to place them so, even though they are unrelated."

I see a parallel with local variables:

  int a[3], b[3];

That may happen to be placed next to each other in the stack frame, such that `&a[3] == &b[0]` indeed leading to the provenance problem <https://www.ralfj.de/blog/2020/12/14/provenance.html> you also mentioned.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114988



More information about the llvm-commits mailing list