From mboxrd@z Thu Jan 1 00:00:00 1970 From: "David S. Miller" To: ghazi@caip.rutgers.edu Cc: egcs-bugs@cygnus.com, rth@cygnus.com, law@cygnus.com, tm@netcom.com Subject: Re: egcs-19980803 (pre-1.1) solaris regressions Date: Tue, 18 Aug 1998 06:21:00 -0000 Message-id: <199808181205.FAA23454@dm.cobaltmicro.com> References: <199808072028.QAA01298@caip.rutgers.edu> X-SW-Source: 1998-08/msg00343.html List-Id: Date: Fri, 7 Aug 1998 16:28:45 -0400 (EDT) From: "Kaveh R. Ghazi" Hi Kaveh, The following errors (except for 930628-1) are regressions from prior releases/snapshots, but they don't appear in "make check" because the testsuite doesn't run with -fpic/-fPIC. ERROR: 930628-1.c: compiled program got signal 11: -O -fno-omit-frame-pointer -fpic ERROR: 930628-1.c: compiled program got signal 11: -O -fomit-frame-pointer -fpic Interesting, as I have begun to look into these tonight. The cause of all these errors is the same thing, and it is related to another recent thread on here from which I will quote the following: > In message < 199808151124.EAA24081@netcom8.netcom.com >you write: > > I'm seeing some strange problems with reload and I think it may have > > something to do with basic_block_head[] and basic_block_tail[]... > > > > Specifically, the current implementation of basic_block_head[] and > > basic_block_tail[] seem to point at actual insns. This seems bad > > because reload calls emit_insn_before() and emit_insn_after(), and these > > functions seem unaware of the existence of the basic_block_head/tail arrays. > > > > Consider: if reload generates a spill for the first insn of a > > basic block, it seems to insert the insns into the basic block outside > > the one intended, or even outside the outermost basic block, like this: > It's a problem, but not a serious one. Nothing bad should happen as > far as I know. (The bulk of the quoted text is from Toshiyasu Marita, the final comment is from Jeff Law). No Jeff, that is incorrect, it is a _serious_ problem. Something bad does in fact happen if the basic blocks get spilled over like this. For one, and this is the failure mode we are seeing on Sparc with Kaveh's PIC test case failures, reorg can't figure out the correct basic block to re-record liveness information when filling delay slots, and as a result the lifetime info becomes corrupt and thus will cause reorg to clobber registers illegally. For example, in one of the Sparc PIC testcases mentioned above reorg changes: bne .LL36 nop ld [%l7+.LLC0],%o2 ld [%o2],%f2 st %f2,[%i5+%i3] b .LL18 nop .LL36: mov 0,%l7 sll %l0,4,%o0 into: bne .LL36 mov 0,%l7 <=== This is illegal ld [%l7+.LLC0],%o2 <=== whoops, we crash here now ld [%o2],%f2 b .LL18 st %f2,[%i5+%i3] .LL25: mov 0,%l7 .LL36: sll %l0,4,%o0 And it is because reload emits: ;; End of basic block 6 (note 340 51 349 "" NOTE_INSN_DELETED) ;; Insn is not within a basic block (insn 349 340 350 (set (reg:SI 10 %o2) (mem/u:SI (plus:SI (reg:SI 23 %l7) (symbol_ref/u:SI ("*.LLC0"))))) 113 {*movsi_insn} (nil) (expr_list:REG_EQUAL (symbol_ref/u:SI ("*.LLC0")) (nil))) (note 350 349 353 "" NOTE_INSN_DELETED) ;; Insn is not within a basic block (insn 353 350 75 (set (reg:SF 34 %f2) (mem:SF (reg:SI 10 %o2))) 124 {*movsf_insn} (nil) (nil)) ;; Start of basic block 7, registers live: 14 [%sp] 30 [%fp] 31 [%i7] 105 106 107 108 114 117 120 121 122 125 126 132 (insn:HI 75 353 76 (set (mem/s:SF (plus:SI (reg:SI 29 %i5) (reg:SI 27 %i3))) (reg:SF 34 %f2)) 124 {*movsf_insn} (nil) (nil)) (jump_insn 76 75 77 (set (pc) (label_ref 185)) 360 {jump} (nil) (nil)) The insn 75 needed a reload to form the address. Reload emitted the reload insns before it into spots before bblock 7 begins (as Toshi has explained it will do). Later reorg says "aha, %l7 is not live, the clr of it in the target of this branch, so I can put the clear of it in the delay slot." Voila :-( I am really surprised we've never been bitten by this before. Later, David S. Miller davem@dm.cobaltmicro.com