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 to
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
+++ b/gcc/cp/parser.h
@@ -61,6
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 st
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 give
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 GENERIC we'd have to invent a
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 12:14:22PM +0200, Richa
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 a/gcc/cp/parser.h b/gcc/cp/
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 G
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 code to
> wrap such uses to be
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
--- a/gcc/cp/parser.h
++
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 purged_p
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
> >> > --- a/gcc/c
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 +61,8 @@ struct GTY ((
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
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 these are always just e
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
short-l
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 a
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 cpp_tok
18 matches
Mail list logo