On Wed, Feb 24, 2016 at 17:13:35 +0100, Thomas Schwinge wrote: > On Tue, 23 Feb 2016 08:37:07 +0100, Tom de Vries <tom_devr...@mentor.com> > wrote: > > On 22/02/16 19:07, Ilya Verbin wrote: > > > 2016-02-22 18:13 GMT+03:00 Thomas Schwinge<tho...@codesourcery.com>: > > >> >On Sat, 20 Feb 2016 13:54:20 +0300, Ilya Verbin<iver...@gmail.com> > > >> >wrote: > > >>> >>On Fri, Feb 19, 2016 at 15:53:08 +0100, Jakub Jelinek wrote: > > >>>> >> >On Wed, Feb 10, 2016 at 08:19:34PM +0300, Ilya Verbin wrote: > > >>>>> >> > >This patch adds crtoffload{begin,end}.o to all -fopenmp > > >>>>> >> > >programs, if they exist. > > > >>> >>Thomas, could you please test it using nvptx > > >> > > > >> >It mostly;-) works. With nvptx offloading enabled (which you don't > > >> >have, do you?), I'm seeing one test case regress: > > >> > > > >> > [-PASS:-]{+FAIL:+} > > >> > libgomp.oacc-c/../libgomp.oacc-c-c++-common/parallel-dims-2.c > > >> > -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 (test for errors, line > > >> > 9) > > >> > [-PASS:-]{+FAIL:+} > > >> > libgomp.oacc-c/../libgomp.oacc-c-c++-common/parallel-dims-2.c > > >> > -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 (test for errors, line > > >> > 13) > > >> > PASS: > > >> > libgomp.oacc-c/../libgomp.oacc-c-c++-common/parallel-dims-2.c > > >> > -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 (test for excess errors) > > >> > [-PASS:-]{+FAIL:+} > > >> > libgomp.oacc-c/../libgomp.oacc-c-c++-common/parallel-dims-2.c > > >> > -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 execution test > > >> > > > >> >(Same for C++.) That testcase, just recently added by Tom in r233237 > > >> >"Handle -fdiagnostics-color in lto", specifies 'dg-additional-options > > >> >"-flto -fno-use-linker-plugin"'. Is that now an unsupported > > >> >combination/configuration? (I have not yet looked in detail, but it > > >> >appears as if the offloading compilers are no longer being run for > > >> >-fno-use-linker-plugin.) > > > Yes, it's really hard to fix the "lto + non-lto objects" issue for > > > no-use-linker-plugin LTO path. In this patch lto-plugin prepares a > > > list of objects files with offloading and passes it to lto-wrapper, so > > > I believe we should consider offloading without lto-plugin as > > > unsupported. I'll update wiki when the patch will be committed. > > Aha, I see. I guess there's no point in keeping offloading supported for > the -fno-lto (default) with -fno-use-linker-plugin configuration? > > Ilya, then please remove > libgomp/testsuite/libgomp.oacc-c-c++-common/parallel-dims-2.c as part of > your patch, unless Tom thinks it should be changed to a -flto test, but > without -fno-use-linker-plugin?
OK. > > Shouldn't we error (or at least warn) then if we compile a file > > containing an offload construct with fopenacc/fopenmp and > > -fno-use-linker-plugin? > > Yes, that makes sense to me, too. (Note that, as I understand it, > -fno-use-linker-plugin may also be the default for certain GCC > configurations...) Aside from spec stuff in gcc/gcc.c relating to > LINK_PLUGIN_SPEC, I see there's some code in > gcc/gcc.c:driver::maybe_run_linker evaluating the three possible values > of HAVE_LTO_PLUGIN, but I have not yet thought about how and where to > conditionalize the diagnostic if attempting to do offloading in an > unsupported (-fno-use-linker-plugin) configuration. To print this error someone has to detect that at least one object contains offload sections, only linker plugin and lto-wrapper can do it. But if linker plugin is absent, the lto-wrapper have to open all objects, scan for all sections, etc. Looks like too much overhead for a single diagnostic. -- Ilya