[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