[llvm] [openmp] [OpenMP][DeviceRTL] Fix the chunked static distribution dropping iterations (PR #216117)

Spencer Bryngelson via llvm-commits llvm-commits at lists.llvm.org
Thu Aug 13 12:51:00 PDT 2026


sbryngelson wrote:

Yes, Fortran: #214303, where `schedule(static,C)` is ignored on device.

A pragma test cannot reach this code. Compiled for gfx90a with current main (53a702813473), these three

```c
#pragma omp target teams distribute parallel for schedule(static, 4)
#pragma omp target teams distribute parallel for
#pragma omp target parallel for schedule(static, 4)
```

emit `__kmpc_for_static_init_4` and `__kmpc_distribute_static_init_4`. No `*_static_loop_*` entry appears at all; clang uses the `*_static_init_*` family. Only flang emits `__kmpc_distribute_for_static_loop_*`, so a C test would compile and pass without entering the code being fixed.

The file reference was too terse, sorry: `offload/test/offloading/distribute_for_no_loop_num_threads.c`, added by 9c317bbbdbea (#214073) two days ago, so it may predate your checkout. Same problem, same approach: it calls the entry directly and says why at the top.

On existing coverage: the `*_static_loop_*` entries are referenced by six MLIR lit tests and an OMPIRBuilder unit test, but those check emitted IR. That offload test is the only one that executes them, and it passes `ThreadChunk = 0`. No test in tree passes a non-zero chunk, so this would not have been caught regardless of @DominikAdamski's tests.

If you would rather avoid a direct-call test, the alternative is to land this with the flang side of #214303 and test through `!$omp ... schedule(static,4)`. That gives a source-level test, at the cost of coupling a runtime fix to a frontend change.


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


More information about the llvm-commits mailing list