On Thu, Oct 07, 2021 at 07:09:07PM +0200, Jakub Jelinek wrote: > The workshare/parallel workshare case is unclear, I've filed > https://github.com/OpenMP/spec/issues/3153 > for it. Either don't allow block if workshare_stmts_only for now > until that is clarified, or if we do, we need to make sure that it does the > expected thing, does that gfc_trans_block_construct call ensure it? > > Then we have the > https://github.com/OpenMP/spec/issues/3154 > issue Tobias discovered, if that issue is resolved to end always applying to > the directive before the block statement, I think your patch handles it that > way but we want testsuite coverage for some of those cases.
Just want to follow-up on this, we now have resolutions of the https://github.com/OpenMP/spec/issues/3153 https://github.com/OpenMP/spec/issues/3154 https://github.com/OpenMP/spec/issues/3155 issues and we can use that to guide this patch. BLOCK is now explicitly allowed for workshare around the body of workshare/parallel workshare or around the body of critical in it but not arbitrarily nested. My understanding of the patch is that it most likely implements that, just we need a testsuite coverage that !$omp workshare block a = 1 b = 2 !$omp critical block c = 3 end block end block is fine (also with !$omp end {criticial,workshare} after the block), but that !$omp workshare a = 1 block b = 2 c = 3 end block !$omp end workshare etc. is diagnosed. For Tobias' issue that !$omp end whatever after end block for strictly structured block binds to the directive above the strictly structured block I think the patch also implements it but we want again testsuite coverage, that subroutine foo !$omp parallel !$omp parallel block end block !$omp end parallel !$omp end parallel end subroutine foo subroutine bar !$omp teams !$omp parallel block end block !$omp end teams end subroutine bar is fine while e.g. subroutine baz !$omp parallel !$omp parallel block end block !$omp end parallel end subroutine baz is not (!$omp end parallel pairs with the inner parallel rather than outer, and the outer parallel's body doesn't start with BLOCK, so needs to be paired with its !$omp end parallel). And lastly, the 3rd ticket clarifies that for the separating directives for Fortran basically the 5.0 state remains except that the body can be now also optionally wrapped in a single BLOCK. (And for C/C++ allows no statements at all in between the separating directives or after/before them but still requires the {}s around it like 5.1 and earlier. Here we implement the 5.1 wording and let's stay with that.) Thinking more about the Fortran case for !$omp sections, there is an ambiguity. !$omp sections block !$omp section end block is clear and !$omp end sections is optional, but !$omp sections block end block is ambiguous during parsing, it could be either followed by !$omp section and then the BLOCK would be first section, or by !$omp end sections and then it would be clearly the whole sections, with first section being empty inside of the block, or if it is followed by something else, it is ambiguous whether the block ... end block is part of the first section, followed by something and then we should be looking later for either !$omp section or !$omp end section to prove that, or if !$omp sections block end block was the whole sections construct and we shouldn't await anything further. I'm afraid back to the drawing board. Jakub