[flang-commits] [flang] [Flang][OpenMP] Support iterator modifier in map and motion clauses (PR #197757)

via flang-commits flang-commits at lists.llvm.org
Tue Aug 4 19:49:05 PDT 2026


================
@@ -2080,13 +2190,25 @@ bool ClauseProcessor::processMotionClauses(lower::StatementContext &stmtCtx,
     // Support motion modifiers: iterator.
     std::string mapperIdName = getMapperIdentifier(converter, mapper);
 
-    if (iterator)
-      TODO(clauseLocation, "Iterator modifier is not supported yet");
     TodoLocators(clauseLocation, objects);
 
-    processMapObjects(stmtCtx, clauseLocation, objects, mapTypeBits,
-                      parentMemberIndices, result.mapVars, mapObjects,
-                      mapperIdName, /*isMotionModifier=*/true);
+    if (iterator) {
+      // Iterator modifier present: route each object to iterated or plain path.
+      llvm::SmallVector<IteratorRange> iteratorRanges;
+      llvm::SmallPtrSet<const Fortran::semantics::Symbol *, 4> ivSyms;
+      collectIteratorIVs(clause, converter, stmtCtx, iteratorRanges, ivSyms);
+
+      processMapObjectsWithIterator(
+          stmtCtx, clauseLocation, objects, iteratorRanges, &ivSyms,
+          mapTypeBits, parentMemberIndices, result, mapObjects, mapperIdName,
+          /*isMotionModifier=*/true, llvm::omp::Directive::OMPD_target_update);
+    } else {
+      processMapObjectsWithIterator(
+          stmtCtx, clauseLocation, objects, /*iteratorRanges=*/{},
+          /*ivSyms=*/nullptr, mapTypeBits, parentMemberIndices, result,
+          mapObjects, mapperIdName, /*isMotionModifier=*/true,
+          llvm::omp::Directive::OMPD_target_update);
----------------
MattPD wrote:

Passing `OMPD_target_update` here changes behaviour for ordinary `target update`. Before this PR the call passed no directive, so `resolveMapperId` received `OMPD_unknown`. `resolveMapperId` excludes `OMPD_target_update` from implicit default mapper synthesis, so a plain `target update` loses its compiler-generated default mapper.

```fortran
subroutine updonly()
  type :: t
    integer, allocatable :: a(:)
  end type
  type(t) :: x
  !$omp target update to(x)
end subroutine
```

Before, `omp.declare_mapper @_QQFupdonlyt_omp_default_mapper` is emitted and the map carries `mapper(@...)`. After, neither appears. The loss affects `to` and `from`, derived types with direct or nested allocatable components, `type(c_ptr)`, and allocatable or pointer derived-type objects. A preceding `target data` for the same type masks the loss, because the mapper is created earlier.

Was passing `OMPD_target_update` here intended, or should this path pass `OMPD_unknown`?

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


More information about the flang-commits mailing list