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

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

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

On Thu, 2015-09-17 at 13:14 -0600, Jeff Law wrote: > 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

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

On 09/15/2015 06:18 AM, Richard Biener wrote: Of course this boils down to "uses" of a VAR_DECL using the shared tree node. On GIMPLE some stmt kinds have separate locations for each operand (PHI nodes), on GENERIC we'd have to invent a no-op expr tree code to wrap such uses to be able to

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

On 09/15/2015 06:54 AM, Manuel López-Ibáñez wrote: On 15 September 2015 at 14:18, Richard Biener wrote: Of course this boils down to "uses" of a VAR_DECL using the shared tree node. On GIMPLE some stmt kinds have separate locations for each operand (PHI nodes), on

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

On 09/15/2015 04:33 AM, Richard Biener wrote: On Tue, Sep 15, 2015 at 12:20 PM, Jakub Jelinek wrote: On Tue, Sep 15, 2015 at 12:14:22PM +0200, Richard Biener wrote: diff --git a/gcc/cp/parser.h b/gcc/cp/parser.h index 760467c..c7558a0 100644 --- a/gcc/cp/parser.h +++

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

On Wed, 2015-09-16 at 16:21 -0400, David Malcolm wrote: > On Tue, 2015-09-15 at 12:48 +0200, Jakub Jelinek wrote: > > On Tue, Sep 15, 2015 at 12:33:58PM +0200, Richard Biener wrote: > > > On Tue, Sep 15, 2015 at 12:20 PM, Jakub Jelinek wrote: > > > > On Tue, Sep 15, 2015 at

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

On Tue, 2015-09-15 at 12:48 +0200, Jakub Jelinek wrote: > On Tue, Sep 15, 2015 at 12:33:58PM +0200, Richard Biener wrote: > > On Tue, Sep 15, 2015 at 12:20 PM, Jakub Jelinek wrote: > > > On Tue, Sep 15, 2015 at 12:14:22PM +0200, Richard Biener wrote: > > >> > diff --git

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

On Thu, Sep 10, 2015 at 10:28 PM, David Malcolm wrote: > This patch adds source *range* information to libcpp's cpp_token, and to > c_token and cp_token in the C and C++ frontends respectively. > > To minimize churn, I kept the existing location_t fields, though in > theory

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

On Tue, Sep 15, 2015 at 12:20 PM, Jakub Jelinek wrote: > On Tue, Sep 15, 2015 at 12:14:22PM +0200, Richard Biener wrote: >> > diff --git a/gcc/cp/parser.h b/gcc/cp/parser.h >> > index 760467c..c7558a0 100644 >> > --- a/gcc/cp/parser.h >> > +++ b/gcc/cp/parser.h >> > @@ -61,6

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

On 15/09/15 12:20, Jakub Jelinek wrote: On Tue, Sep 15, 2015 at 12:14:22PM +0200, Richard Biener wrote: diff --git a/gcc/cp/parser.h b/gcc/cp/parser.h index 760467c..c7558a0 100644 --- a/gcc/cp/parser.h +++ b/gcc/cp/parser.h @@ -61,6 +61,8 @@ struct GTY (()) cp_token { BOOL_BITFIELD

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

On Tue, Sep 15, 2015 at 2:08 PM, Manuel López-Ibáñez wrote: > On 15/09/15 12:20, Jakub Jelinek wrote: >> >> On Tue, Sep 15, 2015 at 12:14:22PM +0200, Richard Biener wrote: diff --git a/gcc/cp/parser.h b/gcc/cp/parser.h index 760467c..c7558a0 100644 ---

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

On Tue, Sep 15, 2015 at 12:14:22PM +0200, Richard Biener wrote: > > diff --git a/gcc/cp/parser.h b/gcc/cp/parser.h > > index 760467c..c7558a0 100644 > > --- a/gcc/cp/parser.h > > +++ b/gcc/cp/parser.h > > @@ -61,6 +61,8 @@ struct GTY (()) cp_token { > >BOOL_BITFIELD purged_p : 1; > >/* The

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

On Tue, Sep 15, 2015 at 12:33:58PM +0200, Richard Biener wrote: > On Tue, Sep 15, 2015 at 12:20 PM, Jakub Jelinek wrote: > > On Tue, Sep 15, 2015 at 12:14:22PM +0200, Richard Biener wrote: > >> > diff --git a/gcc/cp/parser.h b/gcc/cp/parser.h > >> > index 760467c..c7558a0 100644

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

On Tue, 2015-09-15 at 12:20 +0200, Jakub Jelinek wrote: > On Tue, Sep 15, 2015 at 12:14:22PM +0200, Richard Biener wrote: > > > diff --git a/gcc/cp/parser.h b/gcc/cp/parser.h > > > index 760467c..c7558a0 100644 > > > --- a/gcc/cp/parser.h > > > +++ b/gcc/cp/parser.h > > > @@ -61,6 +61,8 @@ struct

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

On 15 September 2015 at 14:18, Richard Biener wrote: > Of course this boils down to "uses" of a VAR_DECL using the shared tree > node. On GIMPLE some stmt kinds have separate locations for each operand > (PHI nodes), on GENERIC we'd have to invent a no-op expr tree

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

On 09/11/2015 07:55 AM, Michael Matz wrote: Hi, On Thu, 10 Sep 2015, David Malcolm wrote: Does anyone know why this was "carefully packed" and to what extent this matters? I'm adding an extra 8 bytes to it (or 4 if we eliminate the existing location_t). As far as I can see, these are

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

Hi, On Thu, 10 Sep 2015, David Malcolm wrote: > Does anyone know why this was "carefully packed" and to what extent > this matters? I'm adding an extra 8 bytes to it (or 4 if we eliminate > the existing location_t). As far as I can see, these are > short-lived, and there are only relative few

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

This patch adds source *range* information to libcpp's cpp_token, and to c_token and cp_token in the C and C++ frontends respectively. To minimize churn, I kept the existing location_t fields, though in theory these are always just equal to the start of the source range. cpplib.h's struct