Re: target/2467: MIPS cross-assembler reports error for constant PC-relative branches

[cgd@sibyte.com (Chris G. Demetriou)]

The following reply was made to PR target/2467; it has been noted by GNATS.

From: cgd@sibyte.com (Chris G. Demetriou)
To: vvortex1@home.com
Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org
Subject: Re: target/2467: MIPS cross-assembler reports error for constant PC-relative branches
Date: 03 Apr 2001 17:13:35 -0700

 vvortex1@home.com writes:
 > When given a PC-relative branch instruction with a numeric immediate, such as "bne $0, $0, 16", the MIPS cross-assembler correctly parses the expression but fails to generate object code. It reports "Can not represent BFD_RELOC_16_PCREL_S2 relocation in this object file format". Strictly speaking, no relocation information is necessary because the value of the immediate field is already known. This error is generated in all known emulation modes.
 > >How-To-Repeat:
 > Contents of broken.s:
 > bne $0, $0, 8
 > nop
 > nop
 > nop
 > nop
 > ------
 > 
 > To reproduce, run:
 > % mips64orion-rtems-as broken.s
 > None of the configuration options seem to have any effect on this glitch.
 > >Fix:
 > Beats me ;-) The assembler should simply store the supplied numeric operand shifted right two places.
 
 (1) why have you reported this as a GCC bug?
 
 (2) in general, I suspect that what's happening here is that it's
 taking '8' as the address '8', and trying to convert that to a branch
 using a PC-relative relocation.
 
 
 I would guess that what you mean here is ".+8" or similar.
 
 I find that, indeed, with current-ish assemblers:
 
         bne     $0, $0, .+8
 
 assembles into:
 
    0:   14000001        bnez    $zero,0x8
    4:   00000000        nop
 
 which is, i believe, what you want.
 
 
 cgd