From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-466649-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 9831 invoked by alias); 13 Nov 2014 14:46:10 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Received: (qmail 9781 invoked by uid 48); 13 Nov 2014 14:46:07 -0000
From: "vmakarov at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/63823] [5.0 Regression] MIPS will not build due to LRA ICE with 64 bit ABI
Date: Thu, 13 Nov 2014 14:46:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: vmakarov at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63823-4-DZWj4Az8CO@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63823-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63823-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-11/txt/msg01121.txt.bz2

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.