Re: [PATCH, OpenMP 5.1, Fortran] Strictly-structured block support for OpenMP directives

[Chung-Lin Tang <cltang@codesourcery.com>]

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