https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412
--- Comment #18 from iverbin at gcc dot gnu.org --- (In reply to Uroš Bizjak from comment #17) > The x86 backend did survive many years just fine, so I think offload should > be fixed to follow approach that generic middle-end takes. The testcase I > posted expands without problems; in this case middle-end knows that symbol > address has to be moved to a register. It looks like offload bypasses > generic expansion functions (that would magically fix this issue). It seems that the problem with offload is that -fPIC option is passed to the offload compiler, but not passed to the host compiler. If I add -fPIC to the host compiler as well, everything is ok. Offload RTL for pic host, pic offload: (insn 8 6 9 4 (set (reg:DI 88) (mem/u/c:DI (const:DI (unspec:DI [ (symbol_ref:DI ("G") <var_decl 0x7f2c78238c60 G>) ] UNSPEC_GOTPCREL)) [0 S8 A8])) addr.c:6 -1 (nil)) Offload RTL for nonpic host, pic offload: (insn 8 6 9 4 (set (reg:CC 17 flags) (compare:CC (mem/f/c:DI (plus:DI (reg/f:DI 82 virtual-stack-vars) (const_int -8 [0xfffffffffffffff8])) [0 p+0 S8 A64]) (symbol_ref:DI ("G") <var_decl 0x7f5546a88c60 G>))) addr.c:6 -1 (nil)) I don't know how -fPIC option affects IR before streaming out, -fdump-tree-optimized are identical for pic/nonpic cases, but .gnu.offload_lto_.decls sections are different. However debug_tree (vnode->decl) for "G" in ipa_write_summaries are identical for pic/nonpic cases. So, the question is, how to figure out what is different in G's declaration in IR, and how it can affect further expansion?