[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