[Bug rtl-optimization/17186] [3.4/3.5 regression] ICE in move_for_stack_reg, at reg-stack.c:1065

["ian at wasabisystems dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From ian at wasabisystems dot com  2004-09-02 03:16 -------
I took a quick look.  I think the basic problem is that the register stack pass
expects the register liveness information to match the instructions used.  The
test case is a tricky one because the function often does not return any value.  

Before the basic block reordering pass, the function looks approximately like this:

st = 0;
st(1) = st;
if (eax != 0)
  bar();
st = st(1);

After the basic block reordering pass, the function is rewritten to look
approximately like this:

st = 0;
st(1) = st;
if (eax == 0)
  st = st(1);
else {
  bar();
  st = st(1);
}

Since the function returns the type double, the return value can be found in st.
 Note that st and st(1) are clobbered by the function call to bar().  This
doesn't matter when compiling this function, because in the case where bar() is
called, no return value is specified.  However, this means that in the last
basic block, st(1) is not live on entry.  Since reg-stack does not expect to see
a reference to a register which is not live on entry to the block and is not set
 inside the block, it blows up.

At this point I do not know what the right fix is.  If the final copy of "st =
st(1);" were removed, the compiler would probably not blow up.  That instruction
was created by the basic block reordering pass, when it inserted a new basic
block.  However, it is useless, since it just copies around a dead value. 
Alternatively, perhaps reg-stack should not be so fussy.

I don't think this bug has much to do with the patch which Richard wrote and I
checked in.  That patch presumably hides this bug in some manner.  But I would
expect that there is still a latent bug which could surface whenever the block
reordering pass duplicates an assignment of values which are actually dead.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17186