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

[via flang-commits]

================
@@ -1924,6 +1968,56 @@ void ClauseProcessor::processMapObjects(
   }
 }
 
+// Process objects in map/motion clauses, lowering iterator-dependent
+// locators into `result.mapIterated` and all others through the regular
+// map-lowering path. A null `ivSyms` indicates that no iterator modifier
+// is present.
+void ClauseProcessor::processMapObjectsWithIterator(
+    lower::StatementContext &stmtCtx, mlir::Location clauseLocation,
+    const omp::ObjectList &objects,
+    llvm::ArrayRef<IteratorRange> iteratorRanges,
+    const llvm::SmallPtrSetImpl<const semantics::Symbol *> *ivSyms,
+    mlir::omp::ClauseMapFlags mapTypeBits,
+    std::map<Object, OmpMapParentAndMemberData> &parentMemberIndices,
+    mlir::omp::MapClauseOps &result, llvm::SmallVectorImpl<Object> &mapObjects,
+    llvm::StringRef mapperIdNameRef, bool isMotionModifier,
+    llvm::omp::Directive directive) const {
+  if (!ivSyms) {
+    processMapObjects(stmtCtx, clauseLocation, objects, mapTypeBits,
+                      parentMemberIndices, result.mapVars, mapObjects,
+                      mapperIdNameRef, isMotionModifier, directive);
+    return;
+  }
+
+  // Inside a declare mapper, the mapper variable's components are mapped
+  // directly, allowing member locators such as v%a(i). Mapping a derived-type
+  // member outside a declare mapper requires parent/member handling that
+  // iterator modifiers do not support yet.
+  bool inDeclareMapper = mlir::isa_and_present<mlir::omp::DeclareMapperOp>(
+      converter.getFirOpBuilder().getRegion().getParentOp());
+
+  // Objects in an iterator-modified clause may independently reference
+  // iterator variables, so handle each object separately.
+  for (const omp::Object &object : objects) {
+    if (hasIteratorIVReference(object, *ivSyms)) {
+      if (!inDeclareMapper && getBaseObject(object, semaCtx))
+        TODO(clauseLocation, "iterator modifier with derived type member map");
----------------
MattPD wrote:

The lowering gap here predates this PR. What changed is that the not-yet-implemented diagnostic no longer shields the iterator spelling.

`inDeclareMapper` tests where the builder is inserting, not whose member is being mapped. It therefore waives the diagnostic for any object inside a declare mapper, including a mapped object whose base is not the declare-mapper variable. With a module variable `w`, `!$omp declare mapper(m: t :: v) map(iterator(i = 1:10): w%a(i))` now triggers `'hlfir.designate' op using value defined outside the region`, then `verification of lowering to FIR failed`. Before this PR the same spelling gave a clean not-yet-implemented. The non-iterator spelling `map(w%a)` fails identically before and after.

Would comparing the object's base against the declare-mapper variable be a better predicate than the insertion point?

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