[Bug c/52334] New: The user of "zero" register is wrong

[Bug c/52334] New: The user of "zero" register is wrong

[cslhc at qq dot com]

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

             Bug #: 52334
           Summary: The user of "zero" register is wrong
    Classification: Unclassified
           Product: gcc
           Version: 4.3.2
            Status: UNCONFIRMED
          Severity: critical
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: cslhc@qq.com


When I use MIPS Cross-compiler 4.3.2 and version 3.2.1 to compile a same
functin, there have been two different result, as follows:

This is my function code:

ulong test_function(ulong index,ushort app)
{
        _Struct_PST_ID *pstid = NULL;    //there have a bug,when user version
4.3.2 compiler.
        switch(app)
        {
                case _MODULE_ID_V:
                {        
                        if ( VALIDATE_INDEX( index ) )
                        {
                                if( _find_port( g_pstv->member.pstid, index,
(void*)&pstid)
                                        == TRUE)
                                {
                                        return pstid->ulType;
                                }        
                        }
                        return SUCCESS;
                }
                        break;
                case _MODULE_ID_M:
                {        
                        if ( VALIDATE_INDEX( index ) )
                        {
                                if( _find_port( g_pstm->member.pstid, index,
(void*)&pstid)
                                        == TRUE)
                                {
                                        return pstid->ulType;
                                }        
                        }
                        return SUCCESS;
                }
                        break;
                default:
                        break;
        }

        return SUCCESS;
}


a. This is result of 4.3.2
gcc version 4.3.2 (eCosCentric GNU tools 4.3.2-sw)


(gdb) x  0x8017ed5c
0x8017ed5c <test_function+156>:        0x0805fb38
(gdb) disa
disable      disassemble
(gdb) disassemble test_function
Dump of assembler code for function test_function:
0x8017ecc0 <test_function+0>:  andi    a1,a1,0xffff
0x8017ecc4 <test_function+4>:  li      v0,92
0x8017ecc8 <test_function+8>:  beq     a1,v0,0x8017ed20 <test_function+96>
0x8017eccc <test_function+12>: addiu   sp,sp,-8
0x8017ecd0 <test_function+16>: li      v0,93
0x8017ecd4 <test_function+20>: beq     a1,v0,0x8017ece8 <test_function+40>
0x8017ecd8 <test_function+24>: sltiu   v0,a0,26
0x8017ecdc <test_function+28>: li      v0,1
0x8017ece0 <test_function+32>: jr      ra
0x8017ece4 <test_function+36>: addiu   sp,sp,8
0x8017ece8 <test_function+40>: beqz    v0,0x8017ecdc <test_function+28>
0x8017ecec <test_function+44>: lui     v0,0x805a
0x8017ecf0 <test_function+48>: lw      v1,19204(v0)
0x8017ecf4 <test_function+52>: lw      a1,4(v1)
0x8017ecf8 <test_function+56>: beqz    a1,0x8017ecdc <test_function+28>
0x8017ecfc <test_function+60>: move    v1,a1
0x8017ed00 <test_function+64>: lw      v0,4(v1)
0x8017ed04 <test_function+68>: beq     a0,v0,0x8017ed5c <test_function+156>
0x8017ed08 <test_function+72>: nop
0x8017ed0c <test_function+76>: lw      v1,60(v1)
0x8017ed10 <test_function+80>: bne     a1,v1,0x8017ed00 <test_function+64>
0x8017ed14 <test_function+84>: li      v0,1
0x8017ed18 <test_function+88>: j       0x8017ece0 <test_function+32>
0x8017ed1c <test_function+92>: nop
0x8017ed20 <test_function+96>: sltiu   v0,a0,26
0x8017ed24 <test_function+100>:        beqz    v0,0x8017ecdc <test_function+28>
0x8017ed28 <test_function+104>:        lui     v0,0x8067
0x8017ed2c <test_function+108>:        lw      v1,28060(v0)
0x8017ed30 <test_function+112>:        lw      a1,4(v1)
0x8017ed34 <test_function+116>:        beqz    a1,0x8017ecdc <test_function+28>
0x8017ed38 <test_function+120>:        move    v1,a1
0x8017ed3c <test_function+124>:        lw      v0,4(v1)
0x8017ed40 <test_function+128>:        beq     a0,v0,0x8017ed5c
<test_function+156>
0x8017ed44 <test_function+132>:        nop
0x8017ed48 <test_function+136>:        lw      v1,60(v1)
0x8017ed4c <test_function+140>:        bne     a1,v1,0x8017ed3c
<test_function+124>
0x8017ed50 <test_function+144>:        li      v0,1
0x8017ed54 <test_function+148>:        j       0x8017ece0 <test_function+32>
0x8017ed58 <test_function+152>:        nop
0x8017ed5c <test_function+156>:        j       0x8017ece0 <test_function+32>
0x8017ed60 <test_function+160>:        lw      v0,76(zero)    //This should not
be "zero" .
End of assembler dump. 


b. This is result of 3.2.1
gcc version 3.2.1 (eCosCentric GNU tools 3.2.1-sw)


