https://sourceware.org/bugzilla/show_bug.cgi?id=25599
--- Comment #9 from John Buddery <jvb at cyberscience dot com> --- Thanks very much for the analysis - I agree, this is about slot numbers not offsets and the comment is inaccurate. I too found the HP behaviour odd, when considering the instruction as using slots 1 and 2. Possibly the reasoning is that the actual instruction really occupies slot 2, with slot 1 containing 39 bits of the immediate. So, HP could argue that the instruction slot is 2, even though the relocation starts at slot 1. In any case, the HP tool chain generates the relocation that way. For this reason, HP would effectively be unable to make a linker change without breaking the existing library codebase. It's also vanishingly unlikely they will make further changes as the OS is end of life in 2025. The binutils linker does not support HP, otherwise of course the preferred solution would be to use that So, the only possibility to get a working gas is compatibility with the HP linker, and I would ask you to please consider keeping this change - with an improved comment to say this is a workaround for the HP linker using slot 2 as the target. As far as I can tell, it is only the immediate-60 relocation that has problems on HP. I have not seen issues with any of the immediate-64 relocations, at least not in any of the instructions gcc generates. -- You are receiving this mail because: You are on the CC list for the bug.
