https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #166 from dave.anglin at bell dot net --- On 2020-02-12 5:26 p.m., peter.bisroev at groundlabs dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 > > --- Comment #165 from Peter Bisroev <peter.bisroev at groundlabs dot com> --- > Hi Dave, > > (In reply to dave.anglin from comment #162) >> On 2020-02-12 10:38 a.m., peter.bisroev at groundlabs dot com wrote: >>> The exact HP linker errors from linking cc1, cc1plus and lto1 were (I was >>> compiling in parallel): >>> -------------------- >>> ld: The value 0xfffffffffdc6eaf0 does not fit when applying the relocation >>> PCREL21B for symbol ".text" at offset 0x102 in section index 51 of file >>> libbackend.a[sancov.o] >> The value doesn't fit in 21 bits. >> >> The relocations are introduced by the assembler. You might check if the HP >> assembler can assemble sancov.s and see what type of relocations are used. >> You can run readelf on .o to see relocations. > Unfortunately I was not able to assemble sancov.s using HPs assembler due to > too many syntax errors. So I tried to find something that can be compiled with > aCC. This might be a wrong approach but it was quick to test out so decided to > give it a go :) > >> It looks like the problem is branches to weak functions. > I went back to gcc 4.9.4 and tried doing stage1 bootstrap with '-O0'. As > expected, we got the same error (only relevant one shown for gimple-expr.c): > -------------------- > ld: The value 0xfffffffffdf81640 does not fit when applying the relocation > PCREL21B for symbol ".text" at offset 0x102 in section index 59 of file > libbackend.a[gimple-expr.o] > -------------------- > The dump for gimple-expr.c Unless I am mistaken, from the dump in attachment > 47828 it is a weak relocation. The problem is is the branch offset is too big. I believe GNU ld will create a PLTOFF entry in the PLT to handle this, but that's not happening with HP ld. In pa, we have have the -mlong-calls option which avoids these pc-relative branches. It would be helpful to know how aCC avoids this problem. > > I was then able to compile the same file but with aCC and attached results > (including an elfdump) in attachment 47829. Unless I am mistaken, weak > relocations are not being used. Is this something expected? It's the branch distance distance that's the main problem. Weak functions are available in C but they are much more common in C++. Have to run.
