From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24500 invoked by alias); 20 Dec 2013 16:47:02 -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 24487 invoked by uid 89); 20 Dec 2013 16:46:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pa0-f44.google.com Received: from mail-pa0-f44.google.com (HELO mail-pa0-f44.google.com) (209.85.220.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 20 Dec 2013 16:46:58 +0000 Received: by mail-pa0-f44.google.com with SMTP id fa1so2855445pad.17 for ; Fri, 20 Dec 2013 08:46:56 -0800 (PST) X-Received: by 10.68.190.228 with SMTP id gt4mr9904376pbc.94.1387558016283; Fri, 20 Dec 2013 08:46:56 -0800 (PST) Received: from msticlxl57.ims.intel.com (fmdmzpr04-ext.fm.intel.com. [192.55.55.39]) by mx.google.com with ESMTPSA id xs1sm20154666pac.7.2013.12.20.08.46.51 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 20 Dec 2013 08:46:55 -0800 (PST) Date: Fri, 20 Dec 2013 16:47:00 -0000 From: "Michael V. Zolotukhin" To: Bernd Schmidt Cc: Jakub Jelinek , Thomas Schwinge , Richard Biener , Kirill Yukhin , Ilya Verbin , Andrey Turetskiy , Ilya Tocar , gcc Subject: Re: [RFC][gomp4] Offloading patches (3/3): Add invocation of target compiler Message-ID: <20131220164647.GC39975@msticlxl57.ims.intel.com> References: <20131217114251.GB39975@msticlxl57.ims.intel.com> <52B46228.7070900@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52B46228.7070900@codesourcery.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2013-12/txt/msg01773.txt.bz2 > This patch seems to make rather too many assumptions about host and > target compilers. Certainly code like this can't go into > target-independent code like lto-wrapper. That's true. The point of this patch was to show what is needed to support x86->MIC OpenMP offloading, as we currently see it. We are ready to extend existing code making it more versatile, but keeping this needed functionality. > Also, I'm not sure you can > assume you'll get ELF files out of the OpenACC target compiler; I'd very > prefer a solution that doesn't rely on objcopy. Yep, that's an issue I suspected but wasn't sure of. The idea was to prepare an image in the following steps: 1. Compile with target compiler. 2. Post-process it (in our case, call objcopy and perform partial linking). 3. Pass it to the host linker as a usual object file with the image and its size placed in the known symbols with defined names (e.g. _omp__image). I would like to keep step 3 unchanged, while the steps 1 and 2 could be easily combined into a single one. In that case we could say that output of a target compiler should be an object file for host linker with several symbols defined: _omp__image, _omp__size, etc. For x86->MIC one would use gcc+objcopy for this, and for OpenACC offloading one could use gcc+some of other target-specific utils (if any of them needed). Will this scheme work for OpenACC? Michael > Bernd