[Bug c/50705] New: Wrong assembly generated in ppc 476

[Bug c/50705] New: Wrong assembly generated in ppc 476

[santoshkumar.a at gmail dot com]

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

             Bug #: 50705
           Summary: Wrong assembly generated in ppc 476
    Classification: Unclassified
           Product: gcc
           Version: 4.6.1
            Status: UNCONFIRMED
          Severity: blocker
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: santoshkumar.a@gmail.com


I built a GCC Little-Endian 32-bit Cross compiler for powerpc 476 with the
below components.

1.    GCC 4.6.1
2.    GLIBC 2.13
3.    BINUTILS 2.21.53
4.    Linux kernel headers 2.6.39

I used the same to build Linux kernel 2.6.39.4 in Little-Endian 32-bit.

The kernel while coming up in start_kernel does calls as shown below
  start_kernel --> pidhash_init  --> alloc_large_system_hash.

kernel/pid.c
1) When pidinit_hash with  HASH_EARLY & HASH_SMALL args call
alloc_large_system_hash here at pid.c, line::5362 
the if condition fails.

Condition::
HASH_EARLY 0x1
HASH_SMALL 0x2
flags value is 0x3

therefore the below if is expected to pass, but it fails.
        if(flags & HASH_EARLY)

reason: it generates "rlwinm r0,r7,1,31,31" with r7 = 3 this instruction
results in 0 and jumps to 0x70305bf4 as shown in 
without_print/objdump_without_print file at line:: 980046.

After i added a prink before "if" the condition passed as the assembly
generated is different as as shown in
with_print/objdump_print file at line:: 980044.

I have encountered another bitwise and failing in
arch/powerpc/mm/mmu_context_nohash.c at 
"mmu_has_feature(MMU_FTR_47x)"

[Bug c/50705] Wrong assembly generated in ppc 476

[santoshkumar.a at gmail dot com]

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

SK <santoshkumar.a at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |https://rapidshare.com/file
                   |                            |s/1485249627/gcc_bug_ppc_47
                   |                            |6.rar

--- Comment #1 from SK <santoshkumar.a at gmail dot com> 2011-10-12 16:36:26 UTC ---
Attachment::
https://rapidshare.com/files/1485249627/gcc_bug_ppc_476.rar;

[Bug target/50705] Wrong assembly generated in ppc 476

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
          Component|c                           |target
           Severity|blocker                     |normal

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> 2011-10-12 17:25:00 UTC ---
Can you attach it to the bug rather than use another URL?  Also can you use
tar/gzip and not rar (rar is not fully free and such).

[Bug target/50705] Wrong assembly generated in ppc 476

[santoshkumar.a at gmail dot com]

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

--- Comment #3 from SK <santoshkumar.a at gmail dot com> 2011-10-13 05:41:20 UTC ---
Created attachment 25481
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25481
system map, objdump, source code

As the earlier file was 14MB with large objdump.I have copied the code around
the area of problem. 

In the objdump search for page_alloc.c:5362 where this issue is seen. You can
compare the same with the code in the attachment.

[Bug target/50705] Wrong assembly generated in ppc 476

[santoshkumar.a at gmail dot com]

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

--- Comment #4 from SK <santoshkumar.a at gmail dot com> 2011-10-13 10:46:32 UTC ---
Please download the full dump(14MB)from ftp0.lsil.com by following below
commands
login:
user: ftp, 
password: anonymous, 
cd pub
binary #
get gcc_bug_ppc_476_mini.zip (NOTE:: ls/dir not supported)
quit

[Bug target/50705] Wrong assembly generated in ppc 476

[santoshkumar.a at gmail dot com]

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

--- Comment #5 from SK <santoshkumar.a at gmail dot com> 2011-10-14 03:29:48 UTC ---
Wrong assembly being is generated in most of the bitwise and's conditions that
have pass are failing and those that have to fail are passing.

[Bug target/50705] Wrong assembly generated in ppc 476

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> 2011-10-14 03:36:01 UTC ---
"Little-Endian 32-bit."  Is there a reason why you are using little-endian with
PPC?

[Bug target/50705] Wrong assembly generated in ppc 476

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> 2011-10-14 03:36:38 UTC ---
How did you configure GCC?

[Bug target/50705] Wrong assembly generated in ppc 476

[santoshkumar.a at gmail dot com]

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

--- Comment #8 from SK <santoshkumar.a at gmail dot com> 2011-10-14 04:48:13 UTC ---
Yes the HW engine that is present on the controller works in Little endian
therefore we need linux to work in LE on PPC. 

I changed 
Binutils
GLIBC
GCC

GCC Changes::


Binutils
gas/configure:
  case "$endian" in
      big)  ;;
      little) ;;


GLIBC
GCC

1)
gcc/config/rs6000/sysv4.h
#define    TARGET_DEFAULT (MASK_POWERPC | MASK_NEW_MNEMONICS |
MASK_LITTLE_ENDIAN)
ASM_SPEC

2)
mcall-gnu             :-mlittle;    \
++  mcall-i960-old        :-mlittle}    \
++-mlittle"

3)
#define CC1_ENDIAN_DEFAULT_SPEC "%(cc1_endian_little)"
#define    MULTILIB_DEFAULTS { "mlittle", "mcall-sysv" }

