https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119691
Peter Bergner <bergner at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bergner at gcc dot gnu.org
--- Comment #1 from Peter Bergner <bergner at gcc dot gnu.org> ---
(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?
