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

[Manuel López-Ibáñez <lopezibanez at gmail dot com>]

> 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.)

Wouldn't the folding that already occurs in the FEs prevent this anyway?

At least last time that somebody tried to implement this, they gave up
on this possibility because of folding:
https://gcc.gnu.org/ml/gcc-patches/2012-09/msg01222.html

Cheers,

Manuel.