------- Comment #3 from abel at gcc dot gnu dot org 2010-09-20 13:05 -------
We have the code like this:
if (...)
{
17 cx:DI=[`s2'] //comes from s2.vl += s1.vl;
...
}
27 dx:DI=[`s2'] //comes from s1 = s2;
When the scheduler tries to move insn 27 before if (...), it also unifies its
right-hand sides, as they seem equal. The scheduler wants to get:
27 dx:DI=[`s2']
if (...)
{
cx = dx
...
dx:DI=[`s2'] // bookkeeping
}
The insn 17 has its MEM with volatile bit set, the insn 27 has it unset. It so
happens that when gathering the available insn set and when moving the actually
selected insn, insns 17 and 27 got merged in the different order. First we
don't have the volatile bit on the resulting insn, thus we believe the load
does not trap and we move it up through a jump before the 'if'. Second we have
the bit and thus insn traps and we don't move it, then we hit the consistency
assert in the scheduler.
Now, I'm happy to implement the correct merging of the may_trap_p bit in the
scheduler which would "fix" this. However, looking at the original C code it
looks like both MEMs should have their volatile bit set. I can only say that
the original bits seem to come from expand, the addresses got propagated by
fwprop but this doesn't seem to be the issue.
--
abel at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |abel at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45472
