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 ESMTPS id F10F838582A7 for ; Mon, 4 Jul 2022 14:53:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F10F838582A7 Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-50-VGwPlRV_N-uL-GfG_q49oA-1; Mon, 04 Jul 2022 10:53:11 -0400 X-MC-Unique: VGwPlRV_N-uL-GfG_q49oA-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 5685981D9CE; Mon, 4 Jul 2022 14:53:11 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.30]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 166EA1121315; Mon, 4 Jul 2022 14:53:10 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 264Er8H51675915 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 4 Jul 2022 16:53:08 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 264Er7N31675914; Mon, 4 Jul 2022 16:53:07 +0200 Date: Mon, 4 Jul 2022 16:53:07 +0200 From: Jakub Jelinek To: Tobias Burnus Cc: gcc-patches , fortran Subject: Re: [Patch] OpenMP/Fortran: Add support for OpenMP 5.2 linear clause syntax Message-ID: Reply-To: Jakub Jelinek References: <00106b18-d0f4-d449-73de-17831af2006a@codesourcery.com> MIME-Version: 1.0 In-Reply-To: <00106b18-d0f4-d449-73de-17831af2006a@codesourcery.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 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=-4.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: fortran@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Fortran mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2022 14:53:17 -0000 On Mon, Jul 04, 2022 at 04:10:03PM +0200, Tobias Burnus wrote: > This patch adds support for the OpenMP 5.2 syntax for the linear clause, > following the C/C++ patch. The testcases are modified versions from the > C/C++ ones, plus one added one for duplicated modifiers. > > At least to me it is not quite clear when > linear ( var : ref) > refers to a variable 'ref' and when to the linear-modifier 'ref'; the > spec does not seem to be very clear about it. I made an attempt, based See OpenMP 5.2 [59:31-34]: A modifier that is an expression must neither lexically match the name of a simple modifier defined for the clause that is an OpenMP keyword nor modifier-name parenthesized-tokens, where modifier-name is the modifier-name of a complex modifier defined for the clause and parenthesized-tokens is a token sequence that starts with ( and ends with ). So, ref can't be step expression because it lexically matches the name of a simple modifier, so linear (var : ref) is equivalent to old style linear (ref (var):1) while e.g. linear (var : ref + 0) is equivalent to linear (var : step (ref + 0)) > + else if (end_colon) > + { > + gfc_symtree *st; > + bool has_modifiers = false; > + bool duplicate_step = false; > + bool duplicate_mod = false; > + while (true) > + { > + old_loc = gfc_current_locus; > + if (gfc_match ("val )") == MATCH_YES) > + { So, if you see val ) even right after colon (when !old_linear_modifiers), it is always linear modifier, so the if (!has_modifiers) looks wrong. > + if (!has_modifiers) > + { > + gfc_find_sym_tree ("val", NULL, true, &st); > + bool has_val = (st > + && !st->n.sym->attr.function > + && !st->n.sym->attr.dimension); > + locus loc = gfc_current_locus; > + gfc_current_locus = old_loc; > + if (has_val > + && gfc_match (" %e ) ", &step) == MATCH_YES) > + break; > + gfc_current_locus = loc; > + } > + if (linear_op != OMP_LINEAR_DEFAULT) > + { > + duplicate_mod = true; > + break; > + } > + linear_op = OMP_LINEAR_VAL; > + has_modifiers = true; > + break; > + } > + else if (gfc_match ("uval )") == MATCH_YES) > + { Likewise. > + if (!has_modifiers) > + else if (gfc_match ("ref )") == MATCH_YES) > + { And again. > + if (!has_modifiers) > + else if (gfc_match ("step ( ") == MATCH_YES) > + { step ( could start both valid step expression and be a valid modifier. But that decision shouldn't be based on whether there is a step symtree or not, but whether it is step ( whatever ) ) or step ( whatever ) , (in that case it should be parsed as the complex modifier with expression in it), otherwise it is parsed as step expression. The whatever above means some tokens with balanced parentheses. I doubt the Fortran FE has something like that right now. You can certainly try to match "step ( %e ) )" or "step ( %e ) , " first, those would handle the case of valid complex modifier. But, I think if there is interface integer function step (x, y, z) integer :: x, y, z end function step end interface then linear (v : step (x, y, z)) should be rejected, not accepted as valid linear (v : step (step (x, y, z))) I think I should add: int step (int x, int y, int z) { return x + y + z; } int foo (int x) { int i; #pragma omp parallel for linear (x : step (step (1, 2, 3))) for (i = 0; i < 64; i++) x += 6; return x; } int bar (int x) { int i; #pragma omp parallel for linear (x : step (1, 2, 3)) /* { dg-error "expected" } */ for (i = 0; i < 64; i++) x += 6; return x; } as another testcase (where foo used to be invalid before and bar used to be valid). Jakub