This is the mail archive of the
mailing list for the GCC project.
Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only.
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Daniel Jacobowitz <drow at mvista dot com>
- Cc: gcc at gcc dot gnu dot org,Richard Henderson <rth at redhat dot com>
- Date: Mon, 6 Oct 2003 14:03:21 -0400
- Subject: Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only.
- References: <20030922001710.GA24248@alinoe.com> <20030927124920.GA16447@alinoe.com> <20031006174054.GC17794@redhat.com> <20031006175129.GA13871@nevyn.them.org>
On Oct 6, 2003, at 1:51 PM, Daniel Jacobowitz wrote:
On Mon, Oct 06, 2003 at 10:40:54AM -0700, Richard Henderson wrote:
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!
Instead it adds it to tree_exp and tree_decl.
Adding it to tree_exp on the mainline would also help solve Carlo's
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
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?
Well, wouldn't e.g. operand_equal_p need to handle
EXPR_WITH_FILE_LOCATION? I see lots of other places in the optimizers
with the same issue. Right now EXPR_WITH_FILE_LOCATION is only used to
wrap inline calls, as far as I can see. Even there I suspect it hurts
optimization because of this issue.
God i hated STRIP_WFL.
It was evil.