From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27957 invoked by alias); 5 Feb 2002 12:46:49 -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 27834 invoked from network); 5 Feb 2002 12:46:39 -0000 Received: from unknown (HELO atrey.karlin.mff.cuni.cz) (195.113.31.123) by sources.redhat.com with SMTP; 5 Feb 2002 12:46:39 -0000 Received: (from hubicka@localhost) by atrey.karlin.mff.cuni.cz (8.9.3/8.9.3/Debian 8.9.3-21) id NAA27172; Tue, 5 Feb 2002 13:46:32 +0100 Date: Tue, 05 Feb 2002 07:34:00 -0000 From: Jan Hubicka To: law@redhat.com Cc: John David Anglin , rth@redhat.com, gcc-bugs@gcc.gnu.org, jh@suse.cz, gcc-patches@gcc.gnu.org Subject: Re: PATCH: Re: ICE in 920624-1.c with -O3 -funroll-loops on Message-ID: <20020205124632.GS17128@atrey.karlin.mff.cuni.cz> References: <200202050510.g155AIxr021739@hiauly1.hia.nrc.ca> <13971.1012890360@porcupine.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <13971.1012890360@porcupine.cygnus.com> User-Agent: Mutt/1.3.24i X-SW-Source: 2002-02/txt/msg00377.txt.bz2 > Furthermore, other insns don't reference the jump table -- they reference > the CODE_LABEL before the jump table. That's the whole point behind leaving > the CODE_LABEL in the insn stream. So I have a real hard time seeing why > it is unsafe to remove the jump table at the same time we convert its > associated tablejump/casesi into a simple jump. Because the label before jumptable is special by the fact that it is not in code segment for most cases. By removing the following jumptable you convert special code_label to not special code_label and create invalid CFG. Sick, I know. You must remove it and convert to NOTE_DELETED_LABEL as code labels other than tablejump are prohibited outside basic block. In case we keep the instructions to compute address in the stream by the accident, we result in accesing code segment for no putpose. > Before we switched to rely heavily on the cfg simplifier such cases were > caught and fixed by running the jump optimizer after any pass which might This is not correct - it is easy to construct testcases where the jumptable has been left in the stream with the old jump optimizer. THey has been removed just in "majority of cases". Honza