From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 116547 invoked by alias); 29 Sep 2015 08:18:23 -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 116537 invoked by uid 89); 29 Sep 2015 08:18:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 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; Tue, 29 Sep 2015 08:18:21 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 1492E8EA2F; Tue, 29 Sep 2015 08:18:20 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-44.ams2.redhat.com [10.36.116.44]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8T8IH9C003807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 29 Sep 2015 04:18:19 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id t8T8IGeO002718; Tue, 29 Sep 2015 10:18:17 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id t8T8IFXs002717; Tue, 29 Sep 2015 10:18:15 +0200 Date: Tue, 29 Sep 2015 09:48:00 -0000 From: Jakub Jelinek To: Thomas Schwinge Cc: gcc-patches@gcc.gnu.org, Bernd Schmidt , Nathan Sidwell , Joseph Myers Subject: Re: Ping^2 Re: Pass -foffload targets from driver to libgomp at link time Message-ID: <20150929081814.GD1847@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <55F18D87.6070208@redhat.com> <55F2E935.7010300@redhat.com> <87egjopgh0.fsf@kepler.schwinge.homeip.net> <20150911154349.GH1847@tucnak.redhat.com> <87a8s6vq69.fsf@kepler.schwinge.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87a8s6vq69.fsf@kepler.schwinge.homeip.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg02172.txt.bz2 On Mon, Sep 28, 2015 at 11:39:10AM +0200, Thomas Schwinge wrote: > Hi! > > On Fri, 11 Sep 2015 17:43:49 +0200, Jakub Jelinek wrote: > > So, do I understand well that you'll call GOMP_set_offload_targets from > > construct[ors] of all shared libraries (and the binary) that contain offloaded > > code? If yes, that is surely going to fail the assertions in there. > > Indeed. My original plan has been to generate/invoke this constructor > only for/from the final executable and not for any shared libraries, but > it seems I didn't implemented this correctly. How would you mean to implement it? -fopenmp or -fopenacc code with offloading bits might not be in the final executable at all, nor in shared libraries it is linked against; such libraries could be only dlopened, consider say python plugin. And this is not just made up, perhaps not with offloading yet, but people regularly use OpenMP code in plugins and then we get complains that fork child of the main program is not allowed to do anything but async-signal-safe functions. > > > You can dlopen such libraries etc. What if you link one library with > > -fopenmp=nvptx-none and another one with -fopenmp=x86_64-intelmicemul-linux? > > So, the first question to answer is: what do we expect to happen in this > case, or similarly, if the executable and any shared libraries are > compiled with different/incompatible -foffload options? As the device numbers are per-process, the only possibility I see is that all the physically available devices are always available, and just if you try to offload from some code to a device that doesn't support it, you get host fallback. Because, one shared library could carefully use device(xyz) to offload to say XeonPhi it is compiled for and supports, and another library device(abc) to offload to PTX it is compiled for and supports. > For this, I propose that the only mode of operation that we currently can > support is that all of the executable and any shared libraries agree on > the offload targets specified by -foffload, and I thus propose the > following patch on top of what Joseph has posted before (passes the > testsuite, but not yet tested otherwise): See above, no. Jakub