[PATCH 07/22] Implement token range tracking within libcpp and C/C++ FEs

Jeff Law law@redhat.com
Thu Sep 17 19:15:00 GMT 2015

On 09/17/2015 10:49 AM, David Malcolm wrote:

> FWIW, I have a (very messy) implementation of this working for the C
> frontend, which gives us source ranges on expressions without needing to
> add any new tree nodes, or add any fields to existing tree structs.
> The approach I'm using:
> * ranges are stored directly as fields within cpp_token and c_token
> (maybe we can ignore cp_token for now)
> * ranges are stashed in the C FE, both (a) within the "struct c_expr"
> and (b) within the location_t of each tree expression node as a new
> field in the adhoc map.
> Doing it twice may seem slightly redundant, but I think both are needed:
>    (a) doing it within c_expr allows us to support ranges for constants
> and VAR_DECL etc during parsing, without needing any kind of new tree
> wrapper node
>    (b) doing it in the ad-hoc map allows the ranges for expressions to
> survive the parse and be usable in diagnostics later.
> So this gives us (in the C FE): ranges for everything during parsing,
> and ranges for expressions afterwards, with no new tree nodes or new
> fields within tree nodes.
> I'm working on cleaning it up into a much more minimal set of patches
> that I hope are reviewable.
> Hopefully this sounds like a good approach
So is the assumption here that the location information is or is not 
supposed to survive through the gimple optimizers?   If I understand 
what you're doing correctly, I think the location information gets 
invalidated by const/copy propagations.

Though perhaps that's not a major problem because we're typically 
propagating an SSA_NAME, not a _DECL node.  Hmm.


More information about the Gcc-patches mailing list