Hi Maciej, On Sun, 22 Dec 2019 00:43:54 +0000 (GMT) "Maciej W. Rozycki" <ma...@wdc.com> wrote:
> On Fri, 20 Dec 2019, Mike Stump wrote: > > > >> This patch series addresses a problem with the testsuite > > >> compiler being set up across libatomic, libffi, libgo, libgomp > > >> with no correlation whatsoever to the target compiler being used > > >> in GCC compilation. Consequently there in no arrangement made to > > >> set up the compilation sysroot according to the build sysroot > > >> specified for GCC compilation, causing a catastrophic failure > > >> across the testsuites affected from the inability to link > > >> executables. > > > > > > Ping for: > > > > > > <https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00767.html> > > > <https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00768.html> > > > <https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00770.html> > > > > Hum... I'm wondering who should review this... Feels like I > > should, the problem is it intertwines with the build system as > > well. So, let me approve the testsuite parts so that can clear the > > way for someone else to approve the remaining bits (if not > > obvious). > > Thanks for your review; I have applied 4/4 as it doesn't contain any > non-testsuite parts and will continue pinging 1/4 and 2/4 for the > build system bits then (3/4 has been already committed by the Go > maintainer). > > > Please do watch out for breakages as it goes in. Thanks. > > Sure! 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 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. 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? Thanks, Julian
