From: Julian Brown <julian@codesourcery.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
Cesar Philippidis <cesar@codesourcery.com>
Subject: Re: [PATCH, OpenACC] Support Fortran derived type members in "acc update" directives
Date: Tue, 04 Dec 2018 19:06:00 -0000 [thread overview]
Message-ID: <20181204190643.1d71e768@squid.athome> (raw)
In-Reply-To: <20181204141708.GX12380@tucnak>
Hi Jakub,
On Tue, 4 Dec 2018 15:17:08 +0100
Jakub Jelinek <jakub@redhat.com> wrote:
> On Mon, Sep 03, 2018 at 08:46:54PM -0400, Julian Brown wrote:
> > 2018-09-03 Cesar Philippidis <cesar@codesourcery.com>
> >
> > gcc/fortran/
> > * openmp.c (gfc_match_omp_variable_list): New allow_derived
> > argument. (gfc_match_omp_map_clause): Update call to
> > gfc_match_omp_variable_list. (gfc_match_omp_clauses): Update
> > calls to gfc_match_omp_map_clause. (gfc_match_oacc_update):
> > Update call to gfc_match_omp_clauses. (resolve_omp_clauses):
> > Permit derived type variables in ACC UPDATE clauses.
> > * trans-openmp.c (gfc_trans_omp_clauses_1): Lower derived
> > type members.
> >
> > gcc/
> > * gimplify.c (gimplify_scan_omp_clauses): Update handling
> > of ACC UPDATE variables.
> >
> > gcc/testsuite/
> > * gfortran.dg/goacc/derived-types.f90: New test.
> >
> > libgomp/
> > * testsuite/libgomp.oacc-fortran/update-2.f90: New test.
> > * testsuite/libgomp.oacc-fortran/derived-type-1.f90: New
> > test.
>
> Note, already OpenMP 4.5 allows the %s in map/to/from clauses, I just
> didn't get to that yet.
> And OpenMP 5.0 allows arbitrary expressions there.
>
> > @@ -4336,9 +4342,12 @@ resolve_omp_clauses (gfc_code *code,
> > gfc_omp_clauses *omp_clauses, || n->expr->ref == NULL
> > || n->expr->ref->next
> > || n->expr->ref->type != REF_ARRAY)
> > - gfc_error ("%qs in %s clause at %L is not a
> > proper "
> > - "array section", n->sym->name,
> > name,
> > - &n->where);
> > + {
> > + if (n->sym->ts.type != BT_DERIVED)
> > + gfc_error ("%qs in %s clause at %L is
> > not a proper "
> > + "array section",
> > n->sym->name, name,
> > + &n->where);
> > + }
> > else if (n->expr->ref->u.ar.codimen)
> > gfc_error ("Coarrays not supported in %s
> > clause at %L", name, &n->where);
>
> I'm worried about this change a little bit. It isn't guarded for
> OpenACC only and I wonder if you actually resolve properly the
> derived expressions (look inside of those).
>
> > diff --git a/gcc/fortran/trans-openmp.c b/gcc/fortran/trans-openmp.c
> > index f038f4c..95b15e5 100644
> > --- a/gcc/fortran/trans-openmp.c
> > +++ b/gcc/fortran/trans-openmp.c
> > @@ -2108,7 +2108,68 @@ gfc_trans_omp_clauses (stmtblock_t *block,
> > gfc_omp_clauses *clauses, tree decl = gfc_get_symbol_decl (n->sym);
> > if (DECL_P (decl))
> > TREE_ADDRESSABLE (decl) = 1;
> > - if (n->expr == NULL || n->expr->ref->u.ar.type ==
> > AR_FULL)
> > + /* Handle derived-typed members for OpenACC Update.
> > */
> > + if (n->sym->ts.type == BT_DERIVED
> > + && n->expr != NULL && n->expr->ref != NULL
> > + && (n->expr->ref->next == NULL
> > + || (n->expr->ref->next != NULL
> > + && n->expr->ref->next->type == REF_ARRAY
> > + && n->expr->ref->next->u.ar.type ==
> > AR_FULL))
> > + && (n->expr->ref->type == REF_ARRAY
> > + && n->expr->ref->u.ar.type != AR_SECTION))
>
> Like here you have all kinds of conditions, but has resolving made
> sure all the needed diagnostics is emitted?
> Perhaps at least for now this also should be guarded on OpenACC only,
> once OpenMP allows %s in map/to/from, part of this will be usable for
> it, but e.g.
>
> > + if (context != type)
> > + {
> > + tree f2 = c->norestrict_decl;
> > + if (!f2 || DECL_FIELD_CONTEXT (f2) != type)
> > + for (f2 = TYPE_FIELDS (TREE_TYPE (decl));
> > f2;
> > + f2 = DECL_CHAIN (f2))
> > + if (TREE_CODE (f2) == FIELD_DECL
> > + && DECL_NAME (f2) == DECL_NAME
> > (field))
> > + break;
> > + gcc_assert (f2);
> > + c->norestrict_decl = f2;
> > + field = f2;
> > + }
>
> the above stuff looks way too OpenACC specific.
Thanks for the review! As it happened though, I had to rewrite a lot of
the code in this patch for the attach/detach patch, and I had meant to
withdraw this one. Many apologies about the wasted time! I mentioned
the superseding in the first submission of the attach/detach patch:
https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00826.html
but omitted to follow up with a link back from this patch to that one.
A revised version of the attach/detach patch is here:
https://gcc.gnu.org/ml/gcc-patches/2018-11/msg02556.html
OpenACC 2.6 allows derived type member accesses (or structs, etc.) on
more types of directive than just "update", so this patch wasn't
sufficient -- for the new code replacing the bits in this patch (i.e.
the bits under gcc/fortran), I tried to integrate with the existing
code a little better, hopefully without disturbing the OpenMP side too
much.
I transferred the new tests from this patch over to the attach/detach
patch also, where of course they pass.
Cheers,
Julian
next prev parent reply other threads:[~2018-12-04 19:06 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-04 0:47 Julian Brown
2018-12-04 14:17 ` Jakub Jelinek
2018-12-04 19:06 ` Julian Brown [this message]
2018-12-04 19:13 ` Jakub Jelinek
2018-12-04 19:20 ` Julian Brown
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=20181204190643.1d71e768@squid.athome \
--to=julian@codesourcery.com \
--cc=cesar@codesourcery.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.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).