From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66523 invoked by alias); 11 Aug 2016 16:27:08 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 66496 invoked by uid 89); 11 Aug 2016 16:27:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=bloated, 43pm, sk:gfc_omp, bloating X-Spam-User: qpsmtpd, 2 recipients X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 11 Aug 2016 16:26:55 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1bXson-00043A-EN from Thomas_Schwinge@mentor.com ; Thu, 11 Aug 2016 09:26:53 -0700 Received: from hertz.schwinge.homeip.net (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.3.224.2; Thu, 11 Aug 2016 17:26:52 +0100 From: Thomas Schwinge To: Cesar Philippidis , Jakub Jelinek CC: "gcc-patches@gcc.gnu.org" , Fortran List , Tobias Burnus Subject: Re: [WIP] [PR fortran/72741] Rework Fortran OpenACC routine clause handling (was: [PATCH] OpenACC routines in fortran modules) In-Reply-To: <20160811154026.GV14857@tucnak.redhat.com> References: <579973CB.3070006@codesourcery.com> <579AD9C9.3030804@codesourcery.com> <5776D55A.4030002@codesourcery.com> <878tw35o6k.fsf@kepler.schwinge.homeip.net> <20160811154026.GV14857@tucnak.redhat.com> User-Agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Thu, 11 Aug 2016 16:27:00 -0000 Message-ID: <871t1vi851.fsf@hertz.schwinge.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-SW-Source: 2016-08/txt/msg00944.txt.bz2 Hi! As Cesar asked for it, there is now a Git branch tschwinge/omp/pr72741-wip containing these changes (plus some other pending changes that I didn't single out at this time), at . (I expect it does, but I didn't verify that this actually builds; I have further changes on top of that.) Cesar, please tell me if you'd like me to push this to GitHub, in case you want to use their review/commentary functions, or the like. On Thu, 11 Aug 2016 17:40:26 +0200, Jakub Jelinek wrote: > On Thu, Aug 11, 2016 at 05:18:43PM +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 subrout= ines? 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 int= erface body for a subroutine or function in an interface block, and applies= to the containing subroutine or function. The routine directive with a nam= e 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".) > In the latter case, it is much better to add some openacc specific pointer > into the namespace structure and stick everything you need into some cust= om > structure it will refer to. E.g. look at gfc_omp_declare_simd struct > in ns->omp_declare_simd. Thanks for the suggestion, I'll look into that. > omp_clauses_locus makes no sense, symbol_attribute contains parsed info f= rom > 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. Gr=C3=BC=C3=9Fe Thomas