public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
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

  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).