From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64588 invoked by alias); 20 May 2016 16:21:31 -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 64575 invoked by uid 89); 20 May 2016 16:21:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=watch 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 20 May 2016 16:21:29 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (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 62CB815447; Fri, 20 May 2016 16:21:28 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-88.ams2.redhat.com [10.36.116.88]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u4KGLQA3004387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 20 May 2016 12:21:27 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id u4KGLOtp027395; Fri, 20 May 2016 18:21:24 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id u4KGLKOG027394; Fri, 20 May 2016 18:21:20 +0200 Date: Fri, 20 May 2016 16:21:00 -0000 From: Jakub Jelinek To: Ilya Verbin , Alexander Monakov , Nathan Sidwell , Thomas Schwinge , Jan Hubicka Cc: gcc-patches@gcc.gnu.org Subject: "omp declare target" on DECL_EXTERNAL vars Message-ID: <20160520162120.GO28550@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20160520161244.GN28550@tucnak.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160520161244.GN28550@tucnak.redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes X-SW-Source: 2016-05/txt/msg01671.txt.bz2 Hi! While working on this patch, I've noticed the need to do: On Fri, May 20, 2016 at 06:12:44PM +0200, Jakub Jelinek wrote: > * varpool.c (varpool_node::get_create): Set node->offloading > even for DECL_EXTERNAL decls. ... > --- gcc/varpool.c.jj 2016-05-04 18:43:25.000000000 +0200 > +++ gcc/varpool.c 2016-05-20 12:18:14.636755302 +0200 > @@ -149,11 +149,11 @@ varpool_node::get_create (tree decl) > node = varpool_node::create_empty (); > node->decl = decl; > > - if ((flag_openacc || flag_openmp) && !DECL_EXTERNAL (decl) > + if ((flag_openacc || flag_openmp) > && lookup_attribute ("omp declare target", DECL_ATTRIBUTES (decl))) > { > node->offloadable = 1; > - if (ENABLE_OFFLOADING) > + if (ENABLE_OFFLOADING && !DECL_EXTERNAL (decl)) > { > g->have_offload = true; > if (!in_lto_p) but that made me think on what handling do we want for the "omp declare target" DECL_EXTERNAL vars. The reason I needed the above is that both gimplify.c and omp-low.c test just the node->offloadable flag, bit the attribute, and so when it is external and the flag wasn't set, we could privatize the vars even when we were supposed to map them etc. In the C/C++ FEs, we set not just node->offloadable, but also for ENABLE_OFFLOADING g->have_offload and offload_vars too. Wonder if that means we register even non-local vars, that would be IMHO a bug. On the other side, we need to watch for an extern declaration of a VAR_DECL marked for offloading and only later on locally defined, in that case if we haven't set g->have_offload and added entry to offload_vars, we'd need to do it when merging the extern decl with the definition. So, your thoughts on that? Jakub