From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11638 invoked by alias); 16 Jan 2002 16:43:41 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 11560 invoked from network); 16 Jan 2002 16:43:38 -0000 Received: from unknown (HELO atrey.karlin.mff.cuni.cz) (195.113.31.123) by sources.redhat.com with SMTP; 16 Jan 2002 16:43:38 -0000 Received: (from hubicka@localhost) by atrey.karlin.mff.cuni.cz (8.9.3/8.9.3/Debian 8.9.3-21) id RAA16824; Wed, 16 Jan 2002 17:43:36 +0100 Date: Wed, 16 Jan 2002 08:53:00 -0000 From: Jan Hubicka To: John David Anglin Cc: gcc-bugs@gcc.gnu.org, jh@suse.cz, rth@redhat.com, gcc-patches@gcc.gnu.org Subject: Re: PATCH: Re: ICE in 920624-1.c with -O3 -funroll-loops on vax-dec-ultrix4.3 Message-ID: <20020116164336.GC14914@atrey.karlin.mff.cuni.cz> References: <200201152316.g0FNGFji010797@hiauly1.hia.nrc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200201152316.g0FNGFji010797@hiauly1.hia.nrc.ca> User-Agent: Mutt/1.3.24i X-SW-Source: 2002-01/txt/msg01169.txt.bz2 > > The ICE occurs in verify_flow_info when it encounters a barrier. It appears > > that case insn's are being incorrectly simplified in the cse2 pass. This > > is the rtl from loop: > > The ICE occurs because the original conditional jump gets converted to > an unconditional jump and a barrier is added after the jump. However, > the jump table data still remains in the rtl for the block. This > confuses the edge analysis into thinking that the block falls thru > and we have an inconsistent configuration. This is bit dangerous, as at some targets, the instructions to compute jump destination may remain in the insn stream until after liveness analysis that should zap them as dead. They should not reference deleted label, so maximally one can convert it into NOTE_INSN_DELETED_LABEL. My approach in the cfg is to keep the tables around and sweep them once done with CSE, but I guess it is easier to zap them to NOTE_INSN_DELETED_LABEL instead. I plan to do that move on the cfg branch. In your case all you need is to use delete_insn_chain for the two insns that cares to create the note instead. Honza > > This patch fixes the problem by deleting the jump table data when a > conditional or computed jump is converted to an unconditional jump. > I have verified that the patch fixes the original problem observed > under vax-dec-ultrix4.3. A new vax bootstrap is underway but it > won't finish until sometime next month. > > Bootstrap checked with no regressions on i686-pc-linux-gnu and > hppa2.0w-hp-hpux11.11. > > OK to install? > > Dave > -- > J. David Anglin dave.anglin@nrc.ca > National Research Council of Canada (613) 990-0752 (FAX: 952-6605) > > 2002-01-14 John David Anglin > > * cse.c (cse_insn): Delete jump table data when a conditional or > computed jump is converted to an unconditional jump. > > --- cse.c.orig Mon Jan 14 12:24:57 2002 > +++ cse.c Mon Jan 14 17:48:32 2002 > @@ -5767,9 +5767,19 @@ > be a conditional or computed branch. */ > else if (dest == pc_rtx && GET_CODE (src) == LABEL_REF) > { > - /* Now emit a BARRIER after the unconditional jump. */ > - if (NEXT_INSN (insn) == 0 > - || GET_CODE (NEXT_INSN (insn)) != BARRIER) > + rtx next = NEXT_INSN (insn); > + rtx tmp; > + > + /* Delete jump table data if present. */ > + if (next != NULL_RTX > + && LABEL_P (next) > + && (tmp = NEXT_INSN (next)) != NULL_RTX > + && JUMP_TABLE_DATA_P (tmp)) > + delete_insn (tmp); > + > + /* Now emit a BARRIER after the unconditional jump. */ > + if (next == NULL_RTX > + || GET_CODE (next) != BARRIER) > emit_barrier_after (insn); > > /* We reemit the jump in as many cases as possible just in