From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11535 invoked by alias); 10 Jan 2008 23:59:12 -0000 Received: (qmail 11433 invoked by uid 48); 10 Jan 2008 23:58:30 -0000 Date: Fri, 11 Jan 2008 01:24:00 -0000 Message-ID: <20080110235830.11432.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug rtl-optimization/31944] [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit 2.6.20 kernel In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "steven at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2008-01/txt/msg00969.txt.bz2 ------- Comment #26 from steven at gcc dot gnu dot org 2008-01-10 23:58 ------- Mark, wrt. the release, I recommend this PR shouldn't be a blocker. The problem is old and is currently latent on the trunk, where it is only exposed with non-default options (-fno-inline-small-functions). Obviously, the problem is that the hash of reg 66 is changed after a hash table element is created for it in the bucket for the original hash. I have no idea yet whether this is expected, or if not, what is going wrong. Messing with CSE at this stage may be more dangerous than accepting the status quo. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944