Re: egcs-19980803 (pre-1.1) solaris regressions

["David S. Miller" <davem at dm dot cobaltmicro dot com>]

   Date: Fri, 7 Aug 1998 16:28:45 -0400 (EDT)
   From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>

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