egcs 1.0.2 is broken on x86 and a patch for it.

[H.J. Lu]

>   > Basically convert_regs () calls change_stack () with INSN to emit
>   > some insn after INSN. But some insn has been added after INSN so
>   > that change_stack () will emit some insn at the wrong place. As the
>   > result, the floating point is broken on x86.
> This is an extremely confusing explanation, primarily because you
> use "insn"/INSN to refer to three different things.
> 
> Basically is sounds like you have
> 
> 	insn 1
>         insn 2
> 
> 
> It sounds like we thought we wanted to insert after insn 1, but
> because of other reg-stack actions we really wanted to insert
> after insn 2.
> 
>   > This patch seems to fix it. Could someone please take a look? Given
>   > the bugs we have seen in egcs 1.0.2, I suggest egcs 1.0.3 be made.
> I must confess I don't undersatnd reg-stack all that well.  Assuming
> your analysis and explanation are correct, then I think your change
> is OK, though possibly incomplete.
> 
> In particular I worry that we need to pass "new" instead of "insn"
> to the call to emit_pop_insn near the end of convert_regs.  I think
> the call to goto_block_pat in convert_regs is OK.

I don't think using "new" will be a problem. At least, it should
introduce a new bug. I don't think subst_stack_regs will add a JUMP
INSN. If it does, that may be a bug in reg-stack.c by itself. We can
add

	if (new != insn && GET_CODE (new) == JUMP_INSN)
	  abort ();

to catch that.

How about straighten_stack () just before convert_regs () returns?

> 
> I also worry that there may be cases were we need to insert after
> insn 1 instead of after insn 2.  But I don't know reg-stack well

That is possible, but not likely. As I said in my previous email.
insn 2 is really the part of insn 1 in this case. Put anything
in between will defeat the whole purpose of inserting insn 2 after
insn 1.


-- 
H.J. Lu (hjl@gnu.org)