From patchwork Fri Feb 19 19:41:58 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Thomas Schwinge X-Patchwork-Id: 585394 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 95E4914056B for ; Sat, 20 Feb 2016 06:42:27 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=ddiQZlqc; 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:from :to:cc:subject:in-reply-to:references:date:message-id :mime-version:content-type; q=dns; s=default; b=FzBF60hi/5AB28lv 28UMWSgTN8l3XgtTKo4ucbuqOgiD8bq0lP8F/ZFaz/188wza04CQmLS/M1U0aP19 fL7aLZG8W0YRwZGmPIjhvV60Qg4o3U5PYppr+Iq5mLVEAg4x3weoBB2c1I0/vgbl 1nPxz7Fe+af+ZVLODzYkPOwvdDg= 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:from :to:cc:subject:in-reply-to:references:date:message-id :mime-version:content-type; s=default; bh=3sroKLG2yIjQ2sNmgrj6OV cxCl0=; b=ddiQZlqcQHRHoU1y/GEzpgcE46YFV+Y7W4G+wAfx6XOCjzfqAzS79d 2A29P0Iy2G/lrAPCRdgek0c5kgOpreeVQuIEoWOykxqjzYMLoEKL6oRvYeQIuyoA ZGK/bwhPG1pkYM+P2aQTbeH82MZh1iFugYWRVx27BIvmckN0tohnY= Received: (qmail 9929 invoked by alias); 19 Feb 2016 19:42:19 -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 9111 invoked by uid 89); 19 Feb 2016 19:42:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy=*src, *dest, identifies, 0x 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; Fri, 19 Feb 2016 19:42:17 +0000 Received: from svr-orw-fem-04.mgc.mentorg.com ([147.34.97.41]) by relay1.mentorg.com with esmtp id 1aWqwN-0007RV-K0 from Thomas_Schwinge@mentor.com ; Fri, 19 Feb 2016 11:42:11 -0800 Received: from tftp-cs (147.34.91.1) by svr-orw-fem-04.mgc.mentorg.com (147.34.97.41) with Microsoft SMTP Server id 14.3.224.2; Fri, 19 Feb 2016 11:42:11 -0800 Received: by tftp-cs (Postfix, from userid 49978) id C981BC230B; Fri, 19 Feb 2016 11:42:10 -0800 (PST) From: Thomas Schwinge To: Ilya Verbin , Jakub Jelinek CC: Bernd Schmidt , Kirill Yukhin , Andrey Turetskiy , Jan Hubicka , Richard Biener , , Cesar Philippidis Subject: Re: [PATCH 4/n] OpenMP 4.0 offloading infrastructure: lto-wrapper In-Reply-To: <20141002151457.GA59899@msticlxl57.ims.intel.com> References: <20141002151457.GA59899@msticlxl57.ims.intel.com> User-Agent: Notmuch/0.9-125-g4686d11 (http://notmuchmail.org) Emacs/24.5.1 (i586-pc-linux-gnu) Date: Fri, 19 Feb 2016 20:41:58 +0100 Message-ID: <87k2m0zdvd.fsf@kepler.schwinge.homeip.net> MIME-Version: 1.0 Hi! On Thu, 2 Oct 2014 19:14:57 +0400, Ilya Verbin wrote: > With this patch lto-wrapper performs invocation of mkoffload tool for each > offload target. This tool [...] > will compile IR from .gnu.offload_lto_* sections into offload > target code and embed the resultant code (offload image) into the new host's > object file. Consider the following scenario: $ cat < CSTS-214-acc.c int acc (void) { int a; #pragma acc parallel num_gangs (1) copyout (a) a = 100; return a; } $ cat < CSTS-214-test.c extern int acc (void); int main (void) { if (acc () != 100) __builtin_abort (); return 0; } Compile these two files as follows: $ [GCC] -fopenacc -c CSTS-214-acc.c $ x86_64-linux-gnu-ar -cr CSTS-214-acc.a CSTS-214-acc.o $ [GCC] -fopenacc CSTS-214-test.c CSTS-214-acc.a The last step will fail -- with incomprehensible diagnostics, ;-) as so often when offloading fails... Here's what's going on: the LTO/offloading machinery correctly identifies that it needs to process the CSTS-214-acc.c:acc function, present in the CSTS-214-acc.a archive file at a certain offset, and it "encodes" that as follows: CSTS-214-acc.a@0x9e (see lto-plugin/lto-plugin.c:claim_file_handler, the "file->offset != 0" code right at the beginning). This makes its way down through here: > --- a/gcc/lto-wrapper.c > +++ b/gcc/lto-wrapper.c > +/* Copy a file from SRC to DEST. */ > + > +static void > +copy_file (const char *dest, const char *src) > +{ > + [...] > +} > @@ -624,6 +852,54 @@ run_gcc (unsigned argc, char *argv[]) > + /* If object files contain offload sections, but do not contain LTO sections, > + then there is no need to perform a link-time recompilation, i.e. > + lto-wrapper is used only for a compilation of offload images. */ > + if (have_offload && !have_lto) > + { > + for (i = 1; i < argc; ++i) > + if ([...]) > + { > + char *out_file; > + /* Can be ".o" or ".so". */ > + char *ext = strrchr (argv[i], '.'); > + if (ext == NULL) > + out_file = make_temp_file (""); > + else > + out_file = make_temp_file (ext); > + /* The linker will delete the files we give it, so make copies. */ > + copy_file (out_file, argv[i]); > + printf ("%s\n", out_file); > + } > +[...] > + goto finish; > + } > + > if (lto_mode == LTO_MODE_LTO) > { > flto_out = make_temp_file (".lto.o"); > @@ -850,6 +1126,10 @@ cont: > obstack_free (&env_obstack, NULL); > } > > + finish: > + if (offloadend) > + printf ("%s\n", offloadend); > + > obstack_free (&argv_obstack, NULL); > } When we hit this, for argv "CSTS-214-acc.a@0x9e", the copy_file call will fail -- there is no "CSTS-214-acc.a@0x9e" file to copy. If we strip off the "@0x[...]" suffix (but still printf the filename including the suffix), then things work. I copied that bit of code from earlier in this function, where the same archive offset handling needs to be done. Probably that code should be refactored a bit. Also, I wonder if the "ext == NULL" case can really happen, and needs to be handled as done in the code cited above, or if that can be simplified? (Not yet tested that.) Will something like the following be OK to fix this issue, or is that something "that should not happen", should be fixed differently? Grüße Thomas --- gcc/lto-wrapper.c +++ gcc/lto-wrapper.c @@ -1161,15 +1161,31 @@ run_gcc (unsigned argc, char *argv[]) && strncmp (argv[i], "-flinker-output=", sizeof ("-flinker-output=") - 1) != 0) { + char *p; + off_t file_offset = 0; + long loffset; + int consumed; + char *filename = argv[i]; + + if ((p = strrchr (argv[i], '@')) + && p != argv[i] + && sscanf (p, "@%li%n", &loffset, &consumed) >= 1 + && strlen (p) == (unsigned int) consumed) + { + filename = XNEWVEC (char, p - argv[i] + 1); + memcpy (filename, argv[i], p - argv[i]); + filename[p - argv[i]] = '\0'; + file_offset = (off_t) loffset; + } + char *out_file; - /* Can be ".o" or ".so". */ - char *ext = strrchr (argv[i], '.'); + char *ext = strrchr (filename, '.'); if (ext == NULL) out_file = make_temp_file (""); else out_file = make_temp_file (ext); /* The linker will delete the files we give it, so make copies. */ - copy_file (out_file, argv[i]); + copy_file (out_file, filename); printf ("%s\n", out_file); } goto finish;