[Bug rtl-optimization/42511] [4.5 Regression] bootstrap error in stage3 on alpha-linux-gnu

["ebotcazou at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #23 from ebotcazou at gcc dot gnu dot org  2010-01-07 08:22 -------
> I'm thinking about the same situation with cse2, where constant assignment
> (with its REG_EQUAL note) would match another assignment with the same
> REG_EQUAL note. cse2 can equal this other assignment (through matching
> REG_EQUAL notes) to the constant - actually the same thing that happens in our
> problematic case. Since this transformation would happen in the same BB, it
> would be perfectly valid - and disabled by removing REG_EQUAL note on 
> constant.

This mechanism very likely results in a bug if the 2 insns are not originally
in the same BB, like in the case at hand.  So, assuming they are originally in
the same BB and carry the same REG_EQUAL note, the constant will be propagated
in both insns.

> Sure, but after the assigment was moved, REG_EQUAL points to invalid
> assignment, see this part from the dumps:
> 
>    39 r78:DI=zero_extend(r154:QI)
>       REG_DEAD: r154:QI
>       REG_EQUAL: zero_extend([r152:DI])
>   583 r82:DI=0x0                                  << here
>       REG_EQUAL: zero_extend([r152:DI])
>    40 pc={(r78:DI==0x0)?L230:pc}
>       REG_BR_PROB: 0x1388
> 
> The proposed change removes REG_EQUAL note only on moved insn, (insn 538) in
> our case.

That's too aggressive in the general case, no need to remove a REG_EQUAL note
pointing to a constant if the SRC is also function_invariant_p.  An acceptable
compromise could be to remove the note only if its content is also not itself
function_invariant_p.


-- 


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