[Mlir-commits] [llvm] [mlir] [mlir][OpenMP] Allow multi-block omp.iterator regions (PR #229198)
llvmlistbot at llvm.org
llvmlistbot at llvm.org
Mon Oct 5 21:08:27 PDT 2026
================
@@ -2727,7 +2727,7 @@ def AffinityEntryOp : OpenMP_Op<"affinity_entry", [Pure]> {
// Iterator Op
//===----------------------------------------------------------------------===//
-def IteratorOp : OpenMP_Op<"iterator", [AttrSizedOperandSegments, SingleBlock],
+def IteratorOp : OpenMP_Op<"iterator", [AttrSizedOperandSegments],
----------------
MattPD wrote:
The newly accepted control flow also exposes the old empty-range count on valid Fortran. For `m=2,d=0`, this range is empty, but the generated count is `(m-3)/2+1 == 1`. The locator executes and divides by zero:
```fortran
subroutine s(a, m, d)
integer :: a(8), m, d
character(4) :: c
c = 'xx '
!$omp task depend(iterator(i=3:m:2), in:a(i/d+len_trim(c)))
!$omp end task
end
```
`flang -fc1 -emit-llvm -fopenmp -fopenmp-version=52 -o - repro.f90` shows the count and division. Before the patch, this input failed the single-block check. With the patch, the compiled code terminates with SIGFPE for those arguments, while `m=3,d=1` produces the expected single entry.
Do you think you could include the required empty-range counting correction here, so the newly accepted regions work before https://github.com/llvm/llvm-project/pull/227454 lands?
https://github.com/llvm/llvm-project/pull/229198
More information about the Mlir-commits
mailing list