http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59985
--- Comment #12 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #11)
> --- gcc/lra-constraints.c.jj 2014-01-24 16:27:35.000000000 +0100
> +++ gcc/lra-constraints.c 2014-01-30 18:10:03.795737809 +0100
> @@ -4049,7 +4049,7 @@ lra_constraints (bool first_p)
> curr_insn = lra_pop_insn ();
> --new_min_len;
> curr_bb = BLOCK_FOR_INSN (curr_insn);
> - if (curr_bb != last_bb)
> + if (curr_bb != last_bb && !DEBUG_INSN_P (curr_insn))
> {
> last_bb = curr_bb;
> bb_reload_num = lra_curr_reload_num;
>
> seems to fix this. Vlad, what do you think about that?
> last_bb is only used to determine bb_reload_num computation, and
> bb_reload_num is only used in process_alt_operands which is called from
> curr_insn_transform and never called for DEBUG_INSNs, so in order to ensure
> that bb_reload_num is set the same, we shouldn't set it for DEBUG_INSN_Ps
> which will not appear without -g.
> And, DEBUG_INSN processing in lra_constraint I think shouldn't care about
> bb_reload_num value.
May be the patch fixes the testcase but in general it might now work as the
order of the insns on the stack sometimes might be different from the original
one. I'll try to make another patch.
