From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27066 invoked by alias); 29 Aug 2007 12:15:46 -0000 Received: (qmail 26957 invoked by alias); 29 Aug 2007 12:15:45 -0000 Date: Wed, 29 Aug 2007 12:15:00 -0000 Message-ID: <20070829121545.26956.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug middle-end/32758] [4.3 Regression] ecj1 hangs In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: java-prs@gcc.gnu.org From: "paolo dot bonzini at lu dot unisi dot ch" Mailing-List: contact java-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-prs-owner@gcc.gnu.org X-SW-Source: 2007-q3/txt/msg00140.txt.bz2 ------- Comment #24 from paolo dot bonzini at lu dot unisi dot ch 2007-08-29 12:15 ------- Subject: Re: [4.3 Regression] ecj1 hangs > Here is what I will try to regtest (already verified it fixes the testcase). This is wrong, because local_live changes during execution of dce_process_block. The {eh,regular}_block_artificial_uses must always be set (they are live throughout, not just at the bottom of the basic block). > Alternatively, artificial_live could be a pointer bitmap which would just > point to one of the &df->*_block_artificial_uses bitmap, though not sure > if that ever could or in some register that wasn't originally set in > local_live. Much better, and would have the same effect as dce_simulate_fixup_sets. > Certainly calling df_has_eh_preds just once per bb rather than per insn is IMHO > worthwhile. A patch to do so if preapproved if you add a comment saying /* Calling df_simulate_fixup_sets has the disadvantage of calling df_has_eh_preds once per insn, so we cache the information here. */ before the place where you set artificial_live. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32758