aaron.ballman added a comment. In D104285#2949638 <https://reviews.llvm.org/D104285#2949638>, @ASDenysPetrov wrote:
> @aaron.ballman > Let me speak some thoughts. Consider next: > > int arr[2][5]; > int *ptr1 = &arr[0][0]; > int *ptr2 = &arr[1][0]; > > The Standard tells that `ptr1[5]` is UB and `ptr2[0]` is a valid object. Agreed. > In practice `ptr1` and `ptr2` usually are equal. Do you mean `&ptr1[5]` and `&ptr2[0]`? If so, I agree they are usually going to have the same pointer address at runtime. > But the Standard does not garantee them to be equal and this depends on a > particular implementation. So we should rely on that there might be a > compiler such that creates every subarray disjointed. I think this is an > exact excerpt from what our arguing actually starts from. I don't think that compilers will create a disjointed multidimensional array, as that would waste space at runtime. However, I do think that *optimizers* are getting much smarter about UB situations, saying "that can't happen", and basing decisions on it. For example, this touches on pointer provenance which is an open area of discussion in LLVM that's still being hammered out (it also relates to the C `restrict` keyword). In a provenance world, the pointer has more information than just its address; it also knows from where the pointer was derived, so you can tell (in the backend) that `&ptr1[5]` and `&ptr2[0]` point to *different* objects even if the pointer values are identical. So while the runtime layout of the array object may *allow* for these sort of type shenanigans with the most obvious implementation strategies for multidimensional arrays, the programming language's object model does not allow for them and optimizers may do unexpected things. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D104285/new/ https://reviews.llvm.org/D104285 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
