Fix crossing jumps in functions with forced_labels (PR rtl-optimization/57763)

Message ID
State New
Headers show

Commit Message

Jakub Jelinek Jan. 17, 2014, 8:31 a.m.

As mentioned in the PR, on alpha (but I don't see a reason why it can't
occur on most other targets except for i?86/x86_64, cr16, m32c, moxie and
msp430) if a function has non-NULL forced_labels (contains computed goto),
we can get ICEs due to incorrect EDGE_CROSSING flags on some edges.

The problem is that if not HAS_LONG_UNCOND_BRANCH,
fix_crossing_unconditional_branches changes normal unconditional jumps into
indirect jumps that jump to a single label, because normal jump might not
be able to jump to very far other section.  But, turning the jump into
indirect one means computed_jump_p is true on those, and such jumps are
supposed to have edges to all forced_labels, but
fix_crossing_unconditional_branches doesn't add those and just if say
post-reload splitter attempts to change something, we can end up calling
make_edges and that might not give the right flags to the edges.
As the indirect jump jumps to a single label only, I don't see why we should
require edges to all forced_labels, we know the single label to which it can
jump.  So the following patch fixes that by setting JUMP_LABEL on the
indirect jump, which results e.g. into computed_jump_p no longer returning
true for it.

Bootstrapped/regtested on x86_64-linux and i686-linux (where it isn't
called, sure) and Uros has bootstrapped/regtested this on Alpha.  Ok for

2014-01-17  Jakub Jelinek  <>

	PR rtl-optimization/57763
	* bb-reorder.c (fix_crossing_unconditional_branches): Set JUMP_LABEL
	on the new indirect jump_insn.



--- gcc/bb-reorder.c.jj	2014-01-03 11:41:01.000000000 +0100
+++ gcc/bb-reorder.c	2014-01-16 12:49:27.695377777 +0100
@@ -2183,6 +2183,8 @@  fix_crossing_unconditional_branches (voi
 	      emit_insn_before (indirect_jump_sequence, last_insn);
 	      delete_insn (last_insn);
+	      JUMP_LABEL (jump_insn) = label;
 	      /* Make BB_END for cur_bb be the jump instruction (NOT the
 		 barrier instruction at the end of the sequence...).  */