http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59581
Bug ID: 59581
Summary: [SH] insns that use r0...r7 are put into delay slot of
rte
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*
The following code:
extern int* ext_buf;
void __attribute__((interrupt_handler, nosave_low_regs)) my_handler (void)
{
ext_buf[0] = 4;
}
compiled with -m4 -O2 results in:
mov.l .L26,r1
mov #4,r2
mov.l @r1,r1
rte
mov.l r2,@r1
On SH3* and SH4* such ISRs are supposed to run with SR.RB = 1 (second set of
r0...r7 registers selected). The rte insn will then switch back to SR.RB = 0.
The insn in the rte delay slot refers to the restored SSR -> SR value, i.e. it
will use SR.RB = 0 and thus the code above is wrong.
If an ISR has the 'nosave_low_regs' attribute set and the target is SH3* or
SH4* there should be no insns allowed in the rte delay slot that refer to
r0...r7.
