https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465
Eric Botcazou <ebotcazou at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|WAITING |NEW --- Comment #27 from Eric Botcazou <ebotcazou at gcc dot gnu.org> --- Thanks. This seems to be a conjunction of several factors, the initial one being that the 4.8+ compiler generates (e.g for the reduced testcase at -O): addl r14 = @ltoffx(_rtld_local#+15032385536), r1 ;; ld8.mov r14 = [r14], _rtld_local#+15032385536 The huge number is not problematic per se, although it very likely runs afoul of some limitation/quirk here, since the value loaded from the GOT is truncated. In fact it looks like the value loaded from the GOT is just the huge number, that is to say the value of _rtld_local has been zeroed during the relocation. This may come from _rtld_local being in the .sdata section, in which case there is a relevant comment in sdata_symbolic_operand: /* Deny the stupid user trick of addressing outside the object. Such things quickly result in GPREL22 relocation overflows. Of course, they're also highly undefined. From a pure pedant's point of view they deserve a slap on the wrist (such as provided by a relocation overflow), but that just leads to bugzilla noise. */ In other words, the compiler skips the efficient @gprel relocation on purpose, only to generate the @ltoffx relocation, which doesn't work either here...