From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 113802 invoked by alias); 6 Jan 2020 15:25:35 -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 110052 invoked by uid 89); 6 Jan 2020 15:25:30 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.1 spammy=conclusion, conference, excessive, our X-HELO: esa3.hgst.iphmx.com Received: from esa3.hgst.iphmx.com (HELO esa3.hgst.iphmx.com) (216.71.153.141) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 06 Jan 2020 15:25:28 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=wdc.com; i=@wdc.com; q=dns/txt; s=dkim.wdc.com; t=1578324329; x=1609860329; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=WBbkI/Mynba7obt43Jr3yYgJKZizTA3W8WROQpI450s=; b=NLFQmBaAt6KvNzvr97gfy+ZWnTIqVhJUI7jf47A/xONiG0TXVK5Kr2/q 3X2xSByNmB+L2fCiZR4WRIaO2gFGkVSNoXp7GrbkoFa/em/xoBzk4bzAI 6J3UswSpnXGWm1P6BfqnE6/YobSk2q/T7+YmWPsykutSmX/ulIEEhVQYi fdmBrB2Hg+FLRHkZPpEtsS2dEymlN37w9SVzeceGncFT420Kw/q0QgU8/ QB2SPsuGfhdmElwZ0Pb8zkVsD0ann3KdQVNh6DlPMO69f1spyEGxQ4DAW Ww+U9Lqa/YVE66vx256FcwPlL/L45GM0AFRvrSuK4Mouh46vRqC0dKS/6 g==; IronPort-SDR: ehoZ27YfRLtAlC4pG3CgEz9743gQgSH9p598kAnCSopdrTbGtNm+AaZFL0VRH+VnqKnZlRWAui n8pRHvzZaotS3/gBVdW9EYdFNTZmS1Y/6XzLUNkDWsJYsOeNWcnkCUyYlYAUa8wyHn0Qv4t+NE DSPHLxeVJyH2GHRIwhS5fhN3P8FE0hLcyc2onj4u6r4oUbNjTclEZ3iquMXPW0gVr2m8hySjwO zFszoFOfmatSqPnUo8CFXUmDMDM14aHfWWsd6RPeNb06z6X69gavQw5GRObZ6GzNjp9NMAP3xs mFw= Received: from h199-255-45-14.hgst.com (HELO uls-op-cesaep01.wdc.com) ([199.255.45.14]) by ob1.hgst.iphmx.com with ESMTP; 06 Jan 2020 23:25:27 +0800 IronPort-SDR: wlsn8AZfAxvFKrVRpcCvTYQ0YeV/4imTZU+GTDL7BqO4NUccVwk+WPZ88DA0qMtQWOW09/l/Xb czi1b64yI/9bW3XtHWlBWLCpZ8esm2CWSvog1N5+z5ljOqVanPqUnVlqTU4w6rAxR1Ie7F7d5W fbi0UsuILgb7GNUCDX+Oc8ga2XTKBJNW5Z/23nPI50mHaUdqIUX4PRVNoon9GOPGmSGBYejrXq CX2AUZvQmrJ39HSzTaoadyX4TWptI/q6c1sZ3mRj7M7Rx6cV7IQIgqtlAB6NGuy8aPiSxWQS0K 8aHwq2JoY7YfLdPDsOxQo1Jg Received: from uls-op-cesaip01.wdc.com ([10.248.3.36]) by uls-op-cesaep01.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jan 2020 07:19:18 -0800 IronPort-SDR: m6O8RxqTPg9+qs5VwvZJ13OgHZXTz10B1xbKkNjRqvrXgl/5eKZGs0eI9jwefLgljP03iXiaql jnLzhdFwurs5AWmOwKCz+dLg1bXzobmX0aKelaLA/zvT/SOd5shUm94QtYV06nZL4oAIkMbew3 bqUFwfuQ7uy9/aabFypHm+CIcp6H4n/5Brd0v9CDebvLr4CfI93ub5sC9iA96t57cYuT1l5IP5 hYHylLpnLCsBuMClePsttyPzgri5rPdDgwWm550OPhP+/OHz056Wnu/dpifszrYNvYLqaa4K/2 lcI= WDCIronportException: Internal Received: from unknown (HELO redsun52) ([10.149.66.28]) by uls-op-cesaip01.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jan 2020 07:25:26 -0800 Date: Mon, 06 Jan 2020 15:25:00 -0000 From: "Maciej W. Rozycki" To: Julian Brown cc: Mike Stump , gcc-patches@gcc.gnu.org, Thomas Schwinge Subject: Re: [PING^4][PATCH 0/4] Fix library testsuite compilation for build sysroot In-Reply-To: <20200103113421.51b55ff5@squid.athome> Message-ID: References: <6594B30D-743B-4B4C-81CE-11DD3EE87C8C@comcast.net> <20200103113421.51b55ff5@squid.athome> User-Agent: Alpine 2.21 (LFD 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-SW-Source: 2020-01/txt/msg00130.txt.bz2 Hi Julian, > FYI: This patch seems to be causing problems for our (internal -- as > you know!) test harness. I'm not sure if it's a local issue (or at least > something we can work around here), or a problem with the patch itself > though. I'm sorry to break your setup. I'm currently a little bit busy before a conference next week I speak at, however I'll try to address your problem the best I can regardless. > I'm currently working on offloading-enabled compilers. I see the same > failure mode for both AMD GCN and NVPTX. > > Without the patch, the compiler is found (with [find_gcc] I suppose) and > invoked as x86_64-none-linux-gnu-gcc. That works fine for us, but we do > (I think) "installed testing", which IIUC is atypical. I'm not sure if the libgomp-test-support.exp file produced by the build is supposed to be used in standalone testing rather than one that has been separately prepared for the standalone environment in question. However before I make any definite conclusion I would like to understand how things are supposed to work with an offload-enabled compiler. > With the patch, the compiler is invoked as (at the risk of excessive > detail) e.g.: > > /scratch/jbrown/nvptx-mainline/obj/gcc-2018.11-999999-x86_64-none-linux-gnu-x86_64-linux-gnu/./gcc/xgcc -B/scratch/jbrown/nvptx-mainline/obj/gcc-2018.11-999999-x86_64-none-linux-gnu-x86_64-linux-gnu/./gcc/ -B/scratch/jbrown/nvptx-mainline/install/opt/codesourcery/x86_64-none-linux-gnu/bin/ -B/scratch/jbrown/nvptx-mainline/install/opt/codesourcery/x86_64-none-linux-gnu/lib/ -isystem /scratch/jbrown/nvptx-mainline/install/opt/codesourcery/x86_64-none-linux-gnu/include -isystem /scratch/jbrown/nvptx-mainline/install/opt/codesourcery/x86_64-none-linux-gnu/sys-include --sysroot=/scratch/jbrown/nvptx-mainline/install/opt/codesourcery/x86_64-none-linux-gnu/libc [...] > > ...and then it fails to find libgomp.spec: > > xgcc: fatal error: cannot read spec file 'libgomp.spec': No such file or directory > > Can your approach be made to work with an offload-enabled compiler? How > should that spec file (and/or the target compiler) be located? As I recall there is a separate compiler invoked for the offload target. I don't have a suitable setup available to hand nor an easy way to make one. Can you therefore please figure out and tell me how this is arranged? Also where does the libgomp.spec file come from? Overall if libgomp-test-support.exp is considered appropriate for standalone testing, then I think two solutions are possible here: 1. An option is added to libgomp's $CC such that the compiler is able to make builds involving the offload compiler where requested, and this then propagates to GCC_UNDER_TEST as it stands. 2. The definition of GCC_UNDER_TEST in libgomp-test-support.exp is only made if inexistent, and then you can predefine the variable in site.exp however you find appropriate. Maciej