On Tue, 12 Aug 2014, Jason Merrill wrote: > On 08/12/2014 11:09 AM, Marek Polacek wrote: > > One possibility (and I think you mentioned this at Cauldron) would be to > > create a new tree code, called e.g. LOCATION_EXPR. > > I don't think it needs a new code: I think we can use VIEW_CONVERT_EXPR for > decls and NOP_EXPR for constants. There will probably be some places in the > front end that need to learn to deal with VIEW_CONVERT_EXPR, though we already > use it a bit.
For C, it is definitely expected within the front end that anything that is an integer constant expression is an INTEGER_CST and that a NOP_EXPR wrapping an INTEGER_CST is something folded to an integer constant that is neither an integer constant expression nor can appear in one. (Something that is not an integer constant expression but can appear in an unevaluated part of one - 1 / 0, for example - is represented as a C_MAYBE_CONST_EXPR with C_MAYBE_CONST_EXPR_INT_OPERANDS set.) So to handle locations of constants like that for C, (a) you'd need a representation that doesn't conflict with marking something as not part of an integer constant expression, (b) you'd need to find all relevant checks for INTEGER_CST and make them allow the new form. (Much the same applies to null pointer constants - they are INTEGER_CSTs with integer or pointer type, and something folded to a null pointer but not a null pointer constant is represented differently.) -- Joseph S. Myers jos...@codesourcery.com
