------- Comment #14 from rth at gcc dot gnu dot org 2009-11-14 02:22 ------- This is a linker bug. Recompiling without -g, so as to get error messages without the unhelpful symbolic interpretation, I can reproduce
msmpeg4.c:(.text.unlikely+0xbe2): relocation truncated to fit: GPREL22 against `.bss' msmpeg4.c:(.text.unlikely+0xc80): relocation truncated to fit: GPREL22 against `.bss' Matching these offsets up with the object file, we see 000000000be2 000400000086 R_IA64_LTOFF22X 0000000000000000 .bss + 29658 000000000c80 000400000086 R_IA64_LTOFF22X 0000000000000000 .bss + 2a560 Notice these are *not* GPREL22 relocations, but LTOFF22X relocations. These LTOFF22X relocations are supposed to be relaxed to GPREL22 relocations by the linker, but ONLY IF the address is in range; otherwise they are to be interpreted as LTOFF22 relocations which store the full address in the GOT. Unfortunately, the ia64 linker doesn't implement --no-relax, like other targets do, so it's not easy to work around this bug. Also, it would be extremely helpful if there was a linker switch that disabled symbolic interpretation of section+offset. I spent a lot of time looking at the wrong addresses... I've created http://sourceware.org/bugzilla/show_bug.cgi?id=10955 to track this problem. You'll need to create new bugzilla accounts on the sourceware system in order to get CC'd. Closing this as not-a-gcc-bug. -- rth at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41567
