From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 86486 invoked by alias); 11 Aug 2016 15:40:35 -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 86456 invoked by uid 89); 11 Aug 2016 15:40:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=bloated X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 11 Aug 2016 15:40:33 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2D8BEC04B334; Thu, 11 Aug 2016 15:40:32 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-204-43.brq.redhat.com [10.40.204.43]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u7BFeUPa029517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 11 Aug 2016 11:40:31 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id u7BFeStd015156; Thu, 11 Aug 2016 17:40:29 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id u7BFeQ6T015155; Thu, 11 Aug 2016 17:40:26 +0200 Date: Thu, 11 Aug 2016 15:40:00 -0000 From: Jakub Jelinek To: Thomas Schwinge Cc: Cesar Philippidis , "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) Message-ID: <20160811154026.GV14857@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <579973CB.3070006@codesourcery.com> <579AD9C9.3030804@codesourcery.com> <5776D55A.4030002@codesourcery.com> <878tw35o6k.fsf@kepler.schwinge.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <878tw35o6k.fsf@kepler.schwinge.homeip.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg00935.txt.bz2 On Thu, Aug 11, 2016 at 05:18:43PM +0200, Thomas Schwinge wrote: > --- gcc/fortran/gfortran.h > +++ gcc/fortran/gfortran.h > @@ -729,7 +839,7 @@ ext_attr_t; > extern const ext_attr_t ext_attr_list[]; > > /* Symbol attribute structure. */ > -typedef struct > +typedef struct symbol_attribute > { > /* Variable attributes. */ > unsigned allocatable:1, dimension:1, codimension:1, external:1, intrinsic:1, > @@ -864,6 +974,13 @@ typedef struct > /* Mentioned in OMP DECLARE TARGET. */ > unsigned omp_declare_target:1; > > + /* OpenACC routine. */ > + unsigned oacc_routine:1; > + unsigned oacc_routine_gang:1; > + unsigned oacc_routine_worker:1; > + unsigned oacc_routine_vector:1; > + unsigned oacc_routine_seq:1; > + > /* Mentioned in OACC DECLARE. */ > unsigned oacc_declare_create:1; > unsigned oacc_declare_copyin:1; > @@ -871,137 +988,24 @@ typedef struct > unsigned oacc_declare_device_resident:1; > unsigned oacc_declare_link:1; > > - /* This is an OpenACC acclerator function at level N - 1 */ > - ENUM_BITFIELD (oacc_function) oacc_function:3; > - > /* Attributes set by compiler extensions (!GCC$ ATTRIBUTES). */ > unsigned ext_attr:EXT_ATTR_NUM; > > + /* Location information for OMP clauses. */ > + //TODO: how to handle in module.c/symbol.c? > + locus omp_clauses_locus; > + > /* The namespace where the attribute has been set. */ > struct gfc_namespace *volatile_ns, *asynchronous_ns; > + > + /* Chain to another set of symbol attributes. Currently only used for > + OpenACC routine. */ > + //TODO: how to handle in module.c/symbol.c? > + struct symbol_attribute *next; 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? 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 custom structure it will refer to. E.g. look at gfc_omp_declare_simd struct in ns->omp_declare_simd. omp_clauses_locus makes no sense, symbol_attribute contains parsed info from many different clauses, which one it is? Jakub