From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id B38733858413 for ; Thu, 7 Oct 2021 17:57:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B38733858413 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-304-0mFFpDGYOMOpH0bu7-8MZw-1; Thu, 07 Oct 2021 13:57:20 -0400 X-MC-Unique: 0mFFpDGYOMOpH0bu7-8MZw-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 10F971AAF213; Thu, 7 Oct 2021 17:09:10 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.193.109]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 793C7A25C2; Thu, 7 Oct 2021 17:09:09 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 197H96He3944669 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 7 Oct 2021 19:09:07 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 197H95GS3944668; Thu, 7 Oct 2021 19:09:05 +0200 Date: Thu, 7 Oct 2021 19:09:05 +0200 From: Jakub Jelinek To: Chung-Lin Tang Cc: gcc-patches , Fortran List , Tobias Burnus , Catherine Moore Subject: Re: [PATCH, OpenMP 5.1, Fortran] Strictly-structured block support for OpenMP directives Message-ID: <20211007170905.GZ304296@tucnak> Reply-To: Jakub Jelinek References: <8d20877d-d52e-d90c-8a4e-a38f43921df1@codesourcery.com> MIME-Version: 1.0 In-Reply-To: <8d20877d-d52e-d90c-8a4e-a38f43921df1@codesourcery.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=unavailable autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2021 17:57:25 -0000 On Thu, Oct 07, 2021 at 09:59:00PM +0800, Chung-Lin Tang wrote: > this patch add support for "strictly-structured blocks" introduced in OpenMP 5.1, > basically allowing BLOCK constructs to serve as the body for directives: > > !$omp target > block > ... > end block > [!$omp end target] !! end directive is optional > > !$omp parallel > block > ... > end block > ... > !$omp end parallel !! error, considered as not match to above parallel directive > > The parsing loop in parse_omp_structured_block() has been modified to allow > a BLOCK construct after the first statement has been detected to be ST_BLOCK. > This is done by a hard modification of the state into (the new) COMP_OMP_STRICTLY_STRUCTURED_BLOCK > after the statement is known (I'm not sure if there's a way to 'peek' the next > statement/token in the Fortran FE, open to suggestions on how to better write this) Thanks for working on this. 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. For the testcases, I think best would be to split it into two, one that contains only what we want to accept and another one with dg-errors in it. I don't think the patch does the right thing for sections/parallel sections. That is (at least in 5.1) defined as: !$omp sections clauses... [!$omp section] structured-block-sequence [!$omp section structured-block-sequence] ... !$omp end sections (and similarly for parallel sections). I believe your patch properly disallows: !$omp sections block ... !$omp section ... end block !$omp end sections - block itself is allowed, e.g. !$omp sections block a=1 b=2 end block !$omp end sections with the meaning that the block is after the first implied !$omp section and there is nothing else. But does the patch actually check that !$omp sections block ... end block c=1 !$omp end sections or !$omp sections !$omp section block ... end block c=1 !$omp section d=1 !$omp end sections is invalid? Though, not sure if that was the intended effect, in OpenMP 5.0 that used to be fine. But then the other changes are backwards incompatible too, !$omp parallel block ... end block c=1 !$omp end parallel used to be valid but no longer is. structured-block-sequence is fortran defined as structured-block and structured-block is defined as either loosely-structured-block or strictly-structured-block, so for sections in between each !$omp section should be either anything not starting with block, or, if it starts with block, after end block there should be immediately !$omp section or !$omp end {,parallel }sections. Another thing is scan, the wording is similar and newly !$omp do reduction(+,inscan:a) do i=1,10 block ... end block x=1 !$omp scan block ... end block x=2 end do is invalid. > @@ -5538,6 +5539,32 @@ parse_omp_structured_block (gfc_statement omp_st, bool workshare_stmts_only) > gcc_unreachable (); > } > > + bool block_construct = false; > + gfc_namespace* my_ns = NULL; > + gfc_namespace* my_parent = NULL; The usual coding conventions put * before variable name instead of after it (except for libstdc++). > --- /dev/null > +++ b/gcc/testsuite/gfortran.dg/gomp/strictly-structured-block-1.f90 > @@ -0,0 +1,295 @@ > +! { dg-do compile } > +! { dg-options "-fopenmp" } > + > +program main > + integer :: x > + > + !$omp parallel > + block > + x = x + 1 > + end block > + > + !$omp parallel > + block > + x = x + 1 > + end block > + !$omp end parallel > + > + !$omp parallel > + block > + x = x + 1 > + end block > + x = x + 1 > + !$omp end parallel ! { dg-error "Unexpected !.OMP END PARALLEL statement" } Other than the splitting into non-dg-error stuff in one testcase and dg-error in another one, I think we want (probably in yet another pair of testcases) test what we are not required to do but with your patch we actually implement, in particular that !$omp master behaves the same way. > + !$omp ordered > + block > + x = x + 1 > + end block > + > + !$omp ordered > + block > + x = x + 1 > + end block > + !$omp end ordered > + > + !$omp ordered > + block > + x = x + 1 > + end block > + x = x + 1 > + !$omp end ordered ! { dg-error "Unexpected !.OMP END ORDERED statement" } I believe these 3 can't be done in the program, would either need to be wrapped in some !$omp do with ordered clause or should go each ordered into its own orphaned subroutine, because ordered region must bind to a worksharing-loop with ordered clause. I think wrapping it inside of !$omp do ordered is easier. Jakub