From patchwork Mon Aug 24 17:54:40 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Joseph Myers X-Patchwork-Id: 510208 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id A812F140280 for ; Tue, 25 Aug 2015 03:54:55 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=DkP4AQJ5; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type; q=dns; s=default; b=nMT4Z7vu3pUqj6+Z g0hncvmzVTZWExG6sGOdpGgGCNy+jR1idr0iLL/VwEYYIMlbPbGmd8k6vPCLYNCt 0MLPPb2Jl40T6ZATDolVRJh5yEf29VxVSBzkfh/EmG09GsWZ2i5HDM+TWo0Rrttz zwuSlTdsJ0J7PMGGEk+X9fUhsjQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type; s=default; bh=/KYOCHHMUmV2bV91Gh5BrX d+o2s=; b=DkP4AQJ5pG52GSyESj+X0w6U0nHqiqm1VD/kPlZ4VFlLQzkmFAvVU8 CcWSLT6Dk35CiB58beXjVNQHUgnY9hBAZZ5SZ6FWd8oU6e4VlHtiO84eH8hlpXAJ hgNaLbD+I3Xmeb0SXSWcxUslGHy5/XlsuZS9sRf0S/62Vrtgj1F6s= Received: (qmail 110954 invoked by alias); 24 Aug 2015 17:54:49 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 110941 invoked by uid 89); 24 Aug 2015 17:54:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 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; Mon, 24 Aug 2015 17:54:46 +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 1ZTvxD-00074y-6O from joseph_myers@mentor.com ; Mon, 24 Aug 2015 10:54:43 -0700 Received: from digraph.polyomino.org.uk (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; Mon, 24 Aug 2015 18:54:41 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.82) (envelope-from ) id 1ZTvxA-0003vA-G2; Mon, 24 Aug 2015 17:54:40 +0000 Date: Mon, 24 Aug 2015 17:54:40 +0000 From: Joseph Myers To: Nathan Sidwell CC: Thomas Schwinge , GCC Patches Subject: Re: Forwarding -foffload=[...] from the driver (compile-time) to libgomp (run-time) In-Reply-To: Message-ID: References: <20141020111935.GA9362@msticlxl57.ims.intel.com> <20141024141601.GA62562@msticlxl57.ims.intel.com> <20141024142028.GD10376@tucnak.redhat.com> <20141028193047.GA17865@msticlxl57.ims.intel.com> <20141103092447.GO5026@tucnak.redhat.com> <20141105124655.GA42356@msticlxl57.ims.intel.com> <87egjopgh0.fsf@kepler.schwinge.homeip.net> <20150731142007.GA64740@msticlxl57.ims.intel.com> <20150805150904.GA3211@msticlxl57.ims.intel.com> <87bneatd5q.fsf@schwinge.name> <87lhddsfs4.fsf@schwinge.name> <87oai4r2ok.fsf@schwinge.name> <55D74C69.6040005@acm.org> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 On Fri, 21 Aug 2015, Joseph Myers wrote: > On Fri, 21 Aug 2015, Nathan Sidwell wrote: > > > this appears to cause an ICE in add_omp_infile_spec_func at; > > gcc_assert (offload_targets != NULL); > > > > when you use something like -foffload='-save-temps -v -fdump-rtl-all > > -fdump-tree-all -fno-verbose-asm' > > > > Is that use ill-formed? > > I'll need to reverse-engineer the question of what's a well-formed > -foffload= option (bug 67300 filed yesterday for the lack of any > documentation of that option). Although there is no documentation for the -foffload options in the manual, I found something at that I hope is current. It turns out the problem wasn't in the assertion, but in how a default -foffload option was generated. Generating it via specs meant that if the only -foffload option specified options without specifying a target (i.e., options applicable to all the configured offload targets), then the offload_targets variable was never set and so the assertion failure resulted (as well as OFFLOAD_TARGET_NAMES not being exported). Rather than trying to make the specs produce something if no -foffload=* options other than -foffload=-* options were passed, I'm testing this patch to default the offload targets after the original command line is processed (and before extra options from these specs are processed, so before the assertion is executed), and will commit it if tests are OK. 2015-08-24 Joseph Myers * gcc.c (driver_self_specs) [ENABLE_OFFLOADING]: Don't generate a -foffload option. (process_command): Call handle_foffload_option (OFFLOAD_TARGETS) if no offload target specified. Index: gcc/gcc.c =================================================================== --- gcc/gcc.c (revision 227045) +++ gcc/gcc.c (working copy) @@ -1064,9 +1064,6 @@ static const char *const multilib_defaults_raw[] = static const char *const driver_self_specs[] = { "%{fdump-final-insns:-fdump-final-insns=.} %