================
@@ -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
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
