From: Jakub Jelinek <jakub@redhat.com>
To: Tobias Burnus <tobias@codesourcery.com>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>, fortran <fortran@gcc.gnu.org>
Subject: Re: [Patch] OpenMP/Fortran: Add support for OpenMP 5.2 linear clause syntax
Date: Mon, 4 Jul 2022 16:53:07 +0200 [thread overview]
Message-ID: <YsL+03j3NxpUS0ns@tucnak> (raw)
In-Reply-To: <00106b18-d0f4-d449-73de-17831af2006a@codesourcery.com>
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
next prev parent reply other threads:[~2022-07-04 14:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-04 14:10 Tobias Burnus
2022-07-04 14:53 ` Jakub Jelinek [this message]
2022-07-04 16:09 ` Tobias Burnus
2022-07-04 17:20 ` Jakub Jelinek
2022-07-04 18:29 ` Tobias Burnus
2022-07-04 19:08 ` Jakub Jelinek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YsL+03j3NxpUS0ns@tucnak \
--to=jakub@redhat.com \
--cc=fortran@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=tobias@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).