[Gomp-discuss] Re: Implementing OpenMP pragmas for the C front end

[Steven Bosscher]

Op vr 07-02-2003, om 23:51 schreef Neil Booth:
> Steven Bosscher wrote:-
> 
> > 1) How can we make sure that the OpenMP pragmas that require so are
> > always immediately followed by a compound statement?  The current plan
> > is to hook {push/pop}level and see if a COMPOUND_STMT is the first thing
> > following the #pragma.
> 
> This kind of thing is a dog with the current C parser.  With a recursive
> descent parser like Mark's or mine, it would simply be a matter of
> calling (umm, let's think of a name 8-)) c_parser_compound_statement
> after accepting the CPP_EOF indicating the end of the pragma.

That sounds much easier than the ideas I had for this with the current
yacc parser.

My idea was, when the parser sees a '{', the first thing it does is a
call to add_stmt (or c_begin_compound_stmt which is just a wrapper for
calls add_stmt, so not sure why it exists...).  When we hook add_stmt()
from c-openmp.c (the beginnings of that file already exist), we can just
check to see if the tree is a COMPOUND_STMT.

To see if a flush or barrier directive is allowed, we could inspect
last_tree from c-openmp.c when we parse such a directive...

Bit hackish maybe, but would it work?

> It's probably worth waiting for the new parser;

Not sure.  We now have the momentum, some people with good understanding
of the matter (Diego, Seb Pop) have already offered to work on GOMP.  I
would like to at least try to get those directives parsed with this
parser.  There are no other front ends we can start with.  OpenMP for C
is hard enough, C++ is much more difficult, and g95 is not even ready
yet to do just Fortran 95.

> I don't think we'll be using bison in 18 months time.

I sure you're right ;-)  Are you making good progress?

BTW Talking about parsers, is MAX_TREE_CODES from tree.h good for
anything? It's unused, but if 256 is a hard limit, then an Obj-C++ will
already almost hit it, with 246 codes in objc-tree.def, cp-tree.def,
c-common.def and tree.def together.  This was actually another concern I
had because we'll need a few new tree codes for OpenMP...

Greetz
Steven