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.