[Bug rtl-optimization/50110] New: Endian reversal when adding extzv instruction

["david.meggy at icron dot com" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50110

             Bug #: 50110
           Summary: Endian reversal when adding extzv instruction
    Classification: Unclassified
           Product: gcc
           Version: 4.6.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: david.meggy@icron.com


We are in the process of adding a bitfield extract instruction to the SPARC
Leon processor for a custom embedded product

I've added the following to the sparc.md file

(define_insn "extzvsi"
  [(set (match_operand:SI 0 "register_operand" "=r")
       (zero_extract:SI (match_operand:SI 1 "register_operand" "r")
                         (match_operand 2 "const_int_operand" "")
                         (match_operand 3 "const_int_operand" "")))]
  ""
  "ext\t%1,%2,%3,%0"
  )

and GCC will start producing assembly code that uses the new opcode


However on simple test programs the endian seems to be reversed

struct x {
    unsigned int a:4;
    unsigned int b:2;
    unsigned int c:3;
    unsigned int d:3;
    unsigned int e:20;
};

unsigned int a(struct x * arg)
{ return arg->a; }

unsigned int b(struct x * arg)
{ return arg->b; }

unsigned int c(struct x * arg)
{ return arg->c; }

unsigned int d(struct x * arg)
{ return arg->d; }

unsigned int e(struct x * arg)
{ return arg->e; }


compiled with -Os -S

results in

        .file   "davidm.c"
        .section        ".text"
        .align 4
        .global a
        .type   a, #function
        .proc   016
a:
        ld      [%o0], %o0
        jmp     %o7+8
         srl    %o0, 28, %o0
        .size   a, .-a
        .align 4
        .global b
        .type   b, #function
        .proc   016
b:
        ld      [%o0], %o0
        jmp     %o7+8
         ext    %o0,2,4,%o0
        .size   b, .-b
        .align 4
        .global c
        .type   c, #function
        .proc   016
c:
        ld      [%o0], %o0
        jmp     %o7+8
         ext    %o0,3,6,%o0
        .size   c, .-c
        .align 4
        .global d
        .type   d, #function
        .proc   016
d:
        ld      [%o0], %o0
        jmp     %o7+8
         ext    %o0,3,9,%o0
        .size   d, .-d
        .align 4
        .global e
        .type   e, #function
        .proc   016
e:
        ld      [%o0], %g1
        sethi   %hi(-1048576), %o0
        jmp     %o7+8
         andn   %g1, %o0, %o0
        .size   e, .-e
        .ident  "GCC: (GNU) 4.6.1"

Just looking at functions a() and b(), a() is using the bitfields in big endian
order as it should for SPARC, but b() seems to be using the bitfields in little
endian order.