From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26997 invoked by alias); 29 Aug 2007 15:34:52 -0000 Received: (qmail 25436 invoked by alias); 29 Aug 2007 15:34:07 -0000 Date: Wed, 29 Aug 2007 15:34:00 -0000 Message-ID: <20070829153407.25434.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: gcc-bugs@gcc.gnu.org From: "zadeck at naturalbridge dot com" 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: 2007-08/txt/msg02178.txt.bz2 ------- Comment #30 from zadeck at naturalbridge dot com 2007-08-29 15:34 ------- Subject: Re: [4.3 Regression] ecj1 hangs bonzini at gnu dot org wrote: > ------- Comment #29 from bonzini at gnu dot org 2007-08-29 14:16 ------- > (When I said "post your first patch", I meant the first one from comment #26; > if my "fixing the mess" works, it'll not be necessary anymore). > > > For some reason, I was not copied on any of the postings for this patch until this morning. First, thankyou Jakub and Andreas for going this. I think that it is obvious that you have spotted the exact problem: in some way shape form of fashion, the artificial uses at the end of the block need to be re added into the live set after the processing of each insn in the block. There are two ways of doing this (assume that you have a local variable called artificial_uses_fixup which is a pointer to either df->eh_block_artificial_uses or df->regular_block_artificial_uses depending on if the block has eh preds) : 1) you can explicitly or artificial_uses_fixup into local_live after processing each insn. 2) you can test artificial_uses_fixup along with local_live when setting needed. As noted, (1) has the problem that may cause an infinite loop. This infinite loop could be fixed by changing the equation for block_changed to be !bitmap_equal (local_live, DF_LR_IN (BB) || artificial_uses_fixup) i.e. the infinite loop is because DF_LR_IN may be deficient in some of the bits in artificial_uses_fixup for basically the same reason that caused the bug in the first place. I personally think that solution (1) is preferable to (2) because it is fewer bitmap operations even though it will require a extra temp bitmap to hold the or. But either patch is a reasonable approach. As far as why there are all of the df_simulate functions that do things in different ways, the answer is that the code has evolved and sometimes things get missed. The addition of the df->eh_block_artificial_uses and df->regular_block_artificial_uses sets is fairly recent and it would most likely be useful to replace walks of artificial_uses with them. Kenny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32758