This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Some (small) c++ compilation profiling data (oprofile)
On Tue, May 21, 2002 at 06:26:27PM +0100, Neil Booth wrote:
> Zack Weinberg wrote:-
>
> > But that's *not* the correct line/col info. We should be reporting
> > tokens from macro expansion as being located where the macro
> > definition was.
>
> Well, yes and no. I don't think people would be too impressed if
> the syntax errors from their 1000-line file were reported to have
> been in stdio.h because of some random macro they used.
>
> Really what we want is
>
> In file included from ... blah
> whilst expanding macro foo [if appropriate, with location]
> and then the error reported as now but pointing to the token in
> the #define.
Agreed.
> However, the information about the location of the original
> invocation is completely lost at the moment; cpplib would need
> to do a bit of book-keeping to retain it.
Should just be a case of adding a pointer to a linemap structure in
the macro context stack, right?
> What I am concerned about is how to maintain a smooth stream of
> tokens from cpplib to the front end. I think an array of token
> pointers is best (or, slightly worse, an array of tokens).
> The front end can then move around in this array freely (as can
> cpplib; removing the current restriction of not being able to
> back-up more than 1 token if a macro is involved) without the
> overhead the current parser has, and with some trivial book-
> keeping cpplib can determine the location of the original
> macro, if any, provided it's given a location in the array
> rather than a pointer to the token.
>
> Now, a cpp token is not enough for the front ends; they want
> to add a few bits (e.g. a tree). So maybe we want something
> like
>
> struct fe_token
> {
> tree *value;
> unsigned int index; /* In cpp_token array. With cpplib's
> help this is enough to determine
> where the original macro was, if
> any. The token itself contains
> the #define position. */
> };
>
> Do you see what I'm trying to get at? Do you have any better
> ideas?
Ah, yes, I get it now... that sounds good to me. I don't mean to rag
on your ideas; I've just been off in other parts of the compiler for
long enough that the issues are becoming fuzzy.
zw