This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]