This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only.

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!

Not anymore.

Instead it adds it to tree_exp and tree_decl.
Adding it to tree_exp on the mainline would also help solve Carlo's problem.

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?

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]