[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