================
@@ -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

Reply via email to