[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