From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22165 invoked by alias); 22 Feb 2005 00:19:30 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 22125 invoked from network); 22 Feb 2005 00:19:25 -0000 Received: from unknown (HELO dberlin.org) (68.164.203.246) by sourceware.org with SMTP; 22 Feb 2005 00:19:25 -0000 Received: from [127.0.0.1] (HELO localhost) by dberlin.org (CommuniGate Pro SMTP 4.2.8) with ESMTP id 7732607; Mon, 21 Feb 2005 19:19:24 -0500 Subject: Re: [Bug tree-optimization/20134] New: 176.gcc miscompare with -m64 after DOM change From: Daniel Berlin To: gcc-bugzilla@gcc.gnu.org Cc: gcc-bugs@gcc.gnu.org In-Reply-To: <20050222001243.20134.janis@gcc.gnu.org> References: <20050222001243.20134.janis@gcc.gnu.org> Content-Type: text/plain Date: Tue, 22 Feb 2005 08:02:00 -0000 Message-Id: <1109031561.28140.5.camel@linux.site> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2005-02/txt/msg02568.txt.bz2 List-Id: On Tue, 2005-02-22 at 00:12 +0000, janis at gcc dot gnu dot org wrote: > The SPEC CPU2000 test 176.gcc has been failing on powerpc64-*-linux-gnu > with "-m64 -O1" since this patch was added: > > > 2004-10-23 Daniel Berlin > > > * tree-ssa-dom.c (record_equality): Use loop depth to determine > which way to record the equality as well. > (loop_depth_of_name): New function. > This can't be the real cause of the problem, however, it must just be exposing the latent bug. It just changes the direction we record the equality, so that we will use one variable instead of another. The code still believes both variables to be equal. In other words, there is something in record_equality that isn't correct, or some pass later on is now doing something wrong as a result. Can you print out the values of x, y, and prev_x we are passing to record_const_or_copy_1 in record_equality before and after the patch, for that function?