https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119691
--- Comment #2 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to Peter Bergner from comment #1) > (In reply to Sergey Fedorov from comment #0) > > :info:build ld: bl out of range (-16839456 max is +/-16M) from > > __ZN10hash_tableI19default_hash_traitsIP11cgraph_edgeELb0E11xcallocatorED1Ev > > at 0x1010140A4 in __text of libbackend.a(ipa-cp.o) to __Z8ggc_freePv at > > 0x100004EA0 in __text of libbackend.a(ggc-page.o) in > > __ZN10hash_tableI19default_hash_traitsIP11cgraph_edgeELb0E11xcallocatorED1Ev > > from libbackend.a(ipa-cp.o) > > :info:build collect2: error: ld returned 1 exit status > [snip] > > It seems that nothing is wrong with my tools (after all, they work robustly > > on 32-bit ppc), and the bug is in gcc itself. Unless I miss something. > > Not a GCC bug. The bl instruction has a signed 24-bit displacement and the > call to __Z8ggc_freePv is just too far away. That function is external to > the function we're compiling, so we cannot know before hand how far away it > is. > > It's the linker that is complaining here and it is the linker's job to > insert a trampoline if the branch displacement is too far away. The current > binutils linker (at least on Linux) will do that for you. Maybe the older > binutils version linker used on darwin doesn't have that capability or is > broken somehow? it's always been broken, unfortunately (for a start, it gets the range wrong) At that stage, there were not many exes that were large enough to trigger an issue.. ... there are various hacks that fix the range - but still that is not enough for exes if of significant size - like clang .... I have a fixed version of ld64 where the branch islands work properly. @sergey ld64-85.2.1 is borked ld64-97.x is better but still limited IFF my current published patched ld64 does not work for you - then I will have to make some effort to publish the latest.
