From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa4.mentor.iphmx.com (esa4.mentor.iphmx.com [68.232.137.252]) by sourceware.org (Postfix) with ESMTPS id 73FFC3858C60; Thu, 7 Oct 2021 16:33:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 73FFC3858C60 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com IronPort-SDR: PnTjcoBoWq56Wot/Hs7Eicycl2KQR6+x9PLnulVI9b739nd7+tdkKkbZV7GMkoncMAObNeETdi KHDxBYGxWLaDR7eC4dGf/r3c7VeKJXHT8r8bxVA2IiNPjgmuBsEGL1i/FvKsLncsp9NzS2sXoP hj6okYoQ2GcDBLR7ZKjZpmFZwtLO2yMSse4xn2SuzLFDA9JjCcGgqcT/B/JluFV8bG9WUg1eBG 0sVZZ4qGES27Nu5/H1DQCJjftVNArUuiOaL6yHevvIfJgbg/czcot46ip+6lCoUtaIimhb3AVI hdCQwAOqGevDurlrxbULt6ol X-IronPort-AV: E=Sophos;i="5.85,355,1624348800"; d="scan'208";a="66939751" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa4.mentor.iphmx.com with ESMTP; 07 Oct 2021 08:33:11 -0800 IronPort-SDR: KOKm4TQ2tXBOJqw5MzRrXaLtYvohCJyU0F1pmXdBXVWjnmteyrDLV1BGCirTB88HjoxxaT2H4H zIkUeS+cHcr7dOjLYnGyc/FO9q/vhfvlXxtafGHkLgQyidiaLBHNfE89ON5go17tMg7u/qC2o5 Z4qikx5VoiMyOioOxwEFqVcaJCZj4P19wA/hZOFLrFT4/tH7XR+3NEbqNmkKRDg3XmPNhtPC0S xdWDeugxqy6jUoIw5jfAYjwD7i5jocSNN3GdhJgo6zJfYmMrEndX/YPGsyIiL43XhyaHa7iWy3 KHg= Message-ID: Date: Thu, 7 Oct 2021 18:33:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: [PATCH, OpenMP 5.1, Fortran] Strictly-structured block support for OpenMP directives Content-Language: en-US To: Chung-Lin Tang , gcc-patches , Fortran List , Catherine Moore , Jakub Jelinek References: <8d20877d-d52e-d90c-8a4e-a38f43921df1@codesourcery.com> From: Tobias Burnus In-Reply-To: <8d20877d-d52e-d90c-8a4e-a38f43921df1@codesourcery.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-06.mgc.mentorg.com (139.181.222.6) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, 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, 07 Oct 2021 16:33:14 -0000 Hi Chung-Lin, On 07.10.21 15:59, 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]=C2=A0 !! end directive is optional Pre-remark: That OpenMP feature causes ambiguities. I have filled an OpenMP spec issue to discuss this, Issue 3154. Namely the following is unclear: !$omp parallel !$omp parallel block x=3D x+ 1 end block !$omp end parallel Does the 'end parallel' end the inner strictly structured block or the outer loosely structured block? In principle, a compiler could defer this until later during parsing, but this requires a tremendous state tracking and it is surely not simple to do in gfortran (and probably all other compilers). =E2=80=94 Thus, I think the spec will change and probably in the way which this patch has implemented. NOTE: It takes the kind of directive into account, i.e. 'omp end target' vs. 'omp end parallel' aren't ambiguous. > 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) > > Tested with no regressions on trunk, is this okay to commit? LGTM =E2=80=93 unless Jakub has further comments. However, I have two requests: First, can you include an update of the implementation status in libgomp/libgomp.texi (+ fix the ...ppp... typo): "@item Suppport of strictly structured blocks in Fortran @tab N @tab" Secondly, can you extend the testcase a bit to include nesting a BLOCK inside the other BLOCK =E2=80=93 and nesting the directive with a strictly structured block inside another (different) directive to ensure that the 'omp end ...' is correctly matched. I mean something like: integer :: x !$omp target map(i) !$omp parallel block block x =3D x + 1 end block end block !$omp end target !$omp target map(i) !$omp parallel block block x =3D x + 1 end block end block !$omp end parallel !$omp end target end Thanks, Tobias > 2021-10-07 Chung-Lin Tang > > gcc/fortran/ChangeLog: > > * decl.c (gfc_match_end): Add COMP_OMP_STRICTLY_STRUCTURED_BLOCK case > together with COMP_BLOCK. > * parse.c (parse_omp_structured_block): Adjust declaration, add > 'bool strictly_structured_block' default true parameter, add handling > for strictly-structured block case, adjust recursive calls to > parse_omp_structured_block. > (parse_executable): Adjust calls to parse_omp_structured_block. > * parse.h (enum gfc_compile_state): Add > COMP_OMP_STRICTLY_STRUCTURED_BLOCK. > * trans-openmp.c (gfc_trans_omp_workshare): Add EXEC_BLOCK case > handling. > > gcc/testsuite/ChangeLog: > > * gfortran.dg/gomp/strictly-structured-block-1.f90: New test. ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstra=C3=9Fe 201= , 80634 M=C3=BCnchen; Gesellschaft mit beschr=C3=A4nkter Haftung; Gesch=C3= =A4ftsf=C3=BChrer: Thomas Heurung, Frank Th=C3=BCrauf; Sitz der Gesellschaf= t: M=C3=BCnchen; Registergericht M=C3=BCnchen, HRB 106955