This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Add extra location information - PR43486
- From: Ian Lance Taylor <iant at google dot com>
- To: Arnaud Charlet <charlet at adacore dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Jason Merrill <jason at redhat dot com>, Joseph Myers <joseph at codesourcery dot com>, Aldy Hernandez <aldyh at redhat dot com>, lopezibanez at gmail dot com
- Date: Tue, 18 Sep 2012 10:49:15 -0700
- Subject: Re: [PATCH] Add extra location information - PR43486
- References: <20120918105831.GA15097@adacore.com>
On Tue, Sep 18, 2012 at 3:58 AM, Arnaud Charlet <charlet@adacore.com> wrote:
>
> Since this issue is more general, I have split my changes and introduced a new
> tentative switch called -fextra-slocs, which is the subject of this email.
Sorry for picking on simple stuff, but the switch name seems
meaningless, and there isn't any documentation.
Conceptually it looks like you are trying to make up for the absence
of a proper AST by building an on-the-side hash table to track
expression locations. The hash table key is the tree structure
itself. The thing is, any call into fold-const may give you an
entirely new tree, and at that point you have lost your extra location
information. And the C/C++ frontends call into fold-const regularly,
which is why we don't have a proper AST in the first place. So it
seems to me that this is going to be kind of frustrating, in that we
will often have the extra location information but sometimes we won't.
And whether we have it or not will change as the frontends change.
So while a proper AST would be nice, I'm not convinced that this is
the right workaround. Another approach might be to tie this to the
location information, because the location information does generally
survive fold-const. E.g., perhaps we could grab a bit in the location
information to mean that it is special. And we could keep an
on-the-side hash table mapping special location values to additional
location information.
Ian