On Mon, Nov 23, 2015 at 8:25 PM, Jason Merrill <ja...@redhat.com> wrote: > On 11/23/2015 12:07 PM, Marek Polacek wrote: >> >> On Mon, Nov 23, 2015 at 05:57:54PM +0100, Jakub Jelinek wrote: >>> >>> On Mon, Nov 23, 2015 at 11:53:40AM -0500, David Malcolm wrote: >>>> >>>> Does the following look like the kind of thing you had in mind? (just >>>> the tree.def part for now). Presumably usable for both lvalues and >>>> rvalues, where the thing it wraps is what's important. It merely exists >>>> to add an EXPR_LOCATION, for a usage of the wrapped thing. >>> >>> >>> Yes, but please see with Jason, Richard and perhaps others if they are ok >>> with that too before spending too much time in that direction. >>> All occurrences of it would have to be folded away during the >>> gimplification >>> at latest, this shouldn't be something we use in the middle-end. >> >> >> I'd expect LOCATION_EXPR be defined in c-family/c-common.def, not >> tree.def. >> And I'd think it shouldn't survive genericizing, thus never leak into the >> ME. > > > Makes sense.
OTOH then the FEs need to strip trees of it if they ever want to use sth from fold-const.c for example. NON_LVALUE_EXPR is not in c-family/c-common.def either... (and conveniently stripped with STRIP_NOPS and friends). Ok, I _would_ like to move NON_LVALUE_EXPR to the C frontend family as well... so I guess that would be a nice starting project and if you can make that work you can add LOCATION_EXPR to the C family only. Richard. > Jason > >
