Bug 10834 - GCC for ARM 3.3 still generates incorrect instructions for functions with __attribute__ ((interrupt ("IRQ")))
Summary: GCC for ARM 3.3 still generates incorrect instructions for functions with __a...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 3.3
: P3 normal
Target Milestone: 3.3.1
Assignee: Not yet assigned to anyone
URL:
Keywords: wrong-code
: 9372 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-05-17 09:26 UTC by dong_geming
Modified: 2005-07-23 22:49 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description dong_geming 2003-05-17 09:26:01 UTC
I cmopiled the following file with gcc 3.3 for ARM.

  /* begin of file ext_irq.c */
void ext_IRQ0_handler(void) __attribute__ ((interrupt ("IRQ")));
void ext_IRQ0_handler(void)
{
   int i = 0;
   i = i++;
}
  /* end of file ext_irq.c */

If it was Compiled with the following command:
    arm-elf-gcc -gdwarf ext_irq.c -o.\debug\ext_irq.o
then Dump the ext_irq.o, and we can get the following code:

00000000 <ext_IRQ0_handler>:
   0:	e52dc004 	str	ip, [sp, -#4]!
   4:	e1a0c00d 	mov	ip, sp
   8:	e24ee004 	sub	lr, lr, #4	; 0x4
   c:	e92dd80e 	stmdb	sp!, {r1, r2, r3, fp, ip, lr, pc}
  10:	e24cb004 	sub	fp, ip, #4	; 0x4
  14:	e24dd004 	sub	sp, sp, #4	; 0x4
  18:	e3a03000 	mov	r3, #0	; 0x0
  1c:	e50b3020 	str	r3, [fp, -#32]
  20:	e24b1020 	sub	r1, fp, #32	; 0x20
  24:	e5913000 	ldr	r3, [r1]
  28:	e1a02003 	mov	r2, r3
  2c:	e50b2020 	str	r2, [fp, -#32]
  30:	e2833001 	add	r3, r3, #1	; 0x1
  34:	e5813000 	str	r3, [r1]
  38:	e95b980e 	ldmdb	fp, {r1, r2, r3, fp, ip, pc}^


On the other way, If it was Compiled with the following command:
    arm-elf-gcc -mthumb-interwork -gdwarf ext_irq.c -o.\debug\ext_irq.o
then Dump the ext_irq.o, and we can get the following code:

00000000 <ext_IRQ0_handler>:
   0:	e52dc004 	str	ip, [sp, -#4]!
   4:	e1a0c00d 	mov	ip, sp
   8:	e24ee004 	sub	lr, lr, #4	; 0x4
   c:	e92dd80e 	stmdb	sp!, {r1, r2, r3, fp, ip, lr, pc}
  10:	e24cb004 	sub	fp, ip, #4	; 0x4
  14:	e24dd004 	sub	sp, sp, #4	; 0x4
  18:	e3a03000 	mov	r3, #0	; 0x0
  1c:	e50b3020 	str	r3, [fp, -#32]
  20:	e24b1020 	sub	r1, fp, #32	; 0x20
  24:	e5913000 	ldr	r3, [r1]
  28:	e1a02003 	mov	r2, r3
  2c:	e50b2020 	str	r2, [fp, -#32]
  30:	e2833001 	add	r3, r3, #1	; 0x1
  34:	e5813000 	str	r3, [r1]
  38:	e91b680e 	ldmdb	fp, {r1, r2, r3, fp, sp, lr}
  3c:	e89d1000 	ldmia	sp, {ip}
  40:	e25ef004 	subs	pc, lr, #4	; 0x4

*******************************
***********PROBLEM*************
*******************************
   Both of the compiled results are not correct. Because
the "sp" register is not restored correctly, It can be 
discovered easily, if we debug this codes on a E.V. board.

Release:
GCC 3.3

Environment:
cygwin --host=i686-pc-cygwin  --target=arm-elf
Comment 1 Richard Earnshaw 2003-05-22 10:40:33 UTC
Already fixed on trunk, now fixed for 3.3.1 with:

2003-05-19  Nick Clifton  <nickc@redhat.com>

        * config/arm/arm.c (use_return_insn): Do not use a single return
        instruction for interrupt handlers which have to create a stack
        frame.
        (arm_expand_prologue): Do not pre-bias the return address of
        interrupt handlers which create a stack frame.

In both cases the code now generated is:

        str     ip, [sp, #-4]!
        mov     ip, sp
        stmfd   sp!, {r1, r2, r3, fp, ip, lr, pc}
        sub     fp, ip, #4
        sub     sp, sp, #4
        ...  @ body of function.
        ldmea   fp, {r1, r2, r3, fp, sp, lr}
        ldmfd   sp!, {ip}
        subs    pc, lr, #4
Comment 2 Richard Earnshaw 2003-05-22 10:44:52 UTC
*** Bug 6039 has been marked as a duplicate of this bug. ***
Comment 3 Richard Earnshaw 2003-05-22 10:46:12 UTC
*** Bug 6040 has been marked as a duplicate of this bug. ***
Comment 4 Richard Earnshaw 2003-05-22 10:47:50 UTC
*** Bug 7941 has been marked as a duplicate of this bug. ***
Comment 5 Richard Earnshaw 2003-05-22 10:49:17 UTC
*** Bug 7960 has been marked as a duplicate of this bug. ***
Comment 6 Richard Earnshaw 2003-05-22 10:51:17 UTC
*** Bug 7328 has been marked as a duplicate of this bug. ***
Comment 7 Nathanael C. Nerode 2003-05-23 06:26:50 UTC
yep.
Comment 8 Richard Earnshaw 2003-05-28 15:20:06 UTC
*** Bug 9372 has been marked as a duplicate of this bug. ***