[flang-commits] [flang] [llvm] [mlir] [flang][OpenMP] Lower target in_reduction for host fallback (PR #199967)

Sairudra More via flang-commits flang-commits at lists.llvm.org
Tue Jun 30 23:32:53 PDT 2026


================
@@ -2220,12 +2221,25 @@ genTargetClauses(lower::AbstractConverter &converter,
     hostEvalInfo->collectValues(clauseOps.hostEvalVars);
   }
   cp.processIf(llvm::omp::Directive::OMPD_target, clauseOps);
+  cp.processInReduction(loc, clauseOps, inReductionObjects);
+  // The host fallback for `target in_reduction` redirects each list item's
+  // dedicated implicit map entry to the per-task reduction-private storage
+  // returned by the runtime. A COMMON block member is accessed in the target
+  // body through the COMMON block storage map, not through its own member map
+  // entry, so the redirect would rewrite an unused map argument and the body
+  // would accumulate into the mapped original rather than the private copy.
+  // Reject this case until the redirect can target the storage map.
+  for (const Object &object : inReductionObjects)
+    if (const semantics::Symbol *sym = object.sym())
+      if (semantics::FindCommonBlockContaining(sym->GetUltimate()))
----------------
Saieiei wrote:

Thanks, this was a good catch.

I added a narrow TODO diagnostic for `target in_reduction` list items that are actually privatized/firstprivatized, which covers the explicit `firstprivate(i) in_reduction(+:i)` case and avoids the `moldVar` assertion path.

While checking the host-associated internal-procedure case, I found that on current `main` the implicit firstprivate promotion is gated off by default, so that case no longer reaches the crash path and lowers successfully as a regular mapped `in_reduction` case. I therefore kept the guard focused on the actually-privatized case and added a targeted TODO test for the explicit firstprivate case.


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


More information about the flang-commits mailing list