public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Thomas Schwinge <thomas@codesourcery.com>
Cc: Cesar Philippidis <cesar@codesourcery.com>,
	       "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
	       Fortran List <fortran@gcc.gnu.org>,
	       Tobias Burnus <tobias.burnus@physik.fu-berlin.de>
Subject: Re: [WIP] [PR fortran/72741] Rework Fortran OpenACC routine clause handling (was: [PATCH] OpenACC routines in fortran modules)
Date: Thu, 11 Aug 2016 16:42:00 -0000	[thread overview]
Message-ID: <20160811164158.GW14857@tucnak.redhat.com> (raw)
In-Reply-To: <871t1vi851.fsf@hertz.schwinge.homeip.net>

On Thu, Aug 11, 2016 at 06:26:50PM +0200, Thomas Schwinge wrote:
> > > --- gcc/fortran/gfortran.h
> > > +++ gcc/fortran/gfortran.h
> 
> > >  /* Symbol attribute structure.  */
> > > -typedef struct
> > > +typedef struct symbol_attribute
> > >  {
> 
> > While symbol_attribute is already bloated, I don't like bloating it this
> > much further.  Do you really need it for all symbols, or just all subroutines?
> 
> Certainly not for all symbole; just for what is valid to be used with the
> OpenACC routine directive, which per OpenACC 2.0a, 2.13.1 Routine
> Directive is:
> 
>     In Fortran the syntax of the routine directive is:
>         !$acc routine clause-list
>         !$acc routine( name ) clause-list
>     In Fortran, the routine directive without a name may appear within the specification part of a subroutine or function definition, or within an interface body for a subroutine or function in an interface block, and applies to the containing subroutine or function. The routine directive with a name may appear in the specification part of a subroutine, function or module, and applies to the named subroutine or function.
> 
> (Pasting that in full just in case that contains some additional Fortran
> lingo, meaning more than "subroutines".)

By "subroutines" I've meant of course also functions, those have their own
namespace structure too.

> > omp_clauses_locus makes no sense, symbol_attribute contains parsed info from
> > many different clauses, which one it is?
> 
> Well, it makes some sense -- it works no worse than the existing code ;-)
> -- but I agree that it's not exactly pretty.  To the best of my
> knowledge, in Fortran OpenACC/OpenMP clauses parsing, we're currently not
> tracking (saving) specific location information for individual clauses
> (at least, that's what a casual scan through the code, and
> gfc_match_oacc_routine or gfc_match_omp_declare_target in particular make
> me think: gfc_omp_clauses collects all clause data, but only contains a
> single "locus loc" member (which maybe I should have used instead of
> "old_loc", the location information for the directive itself?).  Maybe I
> misunderstood, and we do have more precise location information available
> for individual clauses?  In that case, I'll happily use that, of course.

The Fortran FE generally doesn't track locations of any of the attributes
symbols have, attributes as well as OpenMP clauses are represented just as
bits (for boolean stuff), etc., only if you have some expression you have
location for the expression.
I don't see what is so special on these clauses that they need to have
location tracked compared to say CONTIGUOUS or whatever other attribute, just
use the location of the function.  Unless of course you want to rewrite all
the Fortran FE data structures and track detailed locations for everything.
But just treating selected OpenACC clauses specially, ignoring how the FE is
structured, is at least inconsistent with the rest.

	Jakub

  reply	other threads:[~2016-08-11 16:42 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-28  2:54 [gomp4] encode acc routine clauses inside fortran module files Cesar Philippidis
2016-07-29  4:21 ` [gomp4] Fix PR72741 Cesar Philippidis
2016-07-01 20:41   ` [PATCH] OpenACC routines in fortran modules Cesar Philippidis
2016-07-28  9:55     ` Tobias Burnus
2016-07-28 21:33       ` Cesar Philippidis
2016-08-11 15:19     ` [WIP] [PR fortran/72741] Rework Fortran OpenACC routine clause handling (was: [PATCH] OpenACC routines in fortran modules) Thomas Schwinge
2016-08-11 15:40       ` Jakub Jelinek
2016-08-11 16:27         ` Thomas Schwinge
2016-08-11 16:42           ` Jakub Jelinek [this message]
2016-08-16  1:55           ` [WIP] [PR fortran/72741] Rework Fortran OpenACC routine clause handling Cesar Philippidis
2016-08-16 22:17             ` Thomas Schwinge
2019-02-28 20:37             ` [PR72741, PR89433] Repeated use of the Fortran OpenACC 'routine' directive Thomas Schwinge
2019-03-21 19:57               ` Thomas Schwinge
2016-08-11 16:44       ` [WIP] [PR fortran/72741] Rework Fortran OpenACC routine clause handling Cesar Philippidis
2019-02-28 20:35   ` [PR72741] For all Fortran OpenACC 'routine' directive variants check for multiple clauses specifying the level of parallelism Thomas Schwinge

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=20160811164158.GW14857@tucnak.redhat.com \
    --to=jakub@redhat.com \
    --cc=cesar@codesourcery.com \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=thomas@codesourcery.com \
    --cc=tobias.burnus@physik.fu-berlin.de \
    /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).