From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 99581 invoked by alias); 20 Oct 2015 12:13:16 -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 99568 invoked by uid 89); 20 Oct 2015 12:13:16 -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,RP_MATCHES_RCVD,SPF_HELO_PASS 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, 20 Oct 2015 12:13:15 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id BC8698C1D5; Tue, 20 Oct 2015 12:13:13 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-53.ams2.redhat.com [10.36.116.53]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t9KCDBWo022727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 20 Oct 2015 08:13:13 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id t9KCDADE024446; Tue, 20 Oct 2015 14:13:10 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id t9KCD8vA024445; Tue, 20 Oct 2015 14:13:08 +0200 Date: Tue, 20 Oct 2015 12:13:00 -0000 From: Jakub Jelinek To: Bernd Schmidt Cc: Thomas Schwinge , gcc-patches@gcc.gnu.org, Nathan Sidwell , Joseph Myers Subject: Re: Forwarding -foffload=[...] from the driver (compile-time) to libgomp (run-time) Message-ID: <20151020121308.GC478@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <87egjopgh0.fsf@kepler.schwinge.homeip.net> <20150911154349.GH1847@tucnak.redhat.com> <87a8s6vq69.fsf@kepler.schwinge.homeip.net> <20150929081814.GD1847@tucnak.redhat.com> <5624F236.9020308@mentor.com> <87lhbnsy1s.fsf@kepler.schwinge.homeip.net> <87mvve95af.fsf@schwinge.name> <20151020100245.GW478@tucnak.redhat.com> <87bnbt94bq.fsf@schwinge.name> <56262961.90101@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56262961.90101@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg01869.txt.bz2 On Tue, Oct 20, 2015 at 01:45:37PM +0200, Bernd Schmidt wrote: > Both of you can ignore me if you feel I'm not making sense, but what exactly > is the use case for -foffload=disable? Isn't it slightly redundant with > -fno-openacc? IMO it's not an option that alters the available devices, > that's a question that is answered at run-time and doesn't (or shouldn't) > really depend on compiler switches. As a user I'd expect -foffload=disable > to just prevent generation of offloaded code for the things I'm compiling. > As Jakub pointed out, shared libraries may still contain other pieces that > are offloadable. > > I guess I don't fully understand why you want to go to great lengths to > disable devices at run-time based on a compile-time switch. What's the > reasoning here? At least for OpenMP, I'm also happy with what we do now (except for the ability to configure offloading targets as optional, i.e. dynamically configure the default based on what packages user install rather than just on how it has been configured, so that e.g. just because it has been configured for PTX offloading the host GCC itself doesn't have to have a dependency on the proprietary CUDA stuff in any way). I believe in OpenMP nobody says that if the device HW is available, but user chose to not compile offloading code/variables for that particular device that it can't show up among omp_get_num_devices (). And I think it is entirely fine if say target data map succeeds to that device, but then target is offloaded, if that is caused by users configure or command line choice. Maybe OpenACC has different requirements, is it required to terminate the program if it can't fulfill the requested offloading? In any case, I'm fine with something I've noted in the last mail, or with the status quo, but not with running constructors in TUs or even shared libraries just because they have been compiled with -fopenmp (and either haven't used any OpenMP code at all, or just the non-*target* directives). Jakub