From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2816 invoked by alias); 13 May 2003 17:16:25 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 2713 invoked from network); 13 May 2003 17:16:24 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 13 May 2003 17:16:24 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h4DHGMH03502; Tue, 13 May 2003 13:16:22 -0400 Received: from speedy.slc.redhat.com (vpn50-15.rdu.redhat.com [172.16.50.15]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h4DHGKI20975; Tue, 13 May 2003 13:16:20 -0400 Received: from redhat.com (law@localhost) by speedy.slc.redhat.com (8.12.8/8.12.8/Submit) with ESMTP id h4DHGFDW012294; Tue, 13 May 2003 11:16:16 -0600 Message-Id: <200305131716.h4DHGFDW012294@speedy.slc.redhat.com> X-Authentication-Warning: speedy.slc.redhat.com: law owned process doing -bs To: Diego Novillo cc: Zack Weinberg , Michael Matz , "gcc@gcc.gnu.org" Reply-To: law@redhat.com Subject: Re: Dead-code elimination can't remove string copy insns? In-Reply-To: Your message of "Tue, 13 May 2003 13:07:22 EDT." <20030513170722.GA7112@tornado.toronto.redhat.com> From: law@redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 May 2003 17:16:00 -0000 X-SW-Source: 2003-05/txt/msg01332.txt.bz2 In message <20030513170722.GA7112@tornado.toronto.redhat.com>, Diego Novillo wr ites: >On Tue, May 13, 2003 at 09:40:33AM -0700, Zack Weinberg wrote: > >> gcc.dg/const-elim-1.c. On an x86, compile it with -march=i386 -O2; >> rs6000-ibm-aix5 and arm-elf also show the problem. >> >Yup, tree-ssa handles it. The original program in GIMPLE form is >on the left. The optimized version is on the right (we still >don't linearize GOTO_EXPRs). Err, we do zap GOTO_EXPRs to the next statement. See remove_useless_stmts_and_vars. It's restricted in that it can't deal with removal of a GOTO_EXPR when the label is at a different control nesting depth, but they're at the same nesting depth in your example. jeff