[Bug gas/24349] New: [powerpc] gas rejects valid branch instruction and doesn't set "at" branch hints correctly

[bergner at linux dot ibm.com]

https://sourceware.org/bugzilla/show_bug.cgi?id=24349

            Bug ID: 24349
           Summary: [powerpc] gas rejects valid branch instruction and
                    doesn't set "at" branch hints correctly
           Product: binutils
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gas
          Assignee: unassigned at sourceware dot org
          Reporter: bergner at linux dot ibm.com
  Target Milestone: ---

address@hidden:~/binutils/BCTAR$ cat -n bug1.s 
     1          .text
     2  start:
     3          bclr    0,0
     4          bctar   0,0
     5          bcctr   0,0
address@hidden:~/binutils/BCTAR$ as -mpower8 bug1.s 
bug1.s: Assembler messages:
bug1.s:4: Error: invalid counter access
bug1.s:5: Error: invalid counter access

A BO value using a “decrement and test CTR” option is only invalid for the
bcctr insn.  It should be valid for bctar as it is for bclr.  The problem is
the "invalid counter access" test in insert_bo() and insert_boe() isn't
specific enough to distinguish between bcctr and bctar.  That fix is easy
enough.  However, looking closer, I see that we also have a problem setting the
"at" branch hints for some insns.

In the test case below, we have bclr insns using a BO value of'0b1a01t'.  The
first explicitly sets the "at" bits to "11", meaning likely taken.  In the
second insn, we use the "+" opcode suffix to set the bits.  They should encode
to the exact same insn, but they don't.

address@hidden:~/binutils/BCTAR$ cat bug2.s 
        .text
bclr:
        bclr    0b11011,0
        bclr+   0b10010,0
address@hidden:~/binutils/BCTAR$ as -mpower8 -o bug2.o bug2.s 
address@hidden:~/binutils/BCTAR$ objdump -d -Mpower8 bug2.o 
   0:   20 00 60 4f     bdzlr+
   4:   20 00 60 4e     bclr+   18,lt

Looking at the disassembled bits, we can see the insn that used the "+" opcode
suffix only set the "t" bit, which was the old "y" bit.  This leaves us with an
"at" branch hint of "01" which is a reserved value.

I'm working on a patch.

-- 
You are receiving this mail because:
You are on the CC list for the bug.