RE: [Patch][gcn, nvptx, offloading] mkoffload – handle -fpic/-fPIC
>-Original Message-
>From: Gcc-patches [mailto:gcc-patches-boun...@gcc.gnu.org] On Behalf
>Of Tom de Vries
>Sent: Friday, July 3, 2020 6:52 AM
>To: Moore, Catherine ; Burnus, Tobias
>; gcc-patches ;
>Jakub Jelinek
>Cc: Schwinge, Thomas ; Stubbs,
>Andrew
>Subject: Re: [Patch][gcn, nvptx, offloading] mkoffload – handle -fpic/-fPIC
>
>On 6/26/20 9:35 PM, Moore, Catherine wrote:
>> Hi Tom,
>>
>> It doesn't look like you were explicitly cc'd on this patch and probably
>haven't seen it. Would you mind taking a look and approving the nvptx
>portions?
>>
>
>[ thanks for the ping, I think was explicitly cc-ed though. I'm usually
>not too fast in reviewing, and this time a vacation added to that. ]
>
>The patch looks good to me.
Thanks for the review.
Catherine
>
>I tried out the patch with one test-case and -pie -fPIC/-fpic already
>seems to works, so perhaps we could have at least one test-case
>exercising this in libgomp? That sounds easier to do than the
>shared-lib test-case.
>
>I think it's a good idea though to do fPIE/fpie as well, either in this
>patch or as follow-up.
>
>Thanks,
>- Tom
>
>> Thanks,
>> Catherine
>>
>>> -Original Message-
>>> From: Gcc-patches [mailto:gcc-patches-boun...@gcc.gnu.org] On
>Behalf
>>> Of Burnus, Tobias
>>> Sent: Tuesday, June 23, 2020 11:21 AM
>>> To: gcc-patches ; Jakub Jelinek
>>>
>>> Cc: Stubbs, Andrew ; Schwinge,
>Thomas
>>>
>>> Subject: [Patch][gcn, nvptx, offloading] mkoffload – handle -fpic/-fPIC
>>>
>>> If the offloading code is (only) in a library, one can come up
>>> with the idea to build those parts as shared library – and link
>>> it to the nonoffloading code.(*)
>>>
>>> Currently, this fails as the mkoffload calls the nonoffloading
>>> compiler without the -fpic/-fPIC flags, even though the compiler
>>> was originally invoked with those options. – And at some point,
>>> the linker then complains.
>>>
>>> This patch simply adds -fpic/-fPIC to the calls to the nonoffloading
>>> ("host") compiler, invoked from mkoffload, if they were present before.
>>>
>>> For the testcase at hand, this works with both AMDGCN and nvptx
>>> with the attached patch.
>>>
>>> OK for the trunk?
>>>
>>> Tobias
>>>
>>> PS: I think as mid-/longterm project it would be nice to test this
>>> in the testsuite, but that's unfortunately a larger task.
>>>
>>> (*) Thomas mentioned that this is supposed to work also in more
>>> complex cases than the one I outlined, although, that is probably
>>> currently the most common one.
>>>
>>> -
>>> Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634
>München /
>>> Germany
>>> Registergericht München HRB 106955, Geschäftsführer: Thomas
>Heurung,
>>> Alexander Walter
Re: [Patch][gcn, nvptx, offloading] mkoffload – handle -fpic/-fPIC
Hi Kwok!
On 2020-07-08T18:35:43+0100, Kwok Cheung Yeung wrote:
> > I tried out the patch with one test-case and -pie -fPIC/-fpic already
> > seems to works, so perhaps we could have at least one test-case
> > exercising this in libgomp? That sounds easier to do than the
> > shared-lib test-case.
>
> I've created a simple testcase which tries to generate a shared library with
> offloaded code.
Thanks.
> Without the mkoffload patch, it fails during linking with:
>
> ld: /tmp/ccNaT7fO.target.o: relocation R_X86_64_32 against `.rodata' can not
> be
> used when making a shared object; recompile with -fPIC
>
> I have tested this on a x64 host with offloading to nvptx and gcn.
Confirmed, and also that it actually works; using the two files attached:
$ install/bin/gcc -Wall -Wextra -fopenacc -o libf.so shared-lib.c -shared
-fPIC
$ install/bin/gcc -Wall -Wextra -fopenacc shared-lib-main.c -Wl,-rpath,$PWD
-L$PWD -lf
..., and execute 'a.out' on a GCN and a nvptx GPU machine.
(As discussed before, it's non-trivial to get such a two-step compilation
process into the libgomp testsuite, so not doing that now.)
> On AMD GCN,
> it also produces a couple of extra linker warnings that I have added
> dg-warning
> entries for.
Isn't that unexpected to see such warnings? (Would you declare this
issue "done" if users then see such warnings?) That said, I'm not seeing
these, thus get:
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/shared-lib.c
-DACC_DEVICE_TYPE_radeon=1 -DACC_MEM_SHARED=0 -foffload=amdgcn-amdhsa -O0
(test for warnings, line )
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/shared-lib.c
-DACC_DEVICE_TYPE_radeon=1 -DACC_MEM_SHARED=0 -foffload=amdgcn-amdhsa -O0
(test for warnings, line )
> Okay for trunk/OG10 together with the previous mkoffload patch?
In principle yes, with the 'dg-warning' directives removed. Please
verify why you're seeing these warnings with GCN 'mkoffload'.
> commit 43238117c261285a6b95d881bcc2f9efd9f752ad
> Author: Kwok Cheung Yeung
> Date: Wed Jul 8 03:28:08 2020 -0700
>
> Add test case
Try to make 'git log --oneline' meaningful, so a bit more verbose,
please. Maybe: "Add test case 'libgomp.oacc-c-c++-common/shared-lib.c'"?
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/shared-lib.c
> @@ -0,0 +1,16 @@
Maybe add a header line comment, like: "Verify that we can compile
offloading code into a shared library".
> +/* { dg-do link } */
> +/* { dg-additional-options "-shared -fPIC" { target fpic } } */
Let's hope this does the expected thing for all offloading/libgomp
testing configurations. Not sure if (additionally?) we should
'dg-require-effective-target shared'? See 'g++.dg/tls/pr85400.C', for
example. (Jakub?)
> +
> +#define N 512
> +
> +void f(int a[])
> +{
> + int i;
> +
> + #pragma acc parallel
> + for (i = 0; i < N; i++)
> +a[i]++;
> +}
> +
> +/* { dg-warning "relocation against `.*' in read-only section `\.rodata'" ""
> { target openacc_radeon_accel_selected } 0 } */
> +/* { dg-warning "creating DT_TEXTREL in a shared object" "" { target
> openacc_radeon_accel_selected } 0 } */
Grüße
Thomas
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander
Walter
/* { dg-do link } */
/* { dg-additional-options "-shared -fPIC" { target fpic } } */
#define N 512
void f(int a[])
{
int i;
#pragma acc parallel loop copy(a[0:N])
for (i = 0; i < N; i++)
a[i] = -i;
}
#include
extern void f(int a[]);
#define N 512
int main()
{
int a[N] = { 0 };
f(a);
for (int i = 0; i < N; i++)
assert (a[i] == -i);
return 0;
}
Re: [Patch][gcn, nvptx, offloading] mkoffload – handle -fpic/-fPIC
On 7/8/20 7:35 PM, Kwok Cheung Yeung wrote:
> (Resent with CC to gcc-patches)
>
> Hello
>
>> I tried out the patch with one test-case and -pie -fPIC/-fpic already
>> seems to works, so perhaps we could have at least one test-case
>> exercising this in libgomp? That sounds easier to do than the
>> shared-lib test-case.
>
> I've created a simple testcase which tries to generate a shared library
> with offloaded code. Without the mkoffload patch, it fails during
> linking with:
>
> ld: /tmp/ccNaT7fO.target.o: relocation R_X86_64_32 against `.rodata' can
> not be used when making a shared object; recompile with -fPIC
>
> I have tested this on a x64 host with offloading to nvptx and gcn. On
> AMD GCN, it also produces a couple of extra linker warnings that I have
> added dg-warning entries for.
>
> Okay for trunk/OG10 together with the previous mkoffload patch?
>
Hi Kwok,
the test-case looks ok to me, but I can't approve it.
FWIW, the nvptx part of the previous mkoffload patch was already
approved, so AFAIU you could have committed that already.
Thanks,
- Tom
> Thanks
>
> Kwok
>
>
> mkoffload_test_case.patch
>
> commit 43238117c261285a6b95d881bcc2f9efd9f752ad
> Author: Kwok Cheung Yeung
> Date: Wed Jul 8 03:28:08 2020 -0700
>
> Add test case
>
> 2020-07-08 Kwok Cheung Yeung
>
> libgomp/
> * testsuite/libgomp.oacc-c-c++-common/shared-lib.c: New.
>
> diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/shared-lib.c
> b/libgomp/testsuite/libgomp.oacc-c-c++-common/shared-lib.c
> new file mode 100644
> index 000..6d8a4ac
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/shared-lib.c
> @@ -0,0 +1,16 @@
> +/* { dg-do link } */
> +/* { dg-additional-options "-shared -fPIC" { target fpic } } */
> +
> +#define N 512
> +
> +void f(int a[])
> +{
> + int i;
> +
> + #pragma acc parallel
> + for (i = 0; i < N; i++)
> +a[i]++;
> +}
> +
> +/* { dg-warning "relocation against `.*' in read-only section `\.rodata'" ""
> { target openacc_radeon_accel_selected } 0 } */
> +/* { dg-warning "creating DT_TEXTREL in a shared object" "" { target
> openacc_radeon_accel_selected } 0 } */
>
Re: [Patch][gcn, nvptx, offloading] mkoffload – handle -fpic/-fPIC
(Resent with CC to gcc-patches)
Hello
> I tried out the patch with one test-case and -pie -fPIC/-fpic already
> seems to works, so perhaps we could have at least one test-case
> exercising this in libgomp? That sounds easier to do than the
> shared-lib test-case.
I've created a simple testcase which tries to generate a shared library with
offloaded code. Without the mkoffload patch, it fails during linking with:
ld: /tmp/ccNaT7fO.target.o: relocation R_X86_64_32 against `.rodata' can not be
used when making a shared object; recompile with -fPIC
I have tested this on a x64 host with offloading to nvptx and gcn. On AMD GCN,
it also produces a couple of extra linker warnings that I have added dg-warning
entries for.
Okay for trunk/OG10 together with the previous mkoffload patch?
Thanks
Kwok
commit 43238117c261285a6b95d881bcc2f9efd9f752ad
Author: Kwok Cheung Yeung
Date: Wed Jul 8 03:28:08 2020 -0700
Add test case
2020-07-08 Kwok Cheung Yeung
libgomp/
* testsuite/libgomp.oacc-c-c++-common/shared-lib.c: New.
diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/shared-lib.c
b/libgomp/testsuite/libgomp.oacc-c-c++-common/shared-lib.c
new file mode 100644
index 000..6d8a4ac
--- /dev/null
+++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/shared-lib.c
@@ -0,0 +1,16 @@
+/* { dg-do link } */
+/* { dg-additional-options "-shared -fPIC" { target fpic } } */
+
+#define N 512
+
+void f(int a[])
+{
+ int i;
+
+ #pragma acc parallel
+ for (i = 0; i < N; i++)
+a[i]++;
+}
+
+/* { dg-warning "relocation against `.*' in read-only section `\.rodata'" "" {
target openacc_radeon_accel_selected } 0 } */
+/* { dg-warning "creating DT_TEXTREL in a shared object" "" { target
openacc_radeon_accel_selected } 0 } */
Re: [Patch][gcn, nvptx, offloading] mkoffload – handle -fpic/-fPIC
On 6/26/20 9:35 PM, Moore, Catherine wrote:
> Hi Tom,
>
> It doesn't look like you were explicitly cc'd on this patch and probably
> haven't seen it. Would you mind taking a look and approving the nvptx
> portions?
>
[ thanks for the ping, I think was explicitly cc-ed though. I'm usually
not too fast in reviewing, and this time a vacation added to that. ]
The patch looks good to me.
I tried out the patch with one test-case and -pie -fPIC/-fpic already
seems to works, so perhaps we could have at least one test-case
exercising this in libgomp? That sounds easier to do than the
shared-lib test-case.
I think it's a good idea though to do fPIE/fpie as well, either in this
patch or as follow-up.
Thanks,
- Tom
> Thanks,
> Catherine
>
>> -Original Message-
>> From: Gcc-patches [mailto:gcc-patches-boun...@gcc.gnu.org] On Behalf
>> Of Burnus, Tobias
>> Sent: Tuesday, June 23, 2020 11:21 AM
>> To: gcc-patches ; Jakub Jelinek
>>
>> Cc: Stubbs, Andrew ; Schwinge, Thomas
>>
>> Subject: [Patch][gcn, nvptx, offloading] mkoffload – handle -fpic/-fPIC
>>
>> If the offloading code is (only) in a library, one can come up
>> with the idea to build those parts as shared library – and link
>> it to the nonoffloading code.(*)
>>
>> Currently, this fails as the mkoffload calls the nonoffloading
>> compiler without the -fpic/-fPIC flags, even though the compiler
>> was originally invoked with those options. – And at some point,
>> the linker then complains.
>>
>> This patch simply adds -fpic/-fPIC to the calls to the nonoffloading
>> ("host") compiler, invoked from mkoffload, if they were present before.
>>
>> For the testcase at hand, this works with both AMDGCN and nvptx
>> with the attached patch.
>>
>> OK for the trunk?
>>
>> Tobias
>>
>> PS: I think as mid-/longterm project it would be nice to test this
>> in the testsuite, but that's unfortunately a larger task.
>>
>> (*) Thomas mentioned that this is supposed to work also in more
>> complex cases than the one I outlined, although, that is probably
>> currently the most common one.
>>
>> -
>> Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München /
>> Germany
>> Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung,
>> Alexander Walter
RE: [Patch][gcn, nvptx, offloading] mkoffload – handle -fpic/-fPIC
Hi Tom,
It doesn't look like you were explicitly cc'd on this patch and probably
haven't seen it. Would you mind taking a look and approving the nvptx portions?
Thanks,
Catherine
>-Original Message-
>From: Gcc-patches [mailto:gcc-patches-boun...@gcc.gnu.org] On Behalf
>Of Burnus, Tobias
>Sent: Tuesday, June 23, 2020 11:21 AM
>To: gcc-patches ; Jakub Jelinek
>
>Cc: Stubbs, Andrew ; Schwinge, Thomas
>
>Subject: [Patch][gcn, nvptx, offloading] mkoffload – handle -fpic/-fPIC
>
>If the offloading code is (only) in a library, one can come up
>with the idea to build those parts as shared library – and link
>it to the nonoffloading code.(*)
>
>Currently, this fails as the mkoffload calls the nonoffloading
>compiler without the -fpic/-fPIC flags, even though the compiler
>was originally invoked with those options. – And at some point,
>the linker then complains.
>
>This patch simply adds -fpic/-fPIC to the calls to the nonoffloading
>("host") compiler, invoked from mkoffload, if they were present before.
>
>For the testcase at hand, this works with both AMDGCN and nvptx
>with the attached patch.
>
>OK for the trunk?
>
>Tobias
>
>PS: I think as mid-/longterm project it would be nice to test this
>in the testsuite, but that's unfortunately a larger task.
>
>(*) Thomas mentioned that this is supposed to work also in more
>complex cases than the one I outlined, although, that is probably
>currently the most common one.
>
>-
>Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München /
>Germany
>Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung,
>Alexander Walter
Re: [Patch][gcn, nvptx, offloading] mkoffload – handle -fpic/-fPIC
Hi Tobias! On 2020-06-24T15:36:25+0200, Tobias Burnus wrote: > [...] who knows > what users are doing... Indeed. ;-) > On 6/23/20 9:36 PM, Thomas Schwinge wrote: >> I don't think I can approve, but seems fine if this works (as you've >> confirmed) -- it's one incremental step forward! (Noting that nobody spoke up against this.) >> What about 'gcc/config/i386/intelmic-mkoffload.c'? I see that one >> unconditionally passes '-fPIC' to some things -- is that doing the right >> thing for your case, too? > > I have not setup intelmic to test, but it uses -fPIC -share throughout > and in particular for the sister function to the one to those patched. > Hence, I expect that it will simply work. – But I wouldn't mind if you > could test that it indeed does work. I did now test this manually on a simple example, and yes, it works. (And, while Intel MIC offloading's emulated mode could be ported to other targets, it currently isn't, so Intel MIC (emulated) 'mkoffload' only needs to care about x86_64-pc-linux-gnu, and for that one, its unconditional '-fPIC' seems to be doing the expected thing.) Grüße Thomas - Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter
Re: [Patch][gcn, nvptx, offloading] mkoffload – handle -fpic/-fPIC
On Wed, Jun 24, 2020 at 03:36:25PM +0200, Tobias Burnus wrote: > > What about 'gcc/config/i386/intelmic-mkoffload.c'? I see that one > > unconditionally passes '-fPIC' to some things -- is that doing the right > > thing for your case, too? > > I have not setup intelmic to test, but it uses -fPIC -share throughout > and in particular for the sister function to the one to those patched. > Hence, I expect that it will simply work. – But I wouldn't mind if you > could test that it indeed does work. The intelmic model was that both the main program and shared libraries (which need offloading) contain in data section a shared library, and a small main program always the same (if I remember well) dlopens those shared libraries at runtime. While not very common today, it is possible multiple shared libraries or executable and one or more shared libraries have offloading code in them for the same offloading target. And one can deal with that only at runtime (== dynamic linking). Jakub
Re: [Patch][gcn, nvptx, offloading] mkoffload – handle -fpic/-fPIC
On 6/23/20 9:36 PM, Thomas Schwinge wrote: (*) Thomas mentioned that this is supposed to work also in more complex cases than the one I outlined, although, that is probably currently the most common one. Static linking is another such case that we've seen in the wild What I meant was: single library (static or dynamic) contains all offloading code – and rest of the code is free of offloading code. I think those two are the second most common – while a code where all offloading bits are in the program and not the library is by far the #1. – Other variants are much less likely, but who knows what users are doing... I don't think I can approve, but seems fine if this works (as you've confirmed) -- it's one incremental step forward! Or, should this instead be handled in the LTO wrapper (?) options merging etc. machinery? I'd have to dig in further. (Jakub?) The produced code cannot be much optimized (some tables), hence, some fancy flags are not needed (contrary to LTO). However, there might be other ABI relevant options besides -fPIC/-fpic (some -m... flag? For GCN, -march= is crucial, some ARM platform might have the same issue?) What about 'gcc/config/i386/intelmic-mkoffload.c'? I see that one unconditionally passes '-fPIC' to some things -- is that doing the right thing for your case, too? I have not setup intelmic to test, but it uses -fPIC -share throughout and in particular for the sister function to the one to those patched. Hence, I expect that it will simply work. – But I wouldn't mind if you could test that it indeed does work. Cheers, Tobias - Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter
Re: [Patch][gcn, nvptx, offloading] mkoffload – handle -fpic/-fPIC
On 23/06/2020 20:36, Thomas Schwinge wrote: Eventually (not now...), instead of special-casing more and more options (I somehow doubt that '-fpic', '-fPIC' are the only ones?), shouldn't we solve this in some more generic way, like re-invoking the host compiler exactly as invoked before (if that makes sense?), or -- freaky ;-) -- instead of doing the "LTO wrapper thing", pause the host compiler, generate offload code, inject that code into the host compiler, and directly proceed there? (That is, do offload code generation as part of the host compilation, instead of at link time.) (Just thinking aloud, and without and "depth" -- and any such work will be a bigger, separate task, obviously.) I thought the same, but it's better to fix one problem now than probably not getting around to fixing two problems later. In any case, we definitely want a white list, and explicit coding is easy to read. Andrew
Re: [Patch][gcn, nvptx, offloading] mkoffload – handle -fpic/-fPIC
Hi!
On 2020-06-23T17:21:06+0200, Tobias Burnus wrote:
> If the offloading code is (only) in a library, one can come up
> with the idea to build those parts as shared library – and link
> it to the nonoffloading code.(*)
> (*) Thomas mentioned that this is supposed to work also in more
> complex cases than the one I outlined, although, that is probably
> currently the most common one.
Static linking is another such case that we've seen in the wild -- and
that supposedly does work, mostly.
The "more complex cases" would include dynamically loading/registering
offloading code, and unregistering it again, and such things. The
interfaces are there (implemented), but testsuite coverage isn't -- so
I'm not going to claim that it actually works. ;-)
> Currently, this fails as the mkoffload calls the nonoffloading
> compiler without the -fpic/-fPIC flags, even though the compiler
> was originally invoked with those options. – And at some point,
> the linker then complains.
>
> This patch simply adds -fpic/-fPIC to the calls to the nonoffloading
> ("host") compiler, invoked from mkoffload, if they were present before.
>
> For the testcase at hand, this works with both AMDGCN and nvptx
> with the attached patch.
>
> OK for the trunk?
I don't think I can approve, but seems fine if this works (as you've
confirmed) -- it's one incremental step forward!
Or, should this instead be handled in the LTO wrapper (?) options merging
etc. machinery? I'd have to dig in further. (Jakub?)
Eventually (not now...), instead of special-casing more and more options
(I somehow doubt that '-fpic', '-fPIC' are the only ones?), shouldn't we
solve this in some more generic way, like re-invoking the host compiler
exactly as invoked before (if that makes sense?), or -- freaky ;-) --
instead of doing the "LTO wrapper thing", pause the host compiler,
generate offload code, inject that code into the host compiler, and
directly proceed there? (That is, do offload code generation as part of
the host compilation, instead of at link time.) (Just thinking aloud,
and without and "depth" -- and any such work will be a bigger, separate
task, obviously.)
> PS: I think as mid-/longterm project it would be nice to test this
> in the testsuite, but that's unfortunately a larger task.
ACK.
> gcc/config/gcn/mkoffload.c | 15 +--
> gcc/config/nvptx/mkoffload.c | 15 +--
> 2 files changed, 26 insertions(+), 4 deletions(-)
What about 'gcc/config/i386/intelmic-mkoffload.c'? I see that one
unconditionally passes '-fPIC' to some things -- is that doing the right
thing for your case, too?
Grüße
Thomas
> diff --git a/gcc/config/gcn/mkoffload.c b/gcc/config/gcn/mkoffload.c
> index 14f422e..0415d94 100644
> --- a/gcc/config/gcn/mkoffload.c
> +++ b/gcc/config/gcn/mkoffload.c
> @@ -483,7 +483,8 @@ process_obj (FILE *in, FILE *cfile)
> /* Compile a C file using the host compiler. */
>
> static void
> -compile_native (const char *infile, const char *outfile, const char
> *compiler)
> +compile_native (const char *infile, const char *outfile, const char
> *compiler,
> + bool fPIC, bool fpic)
> {
>const char *collect_gcc_options = getenv ("COLLECT_GCC_OPTIONS");
>if (!collect_gcc_options)
> @@ -493,6 +494,10 @@ compile_native (const char *infile, const char *outfile,
> const char *compiler)
>struct obstack argv_obstack;
>obstack_init (_obstack);
>obstack_ptr_grow (_obstack, compiler);
> + if (fPIC)
> +obstack_ptr_grow (_obstack, "-fPIC");
> + if (fpic)
> +obstack_ptr_grow (_obstack, "-fpic");
>if (save_temps)
> obstack_ptr_grow (_obstack, "-save-temps");
>if (verbose)
> @@ -596,6 +601,8 @@ main (int argc, char **argv)
>/* Scan the argument vector. */
>bool fopenmp = false;
>bool fopenacc = false;
> + bool fPIC = false;
> + bool fpic = false;
>for (int i = 1; i < argc; i++)
> {
> #define STR "-foffload-abi="
> @@ -614,6 +621,10 @@ main (int argc, char **argv)
> fopenmp = true;
>else if (strcmp (argv[i], "-fopenacc") == 0)
> fopenacc = true;
> + else if (strcmp (argv[i], "-fPIC") == 0)
> + fPIC = true;
> + else if (strcmp (argv[i], "-fpic") == 0)
> + fpic = true;
>else if (strcmp (argv[i], "-save-temps") == 0)
> save_temps = true;
>else if (strcmp (argv[i], "-v") == 0)
> @@ -766,7 +777,7 @@ main (int argc, char **argv)
>xputenv (concat ("COMPILER_PATH=", cpath, NULL));
>xputenv (concat ("LIBRARY_PATH=", lpath, NULL));
>
> - compile_native (gcn_cfile_name, outname, collect_gcc);
> + compile_native (gcn_cfile_name, outname, collect_gcc, fPIC, fpic);
>
>return 0;
> }
> diff --git a/gcc/config/nvptx/mkoffload.c b/gcc/config/nvptx/mkoffload.c
> index efdf9b9..4fecb2b 100644
> --- a/gcc/config/nvptx/mkoffload.c
> +++ b/gcc/config/nvptx/mkoffload.c
> @@ -356,7 +356,8 @@ process (FILE *in, FILE *out)
> }
>
> static void
> -compile_native (const char *infile, const char
Re: [Patch][gcn, nvptx, offloading] mkoffload – handle -fpic/-fPIC
On 23/06/2020 16:21, Tobias Burnus wrote:
If the offloading code is (only) in a library, one can come up
with the idea to build those parts as shared library – and link
it to the nonoffloading code.(*)
Currently, this fails as the mkoffload calls the nonoffloading
compiler without the -fpic/-fPIC flags, even though the compiler
was originally invoked with those options. – And at some point,
the linker then complains.
This patch simply adds -fpic/-fPIC to the calls to the nonoffloading
("host") compiler, invoked from mkoffload, if they were present before.
For the testcase at hand, this works with both AMDGCN and nvptx
with the attached patch.
OK for the trunk?
The GCN bit is OK.
Andrew
