On 2021/10/14 7:19 PM, Jakub Jelinek wrote:
On Thu, Oct 14, 2021 at 12:20:51PM +0200, Jakub Jelinek via Gcc-patches wrote:
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.
And I have to correct myself, there is no ambiguity in 5.2 here,
the important fact is hidden in sections/parallel sections being
block-associated constructs. That means the body of the whole construct
has to be a structured-block, and by the 5.1+ definition of Fortran
structured block, it is either block ... end block or something that
doesn't start with block.
So,
!$omp sections
block
end block
a = 1
is only ambiguous in whether it is actually
!$omp sections
block
!$omp section
end block
a = 1
or
!$omp sections
!$omp section
block
end block
!$omp end sections
a = 1
but both actually do the same thing, work roughly as !$omp single.
If one wants block statement as first in structured-block-sequence
of the first section, followed by either some further statements
or by other sections, then one needs to write
!$omp sections
!$omp section
block
end block
a = 1
...
!$omp end sections
or
!$omp sections
block
block
end block
a = 1
...
end block
Your patch probably already handles it that way, but we again need
testsuite coverage to prove it is handled the way it should in all these
cases (and that we diagnose what is invalid).
The patch currently does not allow strictly-structured BLOCK for
sections/parallel sections,
since I was referencing the 5.1 spec while writing it, although that is
trivially fixable.
(was sensing a bit odd why those two constructs had to be specially treated in
5.1 anyways)
The bigger issue is that under the current way the patch is written, the
statements inside
a [parallel] sections construct are parsed automatically by parse_executable(),
so to enforce
the specified meaning of "structured-block-sequence" (i.e. BLOCK or non-BLOCK
starting sequence of stmts)
will probably be more a bit harder to implement:
!$omp sections
block
!$omp section
block
x=0
end block
x=1 !! This is allowed now, though should be wrong spec-wise
!$omp section
x=2
end block
Currently "$!omp section" acts essentially as a top-level separator within a
sections-construct,
rather than a structured directive. Though I would kind of argue this is
actually better to use for the
user (why prohibit what looks like very apparent meaning of the program?)
So Jakub, my question for this is, is this current state okay? Or must we
implement the spec pedantically?
As for the other issues:
(1) BLOCK/END BLOCK is not generally handled in parse_omp_structured_block, so
for workshare,
it is only handled for the top-level construct, not within workshare. I
think this is what you meant
in the last mail.
(2) As for the dangling-!$omp_end issue Tobias raised, because we are basically
using 1-statement lookahead,
any "!$omp end <*>" is naturally bound with the adjacent BLOCK/END BLOCK,
so we should be okay there.
Thanks,
Chung-Lin
