This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Committed, CRIS: Fix assumption on absence of notes between tablejump and jump-table label.


I've convinced myself that it has been mostly a coincidence (and
more notes emitted recently) that from the beginning of the port
(gcc-2.1-ish) up till now there has been no notes between the
tablejump insn and the label for the jump-table.  I see no
documentation that promises absence of notes there, and no other
occurrences in the GCC code that assumes it.  All code getting
from the label to the tablejump uses prev_nonnote_insn, code
looking from the tablejump to the jump-table label uses
JUMP_LABEL.  (In contrast to the label before the jump-table: no
insn, note or label must be inserted between it and the
jump-table.  At least two places in the GCC core uses
NEXT_INSN/PREV_INSN to get from one to the other.)

For this particular failure instance, the NOTE_INSN_LOOP_END
note is attached after the last insn of a block by
cfgloopmanip.c:create_loop_notes.  This last insn is the
tablejump; the jump-table is outside that basic block.  The
emit_note_after function doesn't check what insn the note is
attached after, and neither does any caller *generally*,
i.e. not counting checks related to the particular note-type.
There doesn't seem to be any reason they should do any such
checking.

Well, ok, it *may* matter that cfgloopmanip.c:create_loop_notes
*does* check if then next insn is a barrier.  Maybe it should
step over the jump-table for a tablejump too, before checking
for that barrier?  Still, it didn't do that before the failure,
so that may be a bug, but that's not a strong indication for me
that notes may never end up there.

I re-built with a tree saved from the last time things worked
for me, at 2004-07-02 (which may have been weeks before the
actual exposing change happened).  At that time, this basic
block wasn't identified as part of a loop, so the immediate
reason for the exposure is supposedly better loop detection.

I hope Jeff's concern is covered above.

Test-results are at the expected level of unexpectedness.  I
guess I should install that GMP/MPFR to enable fortran for
better coverage...

	* config/cris/cris.h (ASM_OUTPUT_CASE_END): Use prev_nonnote_insn
	to get the tablejump-insn before the jump-table label.

Index: cris.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/cris/cris.h,v
retrieving revision 1.76
diff -p -c -r1.76 cris.h
*** cris.h	14 Jul 2004 06:24:12 -0000	1.76
--- cris.h	3 Sep 2004 16:13:04 -0000
*************** extern const char *cris_elinux_stacksize
*************** call_ ## FUNC (void)						\
*** 1537,1544 ****
  		   CODE_LABEL_NUMBER					\
  		    (XEXP (XEXP (XEXP					\
  				  (XVECEXP				\
! 				    (PATTERN (PREV_INSN (PREV_INSN	\
! 							  (TABLE))),	\
  				     0, 0), 1), 2), 0)),		\
  		   NUM,							\
  		   (TARGET_PDEBUG ? "; default" : ""));			\
--- 1537,1545 ----
  		   CODE_LABEL_NUMBER					\
  		    (XEXP (XEXP (XEXP					\
  				  (XVECEXP				\
! 				    (PATTERN				\
! 				     (prev_nonnote_insn			\
! 				      (PREV_INSN (TABLE))),		\
  				     0, 0), 1), 2), 0)),		\
  		   NUM,							\
  		   (TARGET_PDEBUG ? "; default" : ""));			\

brgds, H-P


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]