https://sourceware.org/bugzilla/show_bug.cgi?id=31503
--- Comment #2 from John David Anglin <danglin at gcc dot gnu.org> --- Created attachment 15431 --> https://sourceware.org/bugzilla/attachment.cgi?id=15431&action=edit Assembly file Attached is an assembly file demonstrating the problem. It's derived from the assembly output at -O1 for the gcc.c-torture/execute/packed-aligned.c test. I changed this code addil LR'g_expect-$global$,%r27 fstd %fr22,RR'g_expect-$global$(%r1) in main to addil LR'g_expect-$global$,%r27 fstd %fr22,RR'g_expect-$global$(%r1) ldo RR'g_expect-$global$(%r1),%r1 fstd %fr22,0(%r1) so I could see what was happening to the symbolic relocation in the fstd instruction. This is the code in the final executable: 10574: 2b 60 00 00 addil L%0,dp,r1 10578: 70 36 00 20 std r22,10(r1) 1057c: 34 21 00 20 ldo 10(r1),r1 10580: 2c 20 12 16 fstd fr22,0(r1) The fstd instruction has changed to a std instruction. In the .o object file, we have: 7c: 2b 60 00 00 addil L%0,dp,r1 80: 70 36 00 02 fstd fr22,0(r1) 84: 34 21 00 00 ldo 0(r1),r1 88: 2c 20 12 16 fstd fr22,0(r1) We have the following relocations: 0000007c R_PARISC_DPREL21L g_expect 00000080 R_PARISC_DPREL14R g_expect 00000084 R_PARISC_DPREL14R g_expect The format 3 (im10a) variants of ldd and fldd differ in bit 30. ldd has a 0 and fldd a 1. -- You are receiving this mail because: You are on the CC list for the bug.
