[C++ Patch] PR 44516

Paolo Carlini paolo.carlini@oracle.com
Mon May 14 13:23:00 GMT 2012


Hi,

On 05/14/2012 05:58 AM, Jason Merrill wrote:
> On 05/13/2012 11:24 PM, Paolo Carlini wrote:
>>>>      tree r = build_x_modify_expr
>>>> -      (RECUR (TREE_OPERAND (t, 0)),
>>>> +      (input_location,
>>>
>>> And EXPR_LOC_OR_HERE (t).
>> Here I think EXPR_LOC_OR_HERE (TREE_OPERAND (t, 1)) is better.
>
> Why?  TREE_OPERAND (t,1) is a dummy tree that we only use for its code.
Ok... now I see.
> Of course, currently it doesn't matter because we don't 
> SET_EXPR_LOCATION on either the MODOP_EXPR or its operand 1, so 
> EXPR_LOC_OR_HERE on either one will give input_location.
Agreed.
> I guess we want a build_min_nt_loc function.
Indeed, and I can use it to handle the latter issue. I have a draft 
patch almost ready.

In terms of implementation details: the new _loc variant (I'm also 
finding useful a build_min_loc and a build_min_non_dep_loc, by the way) 
seems identical to the non-_loc variant besides calling 
SET_EXPR_LOCATION, thus I'm thinking: would it make sense to have the 
current non-_loc variants implemented in terms of the new ones and 
passing 0 as location_t and the _loc variant doing SET_EXPR_LOCATION (t, 
loc); only if loc != 0? Or we want to keep location_t opaque, I don't 
know, we want to do something slightly different?

Thanks,
Paolo.



More information about the Gcc-patches mailing list