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
