[Bug c/12460] New: In-correct code generated for sh-elf target.

[rakeshku at noida dot hcltech dot com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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

           Summary: In-correct code generated for sh-elf target.
           Product: gcc
           Version: 3.4
            Status: UNCONFIRMED
          Severity: critical
          Priority: P1
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: rakeshku at noida dot hcltech dot com
                CC: gcc-bugs at gcc dot gnu dot org,naveens at noida dot
                    hcltech dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: sh-unknown-elf

Consider the following testcase. It is taken from gcc.c-
torture/compile/20001121-1.c

int foo(int x)
{
  return 1 + bar(
        ({
                int y;
                switch (x)
                {
                case 0: y = 1; break;
                case 1: y = 2; break;
                case 2: y = 3; break;
                case 3: y = 4; break;
                case 4: y = 5; break;
                case 5: y = 6; break;
                default: y = 7; break;
                }
                y;
        })
     );
}

With -O2 -ml -m4 options, it generates the following assembly.

_foo:
        mov.l   r14,@-r15
        cmp/hi  r1,r4
        sts.l   pr,@-r15
        bt/s    .L2
        mov     r15,r14
        mov.l   .L13,r0         <-- Here
        add     r4,r4
        mov.w   @(r0,r4),r1
.L2:
        mov.l   .L14,r0
        jsr     @r0
        mov     r1,r4
        add     #1,r0
        mov     r14,r15
        lds.l   @r15+,pr
        rts
        mov.l   @r15+,r14
.L15:
        .align 2
.L13:
        .long   .L10
.L14:
        .long   _bar
        .size   _foo, .-_foo

In the instruction marked "Here", the literal label L13 is referred, which 
further refers L10. And L10 is lost. So the code generated is in-correct.
It compiles, because semantically there is nothing wrong in the assembly. 
Hence no failure is produced.

L10 was lost during flow2. In fact most of rtl has gone haywire.

The problems started when I updated my sources on September 15, 2003. 
Prior to it, it was working fine.

Regards and Thanks,
Rakesh Kumar