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.
>> > >I couldn't think of a better solution...
>> > >Tested using the testcase from the previous mail, e.g.:
>> > >
>> > >$ gcc -DNUM=1 -c -fopenmp test.c -o obj1.o
>> > >$ gcc -DNUM=2 -c -fopenmp test.c -o obj2.o
>> > >$ gcc -DNUM=3 -c -fopenmp test.c -o obj3.o
>> > >$ gcc -DNUM=4 -c -fopenmp test.c -o obj4.o -flto
>> > >$ gcc -DNUM=5 -c -fopenmp test.c -o obj5.o
>> > >$ gcc -DNUM=6 -c -fopenmp test.c -o obj6.o -flto
>> > >$ gcc -DNUM=7 -c -fopenmp test.c -o obj7.o
>> > >$ gcc-ar -cvq libtest.a obj3.o obj4.o obj5.o
>> > >$ gcc -fopenmp main.c obj1.o obj2.o libtest.a obj6.o obj7.o
>> > >
>> > >And other combinations.
>
>>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.
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?
Thanks,
- Tom
