From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24894 invoked by alias); 17 Oct 2004 19:46:16 -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 24887 invoked from network); 17 Oct 2004 19:46:15 -0000 Received: from unknown (HELO atrey.karlin.mff.cuni.cz) (195.113.31.123) by sourceware.org with SMTP; 17 Oct 2004 19:46:15 -0000 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 29025) id 0D0244B412D; Sun, 17 Oct 2004 21:46:15 +0200 (CEST) Date: Sun, 17 Oct 2004 19:48:00 -0000 From: Zdenek Dvorak To: Richard Kenner Cc: gcc-patches@gcc.gnu.org Subject: Re: [patch] for PR 18040 Message-ID: <20041017194615.GA23959@atrey.karlin.mff.cuni.cz> References: <10410171944.AA00989@vlsi1.ultra.nyu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10410171944.AA00989@vlsi1.ultra.nyu.edu> User-Agent: Mutt/1.5.6i X-SW-Source: 2004-10/txt/msg01403.txt.bz2 Hello, > is_gimple_addressable uses handled_component_p to determine whether its > operand is a component reference. However handled_component_p allows > also NOP_EXPRs and CONVERT_EXPRs. This in turn makes SRA believe that > ((cast) var).field is valid gimple (since "(cast) var" passes > is_gimple_addressable), which causes crash later. > > Can you explain this more? I very much think it's going in the wrong > direction to not use handled_component_p. If we don't want to view a > an expression as being a component that's handled, we should change > handled_component_p. But right now, what you show above in valid GIMPLE. > Perhaps there's a bug elsewehre. no, it is not valid gimple, since it does not match grammar as described in documentation. Also considering "(cast) something" to be addressable is a bit weird by itself. Of course feel free to propose to extend gimple for this if you think it would be useful; handling the no-op casts in addresses would not be a problem from optimizations point of view. Zdenek