From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-498479-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 32837 invoked by alias); 1 Oct 2015 12:51:06 -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 32789 invoked by uid 48); 1 Oct 2015 12:51:01 -0000
From: "bernd.edlinger at hotmail dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/67756] [6 Regression] ICE compiling Linux Kernel fs/namei.c on ARM
Date: Thu, 01 Oct 2015 12:51:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: bernd.edlinger at hotmail dot de
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 6.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-67756-4-A22C76ya4o@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67756-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67756-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: 2015-10/txt/msg00034.txt.bz2

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

--- Comment #11 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
I must admit, that I don't know what I am doing here,
... but this (completely untested) patch seems to fix the ICE:
(and at least my linux kernel compiles without ICE now)

--- lra-assigns.c.jj    2015-07-16 17:26:35.000000000 +0200
+++ lra-assigns.c       2015-10-01 14:40:06.262300720 +0200
@@ -576,7 +576,7 @@ find_hard_regno_for_1 (int regno, int *c
        /* Remember about multi-register pseudos.  For example, 2 hard
           register pseudos can start on the same hard register but can
           not start on HR and HR+1/HR-1.  */
-       for (hr = conflict_hr + 1;
+       for (hr = conflict_hr;
             hr < FIRST_PSEUDO_REGISTER && hr < conflict_hr + nregs;
             hr++)
          SET_HARD_REG_BIT (impossible_start_hard_regs, hr);



The problem starts when lra assigns r143 and r144 to r1
although both have obviously conflicting live ranges.