This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug bootstrap/59985] stage2/3 compare error on lto-streamer-in.o
- From: "vmakarov at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 30 Jan 2014 17:50:53 +0000
- Subject: [Bug bootstrap/59985] stage2/3 compare error on lto-streamer-in.o
- Auto-submitted: auto-generated
- References: <bug-59985-4 at http dot gcc dot gnu dot org/bugzilla/>
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.