http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53886
Oleg Endo <olegendo at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kkojima at gcc dot gnu.org
--- Comment #2 from Oleg Endo <olegendo at gcc dot gnu.org> 2012-07-08 11:40:56
UTC ---
I'm just guessing here, but this line
&& GET_CODE (PATTERN (NEXT_INSN (PREV_INSN (insn)))) != SEQUENCE
looks suspicious. Most likely it's a nullptr access.
In sparc.c something similar is being done by the function
'int empty_delay_slot (rtx insn)'
Maybe the patch below could be a fix for the problem?
There are actually more places in sh.c where the usage of NEXT_INSN (PREV_INSN
(insn)) goes unchecked...
Kaz, what do you think? Does this make any sense?
Index: gcc/config/sh/sh.c
===================================================================
--- gcc/config/sh/sh.c (revision 189339)
+++ gcc/config/sh/sh.c (working copy)
@@ -9652,6 +9652,15 @@
#define IS_ASM_LOGICAL_LINE_SEPARATOR(C, STR) ((C) == ';')
#endif
+static bool
+sequence_insn_p (rtx insn)
+{
+ if (PREV_INSN (insn) == NULL)
+ return false;
+
+ return GET_CODE (PATTERN (NEXT_INSN (PREV_INSN (insn)))) == SEQUENCE;
+}
+
int
sh_insn_length_adjustment (rtx insn)
{
@@ -9662,7 +9671,7 @@
&& GET_CODE (PATTERN (insn)) != CLOBBER)
|| CALL_P (insn)
|| (JUMP_P (insn) && !JUMP_TABLE_DATA_P (insn)))
- && GET_CODE (PATTERN (NEXT_INSN (PREV_INSN (insn)))) != SEQUENCE
+ && ! sequence_insn_p (insn)
&& get_attr_needs_delay_slot (insn) == NEEDS_DELAY_SLOT_YES)
return 2;
@@ -9671,7 +9680,7 @@
if (sh_cpu_attr == CPU_SH2E
&& JUMP_P (insn) && !JUMP_TABLE_DATA_P (insn)
&& get_attr_type (insn) == TYPE_CBRANCH
- && GET_CODE (PATTERN (NEXT_INSN (PREV_INSN (insn)))) != SEQUENCE)
+ && ! sequence_insn_p (insn))
return 2;
/* sh-dsp parallel processing insn take four bytes instead of two. */
