From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-60787-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 20222 invoked by alias); 1 Oct 2002 11:23:10 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 20205 invoked from network); 1 Oct 2002 11:23:09 -0000
Received: from unknown (HELO nikam.ms.mff.cuni.cz) (195.113.18.106)
  by sources.redhat.com with SMTP; 1 Oct 2002 11:23:09 -0000
Received: from camelot.ms.mff.cuni.cz (kampanus.ms.mff.cuni.cz [195.113.18.107])
	by nikam.ms.mff.cuni.cz (Postfix) with SMTP
	id 9C27E4E2D8; Tue,  1 Oct 2002 13:23:09 +0200 (CEST)
Received: by camelot.ms.mff.cuni.cz (sSMTP sendmail emulation); Tue, 1 Oct 2002 13:23:08 +0200
Date: Tue, 01 Oct 2002 04:23:00 -0000
From: Jan Hubicka <jh@suse.cz>
To: Olivier Hainque <hainque@ACT-Europe.FR>
Cc: Michael Matz <matz@suse.de>, Jan Hubicka <jh@suse.cz>,
	gcc@gcc.gnu.org
Subject: Re: Question on fixup_abnormal_edges
Message-ID: <20021001112308.GQ29411@kam.mff.cuni.cz>
References: <Pine.LNX.4.33.0210011154390.22516-100000@wotan.suse.de> <Pine.LNX.4.33.0210011202140.22516-100000@wotan.suse.de> <20021001124034.A15939@berlin.int.act-europe.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20021001124034.A15939@berlin.int.act-europe.fr>
User-Agent: Mutt/1.3.28i
X-SW-Source: 2002-10/txt/msg00011.txt.bz2

> 
> Hello Michael,
> 
> Michael Matz wrote:
> > > It can happen.  The relevant sequence in 3.2 and HEAD branch reads as
> > 
> > Doh, in my local copy of 3.2 ;-)  But it's definitely in HEAD.
> 
>  Indeed. Thanks for your input.
> 
>  I had checked HEAD, but was mistakenly looking for an explicit test against
>  "e" and missed the change you mentioned.
> 
>  It did not help much, unfortunately, as we are getting there with the insn
>  below, which is not a USE :/
> 
>  (insn 2134 444 445 (set (reg:DI 22 $22)
>         (mem:DI (plus:DI (reg/f:DI 29 $29)
>                 (const_int 640 [0x280])) [48 S8 A64])) 244 {*movdi_nofix} (nil)
>     (nil))
> 
>  Humm...

I think we should make reload to recognize that given insn never
fallsthru and avoid it from generating such dead code.  Even in case of
USE it is wrong and here as well.  What is the last insn in the basic
block?

Honza
> 
> 
> 
>