public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "mmz at gmx dot net" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/16634] arm-elf-gcc problems when generating code for __attribute__ ((interrupt ("IRQ"))) Date: Thu, 07 Feb 2008 13:55:00 -0000 [thread overview] Message-ID: <20080207135415.3606.qmail@sourceware.org> (raw) In-Reply-To: <bug-16634-8979@http.gcc.gnu.org/bugzilla/> ------- Comment #10 from mmz at gmx dot net 2008-02-07 13:54 ------- (In reply to comment #9) > is this bug still present in 4.2.2? I can confirm this bug still exists in 4.2.2 and 4.2.3. > Acc. to my obervations the error only shows up when not all auto variables can > be mapped to registers, and additional variables are located on stack. As a > work-around, if a more complex interrupt handler is needed, place the code in a > subfunction and call this function from the interrupt handler. In this case no > stack is reserved in the interrupt handler, and the generated code is OK. Care > must be taken, of course, that the optimizer does not inline the code for > IntFunc(). Your subfunction workaround actually did the trick. The generated return instruction is "ldm sp!, {r0, r1, r2, r3, ip, pc}^". However, if a more complex interrupt handler is implemented the wrong return instruction generated. The results seem a bit unpredictable so I currently use plain assembler for my interrupts. Example: extern __attribute__ ((interrupt ("IRQ"))) void base_int_ctrl_top_irq_handler(void) { int_ctrl_status_t status; status.val = READ_REG_U32(ADDR_STATUS_NIRQ); if (status.bf.x) { puts("Spurious x IRQ!"); } else if (status.bf.y) { puts("Spurious y IRQ!"); } else if (status.bf.timer) { base_timer_interrupt(); } else if (status.bf.z) { puts("Spurious z IRQ!"); } else { puts("Spurious unknown IRQ!"); } } Generated assembly for return: pop {r0, r1, r2, r3, ip, lr} subs pc, lr, #4 ; 0x4 (and lr was already decremented by 4 when the handler was entered) So your observations are correct. Bug #27859 seems to be a duplicate of this bug and contains a patch. However, this patch is probably not optimal since it just replaces the final "subs" by a "movs" while the best solution seems to be the "ldmfd ..." instruction above. -- mmz at gmx dot net changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mmz at gmx dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16634
next prev parent reply other threads:[~2008-02-07 13:55 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <bug-16634-8979@http.gcc.gnu.org/bugzilla/> 2006-08-08 23:05 ` pbrook at gcc dot gnu dot org 2006-08-08 23:47 ` pbrook at gcc dot gnu dot org 2006-09-11 10:41 ` rearnsha at gcc dot gnu dot org 2006-09-11 11:31 ` tbm at cyrius dot com 2006-11-14 16:28 ` tla at thrane dot com 2007-01-04 0:10 ` pbrook at gcc dot gnu dot org 2007-05-03 2:14 ` david+gcc at porkrind dot org 2007-08-06 9:08 ` sgh at sgh dot dk 2007-11-08 21:42 ` ralf dot guetlein at web dot de 2008-02-07 13:55 ` mmz at gmx dot net [this message] 2009-02-12 21:58 ` sgh at sgh dot dk 2010-01-09 23:27 ` ramana at gcc dot gnu dot org 2004-07-19 19:27 [Bug c/16634] New: arm-elf-gcc 3.4.0 " bob at cnxtech dot com 2004-10-07 16:14 ` [Bug target/16634] arm-elf-gcc " pinskia at gcc dot gnu dot org 2005-07-02 1:31 ` pinskia at gcc dot gnu dot org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20080207135415.3606.qmail@sourceware.org \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).