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 [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id E3E463858C2C for ; Thu, 14 Oct 2021 10:21:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E3E463858C2C 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-193-bZlTlHK8NSe2t7KPkr0_mw-1; Thu, 14 Oct 2021 06:20:59 -0400 X-MC-Unique: bZlTlHK8NSe2t7KPkr0_mw-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C40DA8015C7; Thu, 14 Oct 2021 10:20:57 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.193.172]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3B4F35F4E2; Thu, 14 Oct 2021 10:20:57 +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 19EAKq3R2770375 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 14 Oct 2021 12:20:53 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 19EAKpJn2770374; Thu, 14 Oct 2021 12:20:51 +0200 Date: Thu, 14 Oct 2021 12:20:51 +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: <20211014102051.GJ920483@tucnak> Reply-To: Jakub Jelinek References: <8d20877d-d52e-d90c-8a4e-a38f43921df1@codesourcery.com> <20211007170905.GZ304296@tucnak> MIME-Version: 1.0 In-Reply-To: <20211007170905.GZ304296@tucnak> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 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=ham 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, 14 Oct 2021 10:21:06 -0000 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