This GDB was configured as "--host=i686-pc-linux-gnu --target=mipsisa32-elf".
For bug reporting instructions, please see:
<http://bugs.ecos.sourceware.org/>...
(gdb) disassemble test_function
Dump of assembler code for function test_function:
0x801748a4 <test_function+0>:  addiu   sp,sp,-32
0x801748a8 <test_function+4>:  andi    a1,a1,0xffff
0x801748ac <test_function+8>:  li      v0,92
0x801748b0 <test_function+12>: sw      ra,16(sp)
0x801748b4 <test_function+16>: beq     a1,v0,0x80174910 <test_function+108>
0x801748b8 <test_function+20>: sw      zero,0(sp)
0x801748bc <test_function+24>: li      v0,93
0x801748c0 <test_function+28>: beq     a1,v0,0x801748d8 <test_function+52>
0x801748c4 <test_function+32>: sltiu   v0,a0,26
0x801748c8 <test_function+36>: li      v0,1
0x801748cc <test_function+40>: lw      ra,16(sp)
0x801748d0 <test_function+44>: jr      ra
0x801748d4 <test_function+48>: addiu   sp,sp,32
0x801748d8 <test_function+52>: beqz    v0,0x801748cc <test_function+40>
0x801748dc <test_function+56>: li      v0,1
0x801748e0 <test_function+60>: lui     v0,0x805b
0x801748e4 <test_function+64>: lw      v1,20936(v0)
0x801748e8 <test_function+68>: move    a1,a0
0x801748ec <test_function+72>: lw      a0,4(v1)
0x801748f0 <test_function+76>: jal     0x80174368 <_find_port>
0x801748f4 <test_function+80>: move    a2,sp
0x801748f8 <test_function+84>: li      v1,1
0x801748fc <test_function+88>: bnel    v0,v1,0x801748cc <test_function+40>
0x80174900 <test_function+92>: li      v0,1
0x80174904 <test_function+96>: lw      v0,0(sp)
0x80174908 <test_function+100>:        b       0x801748cc <test_function+40>
0x8017490c <test_function+104>:        lw      v0,76(v0)    //right
0x80174910 <test_function+108>:        sltiu   v0,a0,26
0x80174914 <test_function+112>:        beqz    v0,0x801748cc <test_function+40>
0x80174918 <test_function+116>:        li      v0,1
0x8017491c <test_function+120>:        lui     v0,0x8058
0x80174920 <test_function+124>:        b       0x801748e8 <test_function+68>
0x80174924 <test_function+128>:        lw      v1,31260(v0)
End of assembler dump.

[Bug middle-end/52334] The user of "zero" register is wrong

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |middle-end
           Severity|critical                    |normal

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-02-22 05:39:31 UTC ---
First can you provide the preprocessed source?  Second can you try with a newer
version of GCC like maybe 4.4.6?  Third can you describe why you think the
assembly that GCC produces is wrong.

[Bug middle-end/52334] The user of "zero" register is wrong

[cslhc at qq dot com]

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

--- Comment #2 from haichang417 <cslhc at qq dot com> 2012-02-22 06:52:12 UTC ---
(In reply to comment #1)
> First can you provide the preprocessed source?  Second can you try with a newer
> version of GCC like maybe 4.4.6?  Third can you describe why you think the
> assembly that GCC produces is wrong.

    Thank you for your reply. I'm sorry I can't provide the preprocessed
code.Because I used 3.2.1 version of cross-compiler(MIPS target)，and it is very
difficult to create a new version of the cross-compiler.

    In test_function(), I declared a structure(_Struct_PST_ID *pstid =
NULL),and point to NULL. In _find_port( g_pstv->member.pstid, index,
(void*)&pstid) function , the empty structure point to a new address of
structure.But I found the address of pointer is still 0. When I view the
Assembly code, found that the above error. The above error will not appear when
I use 3.2.1 version,So I think the assembly that GCC 4.3.2 produces is wrong.

[Bug middle-end/52334] The user of "zero" register is wrong

[mikpe at it dot uu.se]

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

--- Comment #3 from Mikael Pettersson <mikpe at it dot uu.se> 2012-02-22 09:07:20 UTC ---
(In reply to comment #0)
>                                 if( _find_port( g_pstv->member.pstid, index,
> (void*)&pstid)

This bit looks like a strict-aliasing violation waiting to happen.

[Bug middle-end/52334] The user of "zero" register is wrong

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2012-02-22
     Ever Confirmed|0                           |1

--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-02-22 09:33:10 UTC ---
Waiting for a compilable testcase.

[Bug middle-end/52334] The user of "zero" register is wrong

[cslhc at qq dot com]

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

--- Comment #5 from haichang417 <cslhc at qq dot com> 2012-02-23 01:01:56 UTC ---
(In reply to comment #3)
> (In reply to comment #0)
> >                                 if( _find_port( g_pstv->member.pstid, index,
> > (void*)&pstid)
> 
> This bit looks like a strict-aliasing violation waiting to happen.

    But When I compiled without any warning that about strict-aliasing. I think
that his result is caused by the optimization. In the assembly of 4.3.2, there
is nothing code about calling the _find_port() func.

    lw      v0,76(zero)  //"zero" should be "v1"

[Bug middle-end/52334] The user of "zero" register is wrong

[mikpe at it dot uu.se]

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

--- Comment #6 from Mikael Pettersson <mikpe at it dot uu.se> 2012-02-23 01:10:57 UTC ---
This is all speculation.  We need a complete compilable testcase.

[Bug middle-end/52334] The user of "zero" register is wrong

[pinskia at gcc dot gnu.org]

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

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

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

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
No testcase in the last year so closing as invalid.