4)
CC1_SPEC
mcall-gnu             : -mlittle %(cc1_endian_little);  \
+   mcall-i960-old        : -mlittle %(cc1_endian_little);  \
+                         : %(cc1_endian_default)}          \

5)
LINK_SPEC:
added -EL at the end

LINK_TARGET_SPEC
added  --oformat elf32-powerpcle at end

[Bug target/50705] Wrong assembly generated for bitwise AND for ppc 476

[santoshkumar.a at gmail dot com]

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

--- Comment #9 from SK <santoshkumar.a at gmail dot com> 2011-10-14 16:26:38 UTC ---
Below is another scenario::

test_bit called with args 
PG_slab = 7;
page->flags = 0xc0;
test_bit(PG_slab, &page->flags) returns value 0. This is used by PageSlab in
linux kernel.

/**
 * test_bit - Determine whether a bit is set
 * @nr: bit number to test
 * @addr: Address to start counting from
 */
static inline int test_bit(int nr, const volatile unsigned long *addr)
{
    return 1UL & (addr[BIT_WORD(nr)] >> (nr & (BITS_PER_LONG-1)));
}

but if i modify the return as 

    return (addr[BIT_WORD(nr)] >> (nr & (BITS_PER_LONG-1)));

the results are as expected, which i dont understand.

Also in all the scenarios that i reported earlier the bitwise AND is in between
a variable and a constants.

[Bug target/50705] Wrong assembly generated for bitwise AND for ppc 476

[santoshkumar.a at gmail dot com]

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

--- Comment #10 from SK <santoshkumar.a at gmail dot com> 2011-10-17 17:16:36 UTC ---
Please let me know if I have to add or remove any GCC options while configuring
it or while compiling Linux. 

Any comment which can help me move further will be helpful.

[Bug target/50705] Wrong assembly generated for bitwise AND for ppc 476

[santoshkumar.a at gmail dot com]

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

--- Comment #11 from SK <santoshkumar.a at gmail dot com> 2011-10-19 14:22:16 UTC ---
FILE::
/mm/page_alloc.c:5363
flags -> 0x3
HASH_EARLY - > 0x1

CODE::
if (flags & HASH_EARLY)

Assembly:
70307c44:       fe 0f e0 54     rlwinm  r0,r7,1,31,31

r7 = 0x3 = 0000 0000 0000 0000 0000 0000 0000 0011 (bits 0...31. So, bit 30 ==
1 and bit 31 == 1).

HASH_EARLY should ideally be seen by the compiler as 0000 0000 0000 0000 0000
0000 0000 0001 (bits 0...31. So, bit 31 == 1).

So, if in Little Endian mode, then in PowerPC terms the above "if" is testing
bit 31 of the flags field. 
In which case, the compiler should be generating assembly as: rlwinm 
r0,r7,0,31,31

However, it appears the compiler sees HASH_EARLY as 1000 0000 0000 0000 0000
0000 0000 0000 (bits 0...31. So, bit 0 == 1).
So, if in Little Endian mode, then in PowerPC terms the above "if" is testing
bit 0 of the flags field.
In which case, the compiler is generating assembly as: rlwinm  r0,r7,1,31,31

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

CODE::
MMU_FTR_TYPE_47x has 0x40
cur_cpu_spec->mmu_features -> 0x140040

static inline int mmu_has_feature(unsigned long feature) {
        return(cur_cpu_spec->mmu_features & feature); }

Assembly:
andis.  r10,r11,512

What the above assembly instruction does is basically this: r10 = r11 & (512 <<
16) = r11 & 0x02000000 (i.e. bit 6 is getting tested).
Now, where does 512 come from? Let's look at MMU_FTR_TYPE_47x:

MMU_FTR_TYPE_47x should ideally be seen by the compiler as 0000 0000 0000 0000
0000 0000 0100 0000 (bits 0...31. So, bit 25 == 1).
So, if in Little Endian mode, then in PowerPC terms the above "&" operation is
testing bit 25 of the cur_cpu_spec->mmu_features field.
In which case, the compiler should be generating assembly as: andi.  r10,r11,64

However, it appears the compiler sees MMU_FTR_TYPE_47x as 0000 0010 0000 0000
0000 0000 0000 0000 (bits 0...31. So, bit 6 == 1).
So, if in Little Endian mode, then in PowerPC terms the above "&" is testing
bit 6 of the cur_cpu_spec->mmu_features field.
In which case, the compiler is generating assembly as: andis.  r10,r11,512

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Therefore it appears that constants are being interrupted wrongly i.e as a
mirror image.

Few Observations:
1) After I compile a small piece of code and run " file <binary> " the output
is 

ELF 32-bit LSB executable, PowerPC, Versoin 1 (SYSV), dynamically linked (uses
shared libs), for GNU/Linux 2.6.39, not stripped

2) __LITTLE_ENDIAN is defined.

3) Though the above 2 are true the machine is still working in Big Endian.
confirmed by writing 1 into b and reading a[0]. which reads 0.
union endian{
      unsigned int b;
      unsigned char a[4] ;
}

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

[Bug target/50705] Wrong assembly generated for bitwise AND for ppc 476

[santoshkumar.a at gmail dot com]

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

SK <santoshkumar.a at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID

--- Comment #12 from SK <santoshkumar.a at gmail dot com> 2011-12-26 14:08:05 UTC ---
Invalid.