[flang-commits] [flang] [llvm] [mlir] [Flang][OpenMP] Fix Fortran automap handling (PR #162501)

via flang-commits flang-commits at lists.llvm.org
Wed Jul 8 09:18:24 PDT 2026


================
@@ -5719,16 +5719,18 @@ static void collectMapDataFromMapOperands(
   // Process MapOperands
   for (Value mapValue : mapVars) {
     auto mapOp = cast<omp::MapInfoOp>(mapValue.getDefiningOp());
+    bool isAttachMap =
+        bitEnumContainsAll(mapOp.getMapType(), omp::ClauseMapFlags::attach);
     bool isRefPtrOrPteeMapWithAttach =
         checkRefPtrOrPteeMapWithAttach(mapOp.getMapType());
     Value offloadPtr = (mapOp.getVarPtrPtr() && !isRefPtrOrPteeMapWithAttach)
                            ? mapOp.getVarPtrPtr()
                            : mapOp.getVarPtr();
+    Value pointeePtr = isRefPtrOrPteeMapWithAttach
----------------
agozillon wrote:

I'm not entirely sure we want to do this, would it be possible to print the map entry list from the trace you're aiming for here and the one you're working from without these changes (or pseudo code it, whatever is easiest)?

I think, in this case, the "isAttachMap ?" true segment is perhaps redundant as I think whenever isRefPtrOrPteeMapWithAttach is true is also the only case where isAttachMap will be true, I don't believe (but I could be wrong) we ever emit attach without ref_ptr/ptee/ref_ptr_ptee and if someone has explicitly specified attach_never we just drop the attach map entirely. I think this means even if we fall into the else case for isRefPtrOrrPteeMapWithAttach, we have no attach map so we default back to the offloadPtr which is what the old code that we're removing at line 5728 used to do. So, perhaps the original variation might work for your case now, unsure though!

The original logic (annoyingly complex because of myself, so my apologies), basically just selects between the descriptor address and the base pointer address (or defaults to the old logic) as the attach map is a special case where we basically add the descriptor address as the varPtr and the data's base pointer address as the varPtrPtr so we have access to them both, as an attach map entry expects both so that they can be glued together by the runtime. The caveat of this is that if we offset the base pointer via bounds specification we have to replicate it.

https://github.com/llvm/llvm-project/pull/162501


More information about the flang-commits mailing list