================ @@ -8811,8 +8829,19 @@ class MappableExprsHandler { ++EI; } } - llvm::stable_sort(DeclComponentLists, [](const MapData &LHS, - const MapData &RHS) { + llvm::stable_sort(DeclComponentLists, [VD](const MapData &LHS, + const MapData &RHS) { + // For cases like map(p, p[0], p[0][0]), the shortest map, like map(p) ---------------- abhinavgaba wrote:
I created two NFC PRs: https://github.com/llvm/llvm-project/pull/146934 and https://github.com/llvm/llvm-project/pull/146891 to add new tests and do a refactor of this code a bit. Please take a look. I have a patch locally for this PR that builds upon the refactor. I can upload that once those NFC PRs are merged. It would fix the IR emission for this case, but there would still be an underlying problem for the struct member case -- since we don't use PTR_AND_OBJ for mapping things like "sp->x", when we have "map(sp, sp->x)", we can either access the mapped pointer, or the pointee inside the target region, because sp and sp->x are not attached. So if we merge the fix for mapped "sp" not being accessible in the target region, it will make the mapped pointee inaccessible. One of the tests from the NFC PR shows this problem, and I can highlight that once those are merged and I upload a follow-up patch to this one. https://github.com/llvm/llvm-project/pull/145454 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits