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