https://sourceware.org/bugzilla/show_bug.cgi?id=20805
--- Comment #12 from Cary Coutant <ccoutant at gmail dot com> --- (In reply to Markus Trippelsdorf from comment #8) > But Jakub wrote in the gcc bug: > > »As for the ld.bfd optimization that makes linking with ld.bfd work, that is > an optimization if there are any IE relocations then other GD/LD relocations > are turned into them too, because once you have any IE relocations, all of > the TLS has to be static anyway, so the TLS GD/LD calls are just a waste of > time.« > > So either this is a missed optimization for gold, or ld.bfd generates wrong > code. Yes, we could take the presence of a R_X86_64_GOTTPOFF relocation as a signal that it's OK to optimize for the IE model. But to do it reliably, it would require us to pre-scan the relocations before making any optimization decisions. If we see a GD relocation that could have been optimized before we see any GOTTPOFF relocations, we wouldn't be able to optimize that relocation. I don't think that slowing the link down by adding another pass over the relocations is worth it. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
