Message ID | 1448297620.19594.168.camel@surprise |
---|---|
State | New |
Headers | show |
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. > diff --git a/gcc/tree.def b/gcc/tree.def > index 44e5a5e..30fd766 100644 > --- a/gcc/tree.def > +++ b/gcc/tree.def > @@ -1407,6 +1407,13 @@ DEFTREECODE (CILK_SPAWN_STMT, "cilk_spawn_stmt", tcc_statement, 1) > /* Cilk Sync statement: Does not have any operands. */ > DEFTREECODE (CILK_SYNC_STMT, "cilk_sync_stmt", tcc_statement, 0) > > +/* Wrapper to add a source code location to an expression, either one > + that doesn't have one (such as an INTEGER_CST), or to a usage of a > + variable (e.g. PARAM_DECL or VAR_DECL), where we want to record > + the site in the source where the variable was *used* rather than > + where it was declared. */ > +DEFTREECODE (LOCATION_EXPR, "location_expr", tcc_unary, 1) > + > /* > Local variables: > mode:c Jakub
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. Marek
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. Jason
On Mon, Nov 23, 2015 at 8:25 PM, Jason Merrill <jason@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 > >
diff --git a/gcc/tree.def b/gcc/tree.def index 44e5a5e..30fd766 100644 --- a/gcc/tree.def +++ b/gcc/tree.def @@ -1407,6 +1407,13 @@ DEFTREECODE (CILK_SPAWN_STMT, "cilk_spawn_stmt", tcc_statement, 1) /* Cilk Sync statement: Does not have any operands. */ DEFTREECODE (CILK_SYNC_STMT, "cilk_sync_stmt", tcc_statement, 0) +/* Wrapper to add a source code location to an expression, either one + that doesn't have one (such as an INTEGER_CST), or to a usage of a + variable (e.g. PARAM_DECL or VAR_DECL), where we want to record + the site in the source where the variable was *used* rather than + where it was declared. */ +DEFTREECODE (LOCATION_EXPR, "location_expr", tcc_unary, 1) + /* Local variables: mode:c