This is the mail archive of the gcc-patches@gcc.gnu.org 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: [gomp] Parser for OpenMP directives


On Thu, 31 Mar 2005, Dmitry Kurochkin wrote:

> On Wed, 30 Mar 2005 17:17:48 +0000 (UTC), Joseph S. Myers
> <joseph@codesourcery.com> wrote:
> > We currently have two different forms of pragma handling, deferred and
> > immediate.  In the latter case we can do macro expansion for pragmas
> > requiring it, but not in the former.  What I don't want is to have *three*
> > different forms of pragma handling.
> Maybe we can implement the third way of handling pragmas, then convert
> the C++ parser to use this way instead of deferred pragmas? After the
> deferred pragmas can be removed painlessly.

We have an incomplete transition already in progress; I don't like the 
compiler having another transition in the same area before the first is 
complete; I'd rather there were a maximum of two mechanisms in the 
compiler for handling pragmas at any one time.

> >  You could avoid this by moving C to
> > lex up front (so deferred pragmas are the only way) before changing the
> > tokens used, or you could implement the changed tokens at the same time
> > for both lexing up front and lexing a token at a time (with the necessary
> > changes to both C and C++ parsers to handle this), or you could implement
> > the changed tokens initially for deferred pragma handling only so they
> > would at first only be used for C++ and become available for C only later
> > when C changes to lexing up front.  In any case, these changes should be
> > made on mainline and then merged from there to gomp-branch.
> Sorry, I don't think I clearly understand what you mean by "lexing up
> front", "the tokens used" and "changed tokens". Can you please
> describe this in more details?

The C++ front end lexes the whole file into an array of tokens before 
starting parsing any of it, thereby improving performance over calling 
back into the lexer whenever a new token is needed.  Because pragmas are 
context-sensitive, their handlers need calling at the right point in 
parsing, so for C++ pragmas become single tokens in the token array and 
when these tokens are reached in parsing cpp_handle_deferred_pragma is 
called.  This makes c_lex start returning tokens from within the pragma so 
that target pragma handlers work; whereas in the C front end when a 
#pragma is encountered the pragma handler is called immediately and c_lex 
returns the tokens from the pragma while the rest of the source file 
hasn't been lexed at all.  The proposal is to change the C++ method from 
using a single token in the token array to represent the pragma to having 
a sequence of tokens representing the pragma.  You still need to arrange 
for c_lex, called from the target pragma handlers, to return those tokens 
(from the token array used in the C++ front end) one by one and then 
CPP_EOF at the end of the pragma, so that target pragma handlers continue 
to work.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    joseph@codesourcery.com (CodeSourcery mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)


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