This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [C++ PATCH] Improve location info [1/many]


On 08/12/2014 05:09 PM, Marek Polacek wrote:
Furthermore, the arguments should have their own locations in EXPR_LOCATION;
I don't think we need to track them separately.  If their locations are
wrong that's something to fix directly, rather than adding a special case
for function arguments.

So I think I'd like to drop the arg_loc/convert_like changes from this
The problem is that we can't set EXPR_LOCATION of neither integer_cst nor
declaration, because only EXPR_Ps can have locations.  That means setting
EXPR_LOCATIONS of argument here:
int i = 3;
foo (i);
wouldn't work (VAR_DECL), but here
int i = 3;
foo (-i);
it should (NEGATE_EXPR).  Bummer.  So I think we'll have to pursue something
else.  One possibility (and I think you mentioned this at Cauldron) would be to
create a new tree code, called e.g. LOCATION_EXPR.  This expr would wrap
a tcc_constant or a tcc_declaration, and add a location_t to it, thus something

struct GTY(()) tree_location_expr {
   struct tree_base base;
   location_t loc;
Would that make sense?
Lately I'm not spending much time on these issues, and I'm glad that you do, by the way, but I'm still under the impression that something like the above is necessary, for templates, for example. Today, however, I have a (new for me) thought: why wrapping ("somebody" also suggested a NOP_EXPR at some point ;) instead of simply changing integer_cst & co to natively have a location?!? Memory use will increase, that for sure, but maybe something can be optimized at an abstraction level lower than most normal uses, like, if the location is not set, share a node similar to current integer_cst, I'm sure a lot can be done in this area. However, most *uses* of the beefed up integer_cst would be straightforward, it will just become possible to store and fetch the location like for the other EXPRs, and there will be no risks of leaking into the middle-end new unhandled tree nodes.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]