This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
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)