https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87833
Bug ID: 87833
Summary: Intel MIC (emulated) offloading: "relocation [...] can
not be used when making a shared object; recompile
with -fPIC"
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: openmp
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tschwinge at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, iverbin at gcc dot gnu.org,
jakub at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-intelmicemul-linux-gnu
Created attachment 44937
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44937&action=edit
WIP patch/work around
Commit r263988 (for PR86517 "relocation R_X86_64_32 against `.rodata.str1.1'
can not be used when making a shared object with LTO") makes a lot of (or even
all?) Intel MIC offloading test cases fail to compile:
[...]/ld: /tmp/ccCCZyfF.o: relocation R_X86_64_32S against `[...]' can not
be used when making a shared object; recompile with -fPIC
/tmp/ccCCZyfF.o: error adding symbols: Bad value
mkoffload-intelmic: fatal error: [...]
I have not yet analyzed what's actually going wrong. Before spending more time
on this, I first wanted to make sure that's still useful -- given that in the
past two months apparently nobody but me has run into this (or didn't bother to
report it), and I thus wonder whether anyone but me is still testing Intel MIC
(emulated) offloading?
No idea yet if the attached patch/hack is correct in any way, but it at least
restores Intel MIC (emulated) offloading compilation.
