This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
- From: "kkojima at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 29 Jan 2010 02:19:57 -0000
- Subject: [Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
- References: <bug-42841-18412@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #23 from kkojima at gcc dot gnu dot org 2010-01-29 02:19 -------
I agree with you that there is a latent problem. It seems
that sh_reorg inserts a CP with a new jump at the landing pad
for the exception in basic.cc and propagation_consistent.cc
cases. This confuses EH processing because the labels for
landing pads are defined and recorded very early and used later
to output DW2 frame data, unfortunately. A simple work around
may be not to insert a jump+CP at the possible position for
the landing pad. The patch
--- ORIG/trunk/gcc/config/sh/sh.c 2010-01-26 18:33:47.000000000 +0900
+++ trunk/gcc/config/sh/sh.c 2010-01-29 09:56:50.000000000 +0900
@@ -4641,6 +4641,9 @@ find_barrier (int num_mova, rtx mova, rt
a jump makes it more likely that the bra delay slot will be
filled. */
while (NOTE_P (from) || JUMP_P (from)
+ || (flag_exceptions
+ && CALL_P (from)
+ && find_reg_note (from, REG_EH_REGION, NULL_RTX))
|| LABEL_P (from))
from = PREV_INSN (from);
fixes the failures for basic.cc and propagation_consistent.cc,
though it doesn't fix the execution failures for get_future.cc
and get.cc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841