------- 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
