From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7668 invoked by alias); 6 Oct 2003 17:41:00 -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 7652 invoked from network); 6 Oct 2003 17:40:58 -0000 Received: from unknown (HELO mx2.redhat.com) (66.187.237.31) by sources.redhat.com with SMTP; 6 Oct 2003 17:40:58 -0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.11.6/8.11.6) with ESMTP id h96HNQO13996; Mon, 6 Oct 2003 13:23:26 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h96HeuD29390; Mon, 6 Oct 2003 13:40:57 -0400 Received: from dot.sfbay.redhat.com (dot.sfbay.redhat.com [172.16.24.7]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h96Heuw26813; Mon, 6 Oct 2003 10:40:56 -0700 Received: (from rth@localhost) by dot.sfbay.redhat.com (8.11.6/8.11.6) id h96HesS17817; Mon, 6 Oct 2003 10:40:54 -0700 X-Authentication-Warning: dot.sfbay.redhat.com: rth set sender to rth@redhat.com using -f Date: Mon, 06 Oct 2003 17:41:00 -0000 From: Richard Henderson To: gcc@gcc.gnu.org, wilson@specifixinc.com, jason@redhat.com Subject: Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only. Message-ID: <20031006174054.GC17794@redhat.com> Mail-Followup-To: Richard Henderson , gcc@gcc.gnu.org, wilson@specifixinc.com, jason@redhat.com References: <20030922001710.GA24248@alinoe.com> <20030927124920.GA16447@alinoe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030927124920.GA16447@alinoe.com> User-Agent: Mutt/1.4i X-SW-Source: 2003-10/txt/msg00161.txt.bz2 On Sat, Sep 27, 2003 at 02:49:20PM +0200, Carlo Wood wrote: > But tree-ssa (3.5) even adds a location_t to tree_common! Not anymore. > A suggestion was to use expr wfl, but that is impractical: > there are too many places where an expressions type is directly > compared with CALL_EXPR (if (TREE_CODE (call) != CALL_EXPR)) - > all of those places would have to be changed to also check for > a EXPR_WITH_FILE_LOCATION that wraps a CALL_EXPR and then > unwrap the call expr in order to subsequentially be able to > process it. What leads you to believe that this is true? Why would not the WFL expr just go through expand_expr, and thence to expand_call? r~