On Tue, Sep 15, 2015 at 12:20 PM, Jakub Jelinek <ja...@redhat.com> 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 : 1; >> > /* The location at which this token was found. */ >> > location_t location; >> > + /* The source range at which this token was found. */ >> > + source_range range; >> >> Is it just me or does location now feel somewhat redundant with range? >> Can't we >> compress that somehow? > > For a token I'd expect it is redundant, I don't see how it would be useful > for a single preprocessing token to have more than start and end locations. > But generally, for expressions, 3 locations make sense. > If you have > abc + def > ~~~~^~~~~ > then having a range is useful. In any case, I'm surprised that the ranges > aren't encoded in > location_t (the data structures behind it, where we already stick also > BLOCK pointer).
Probably lack of encoding space ... I suppose upping location_t to 64bits coud solve some of that (with its own drawback on increasing size of core structures). Richard. > Jakub