[Bug rtl-optimization/63823] [5.0 Regression] MIPS will not build due to LRA ICE with 64 bit ABI

["vmakarov at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63823

--- Comment #6 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to Robert Suchanek from comment #5)
> It appears that enabling the debug info can trigger the ICE. In the
> testcase, after the patch, an instruction 1136 gets deleted and all
> references to pseudo 704 meant to be updated.
> 
> The following change in process_bb_lives () triggers the assertion later in
> the pass.
> 
> +             EXECUTE_IF_SET_IN_BITMAP
> +               (&lra_reg_info[dst_regno].insn_bitmap, 0, uid, bi)
> +               {
> +                 insn = lra_insn_recog_data[uid]->insn;
> +                 lra_substitute_pseudo_within_insn (insn, dst_regno,
> +                                                    SET_SRC (set));
> +                 lra_update_insn_regno_info (insn);
> +               }
> 
> On the first iteration, the list of insns using pseudo 704 is correct:
> 
> (gdb) call debug_bitmap(&lra_reg_info[704].insn_bitmap)
> 
> first = 0x188b720 current = 0x188b770 indx = 3
>         0x188b720 next = 0x188b770 prev = (nil) indx = 2
>                 bits = { 343 }
>         0x188b770 next = (nil) prev = 0x188b720 indx = 3
>                 bits = { 384 }
> 
> Insn 343 gets updated, pseudo 704 is replaced with original pseudo 234.
> However, the call to lra_update_insn_regno_info destroys the remaining
> references to pseudo 704 via invalidate_insn_data_regno_info so we end up
> with the following:
> 
> (gdb) call debug_bitmap(&lra_reg_info[704].insn_bitmap)
>                                                        
> first = 0x1855770 current = 0x1855770 indx = 3         
>         0x1855770 next = (nil) prev = (nil) indx = 3   
>                 bits = { 384 }
> 
> The next iteration(s) in EXECUTE_IF_SET_IN_BITMAP will not happen as
> bmp_iter_set () returns false. Insn 384 is left unchanged and the compiler
> fails later on assertion.

Thanks for analyzing this, Robert.  I've been working on some LRA
rematerialization issues and found this too.  I'll post a patch fixing this
issue soon.  If it works for you, I'll commit it on this week.