Implementing OpenMP pragmas for the C front end

Implementing OpenMP pragmas for the C front end

[Steven Bosscher]

Hi,

Over the past few days we've had an interesting discussion in the GOMP
project mailing list about implementing the OpenMP directives and
constructs (#pragma omp) in the C front end.  

The issue is that the OpenMP pragmas are quite different from the
pragmas GCC currently supports.

GCC right now only has pragmas that do not put restrictions on the
language elements surrounding the pragmas.  AFAICT most pragmas have
their effect over the whole translation unit.

Pragmas are registered in cpplib with a handler that is called from
cpplib.  So the lexer and parser never see the pragmas. This makes it a
bit difficult to have elaborate interaction between the parser and the
pragma handlers.  There are additional callbacks for most pragmas from
c-decl (the maybe_apply_{weak,renaming_pragma} functions) because the
compiler may encounted symbols that are affected by those pragmas long
after the pragma itself was handled.

In OpenMP, the pragmas are more like grammar productions.  Certain
pragmas can only be followed or by a compound statement, some other
pragmas can only appear inside a compound.  Some constructs need
information about scope and/or about how deep they're nested.

In fact, the OpenMP specifications present the OpenMP pragmas as grammar
extensions for C/C++!

To give you an idea of how C syntax and OpenMP pragmas (don't) always go
together, here's an example from the OpenMP 2.0 specs for C/C++),
----------
/* ERROR - The flush directive cannot be the immediate
 * substatement of an if statement. */
if (x!=0)
  #pragma omp flush (x)
...

/* OK - The flush directive is enclosed in a * compound statement */
if (x!=0)
  {
    #pragma omp flush (x)
  }
----------

Another example: In a sections construct, all section directives must be
in the lexical extend of a sections construct:
----------
#pragma omp sections [clause[[,] clause] ...] new-line
  {
    [#pragma omp section new-line]
    structured-block

    #pragma omp section new-line
    structured-block
    ...
  }

/* ERROR - The section directive is not in the lexical extend of the
 * sections construct.  */
#pragma omp section new-line
structured-block 
----------


Actually parsing the pragmas is of course quite easy.  Making sure they
appear in a legal context is not, so that's what the discussion on the
GOMP list focussed on.

We considered callbacks and I've tried to play with that a bit.  It
seems we would at least need callbacks from start_decl() and add_stmt()
and we need a way to keep track of the current binding level.  I have
not yet found a way to enforce that the barrier and flush directives
only appear where they're allowed to; haven't looked into that much yet,
really.

(For those of you who're interested, here's the piece of the grammar
extensions from the OpenMP specs for the flush and barrier directives:

block-item:
	  declaration
	| statement
	| openmp-directive
	;

openmp-directive:
	  barrier-directive
	| flush-directive
	;

The complete "grammar extension" is 6 pages in the OpenMP 2.0 specs.)


But I don't like all the callbacks much.  It may clutter the code for
people who don't care about OpenMP, and it is more prone to errors than
I would like (it's so easy to overlook something in the parser...). 
Obviously, we would like to keep the changes to existing front end files
small.

So I would like to ask for some input from people who know the C front
end better than most of us un the GOMP project do.  To give you an idea
of the questions we're trying to find answers to, here are two of them:

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.

2) How can we make sure all "section" directives are in the lexical
extend of a "sections" construct?  No clue of how to do that.

Other suggestions/ideas/insights are very welcome too, of course ;-)

We have already looked at the Open64 C/C++ front ends, which are just
the "GCC 2.96" experimental front ends.  Unfortunately it looks like
they haven't implemented it there yet.

Greetz
Steven

Re: Implementing OpenMP pragmas for the C front end

[Neil Booth]

Steven Bosscher wrote:-

> GCC right now only has pragmas that do not put restrictions on the
> language elements surrounding the pragmas.  AFAICT most pragmas have
> their effect over the whole translation unit.

Right.  Really, for things like expressions (possibly functions,
depending on your IR) that are affected by C99 pragmas, there really
needs to be bits on their representation that gives the state of said
pragmas at that time in the soure file.  It isn't hard to do I think.

> ----------
> /* ERROR - The flush directive cannot be the immediate
>  * substatement of an if statement. */
> if (x!=0)
>   #pragma omp flush (x)

Surely not.  I think this is a *really really* bad idea; I wouldn't
support it going into GCC.  It's simply not the way C and C++ work.

> if (x!=0)
>   {
>     #pragma omp flush (x)
>   }

Ugh.  Which @#$&*( thought of this?

Neil.

Re: Implementing OpenMP pragmas for the C front end

[David Edelsohn]

>>>>> Neil Booth writes:

>> ----------
>> /* ERROR - The flush directive cannot be the immediate
>> * substatement of an if statement. */
>> if (x!=0)
>> #pragma omp flush (x)

Neil> Surely not.  I think this is a *really really* bad idea; I wouldn't
Neil> support it going into GCC.  It's simply not the way C and C++ work.

	Unfortunately, this is a public standard.  Somehow we need to be
compatible. 

	What we really want is some way of converting

#pragma omp flush (x)

to

__builtin_omp_flush (x);

which is a more natural way of implementing this and would allow semantic
error checking.

David

Re: Implementing OpenMP pragmas for the C front end

[Neil Booth]

David Edelsohn wrote:-

> 	Unfortunately, this is a public standard.  Somehow we need to be
> compatible. 
> 
> 	What we really want is some way of converting
> 
> #pragma omp flush (x)
> 
> to
> 
> __builtin_omp_flush (x);
> 
> which is a more natural way of implementing this and would allow semantic
> error checking.

On second thoughts it's possibly not as bad as I thought.  I had in mind
that the #pragma callbacks would be conditional on parser state; of
course that needn't be the implementation.  The callbacks should happen
regardless, and the front end should ignore/reject appropriately.

Neil.

Re: Implementing OpenMP pragmas for the C front end

[Neil Booth]

Steven Bosscher wrote:-

> But I don't like all the callbacks much.  It may clutter the code for
> people who don't care about OpenMP, and it is more prone to errors than
> I would like (it's so easy to overlook something in the parser...). 

From your post it appears that the pragmas all share a namespace.  That
namespace need only be registered when the relevant command-line flag
is given.  All those pragmas could be implemented in a separate file,
say c-omp.c.  I don't see why it should clutter or slow down the rest
of the compiler if done like that.

Neil.

Re: Implementing OpenMP pragmas for the C front end

[Geoff Keating]

Neil Booth <neil@daikokuya.co.uk> writes:

> David Edelsohn wrote:-
> 
> > 	Unfortunately, this is a public standard.  Somehow we need to be
> > compatible. 
> > 
> > 	What we really want is some way of converting
> > 
> > #pragma omp flush (x)
> > 
> > to
> > 
> > __builtin_omp_flush (x);
> > 
> > which is a more natural way of implementing this and would allow semantic
> > error checking.
> 
> On second thoughts it's possibly not as bad as I thought.  I had in mind
> that the #pragma callbacks would be conditional on parser state; of
> course that needn't be the implementation.  The callbacks should happen
> regardless, and the front end should ignore/reject appropriately.

All you really want is a way for the #pragma callback to respond with
"please pass #pragma to the parser as a token"; then the parser can
handle it.

[Mind, I'm a bit worried about what this might make the parser look
like; maybe we would really prefer to use another preprocessor before
the code actually gets to the compiler, not try to handle the pragmas
in the compiler itself.]

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Implementing OpenMP pragmas for the C front end

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

It's probably worth waiting for the new parser; I don't think we'll be
using bison in 18 months time.

Neil.

Re: Implementing OpenMP pragmas for the C front end

[Steven Bosscher]

Op vr 07-02-2003, om 23:18 schreef Neil Booth:
> Steven Bosscher wrote:-
> 
> > GCC right now only has pragmas that do not put restrictions on the
> > language elements surrounding the pragmas.  AFAICT most pragmas have
> > their effect over the whole translation unit.
> 
> Right.  Really, for things like expressions (possibly functions,
> depending on your IR) that are affected by C99 pragmas, there really
> needs to be bits on their representation that gives the state of said
> pragmas at that time in the soure file.  It isn't hard to do I think.
> 
> > ----------
> > /* ERROR - The flush directive cannot be the immediate
> >  * substatement of an if statement. */
> > if (x!=0)
> >   #pragma omp flush (x)
> 
> Surely not.  I think this is a *really really* bad idea; I wouldn't
> support it going into GCC.  It's simply not the way C and C++ work.
> 
> > if (x!=0)
> >   {
> >     #pragma omp flush (x)
> >   }
> 
> Ugh.  Which @#$&*( thought of this?
> 

Ehhr... This was copied verbatim from the OpenMP 2.0 specs for C/C++ :-)

Greetz
Steevn

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

[Scott Robert Ladd]

Steven Bosscher and Neil Booth have written:

SB> ----------
SB> /* ERROR - The flush directive cannot be the immediate
SB>  * substatement of an if statement. */
SB> if (x!=0)
SB>   #pragma omp flush (x)

NB> Surely not.  I think this is a *really really* bad idea; I
NB> wouldn't support it going into GCC.  It's simply not the way
NB> C and C++ work.

Well, this *is* the way OpenMP works. From the OpenMP standard for C and
C++:

[quote]
The directives, library functions, and environment variables defined in this
document will allow users to create and manage parallel programs while
permitting portability. The directives extend the C and C++ sequential
programming model with single program multiple data (SPMD) constructs,
work-sharing constructs, and synchronization constructs, and they provide
support for the sharing and privatization of data. Compilers that support
the OpenMP C and C++ API will include a command-line option to the compiler
that activates and allows interpretation of all OpenMP compiler directives.
[end quote]

I've always considered the OpenMP directives to be language extensions that
can be ignored by a compiler. Nothing in the C or C++ Standards prevents
pragmas from acting as do the ones defined by OpenMP. In Fortran, the OMP
directives exist as comments with a specific format.

SB> if (x!=0)
SB>   {
SB>     #pragma omp flush (x)
SB>   }

NB> Ugh.  Which @#$&*( thought of this?

A concept of OpenMP is that a program maintains its logic whether its is
compiled for serial or parallel execution. Thus the use of pragmas, which
can be ignored (or warned about) by any non-OpenMP compiler.

OpenMP is an outgrowth of an unfinished ANSI draft, X3H5. The OpenMP
Architecture Review Board is comprised of members from IBM, Sun, HP, Intel,
SGI, Fujitsu, and ASCI. No Microsoft, just as an interesting note. The
OpenMP Standard is implemented in C, C++, and Fortran compilers from these
companies.

..Scott

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

Re: Implementing OpenMP pragmas for the C front end

[Joseph S. Myers]

On Fri, 7 Feb 2003, Neil Booth wrote:

> 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.
> 
> It's probably worth waiting for the new parser; I don't think we'll be
> using bison in 18 months time.

When do we get a branch for the new parser?  (Or incremental improvements
that help the new parser on mainline, or a branch for particular such
improvements.  Cf <http://gcc.gnu.org/ml/gcc/2002-06/msg01467.html>:
incremental improvements should go on the mainline to avoid them getting
lost in the case of long delays.  Given a design similar to the C++ parser
- and simply trying to replace the parser, reusing working code, rather
than to redesign the world at once - I'd expect there should be various
opportunities for such cleanups.)  A branch doesn't require the code to
actually work.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Implementing OpenMP pragmas for the C front end

[Neil Booth]

Joseph S. Myers wrote:-

> When do we get a branch for the new parser?  (Or incremental improvements
> that help the new parser on mainline, or a branch for particular such
> improvements.  Cf <http://gcc.gnu.org/ml/gcc/2002-06/msg01467.html>:
> incremental improvements should go on the mainline to avoid them getting
> lost in the case of long delays.  Given a design similar to the C++ parser
> - and simply trying to replace the parser, reusing working code, rather
> than to redesign the world at once - I'd expect there should be various
> opportunities for such cleanups.)  A branch doesn't require the code to
> actually work.

I want to wait until I have something that actually parses most of C99.
Then it will be bug-fixing, doing the lowering stage, adding GNU
extensions and adding ObjC; which could be done in CVS.

It's going to be at least 3 months; more like 6.

Neil.

Re: Implementing OpenMP pragmas for the C front end

[Pop Sébastian]

On Fri, Feb 07, 2003 at 10:51:04PM +0000, Neil Booth wrote:
> 
> It's probably worth waiting for the new parser; I don't think we'll be
> using bison in 18 months time.
> 
Then we could focus our efforts on the C++ front-end that is ready.  
Once the C-fe will be rewritten in rd form, we'll port the OMP bits to C-fe.

Re: Implementing OpenMP pragmas for the C front end

[Joseph S. Myers]

On Sat, 8 Feb 2003, Neil Booth wrote:

> I want to wait until I have something that actually parses most of C99.
> Then it will be bug-fixing, doing the lowering stage, adding GNU
> extensions and adding ObjC; which could be done in CVS.

Do you have a design document - describing how it is similar to the C++
parser, how it differs, what existing code is reused, what is shared with
C++, what is adapted to the new parser structure (and whether any such
changes can be done incrementally), what is rewritten afresh (and
rationale for these choices), what intentional behaviour changes there are
(and whether these too can be done incrementally: if something becomes a
hard error, emit a mandatory deprecation warning now for 3.3 if the
information is now available in the present parser to do so), what new
features (if any) are to be implemented at the same time as the parser 
(and why at the same time rather than once the parser is in mainline 
making them easier to implement), what (apart from OpenMP discussed here) 
should be easier to implement once the new parser is in, ...?

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Implementing OpenMP pragmas for the C front end

[Neil Booth]

Joseph S. Myers wrote:-

> On Sat, 8 Feb 2003, Neil Booth wrote:
> 
> > I want to wait until I have something that actually parses most of C99.
> > Then it will be bug-fixing, doing the lowering stage, adding GNU
> > extensions and adding ObjC; which could be done in CVS.
> 
> Do you have a design document - describing how it is similar to the C++
> parser, how it differs, what existing code is reused, what is shared with
> C++, what is adapted to the new parser structure (and whether any such
> changes can be done incrementally), what is rewritten afresh (and
> rationale for these choices), what intentional behaviour changes there are
> (and whether these too can be done incrementally: if something becomes a
> hard error, emit a mandatory deprecation warning now for 3.3 if the
> information is now available in the present parser to do so), what new
> features (if any) are to be implemented at the same time as the parser 
> (and why at the same time rather than once the parser is in mainline 
> making them easier to implement), what (apart from OpenMP discussed here) 
> should be easier to implement once the new parser is in, ...?

Nope.

Neil.

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

[Scott Robert Ladd]

> Then we could focus our efforts on the C++ front-end that is ready.
> Once the C-fe will be rewritten in rd form, we'll port the OMP
> bits to C-fe.

I don't really see a problem with implementing for C++ and porting to C.

The only practical difference in OpenMP between C and C++ is in the
necessity for the latter to construct private objects via copy constructor
from the original object.

..Scott

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

[Steven Bosscher]

Op za 08-02-2003, om 14:09 schreef Scott Robert Ladd:
> > Then we could focus our efforts on the C++ front-end that is ready.
> > Once the C-fe will be rewritten in rd form, we'll port the OMP
> > bits to C-fe.
> 
> I don't really see a problem with implementing for C++ and porting to C.
> 
> The only practical difference in OpenMP between C and C++ is in the
> necessity for the latter to construct private objects via copy constructor
> from the original object.
> 

It's also very likely that people are more interested in OpenMP for C++
than for C.  I've never seen any serious numerical code in C, and lots
of them in C++.

OTOH, the First Principle in aeronautical engineering is "Don't put a
new airframe design around a new engine design", and I would think a
similair idea would apply to software engineering.  Maybe working on the
C++ parser on a subbranch of a branch, two steps away from the mailine
where all the patches for C++ are going to now, is not such a great
idea.

Note that C++ uses the same pragma handlers that C does (C++ uses
c-pragma.c).  Scott, did you find any differences in the
syntax/semantics of the OpenMP directives for C/C++?  If they are the
same, we would only need c-openmp.c, no need for a cp-open.mp.c :-)

Greetz
Steven

RE: [Gomp-discuss] Re: Implementing OpenMP pragmas for the Cfront end

[Scott Robert Ladd]

Steven Bosscher wrote:
> It's also very likely that people are more interested in OpenMP for C++
> than for C.  I've never seen any serious numerical code in C, and lots
> of them in C++.

That could very well change. C99 focused on numerical extensions; it is, in
some ways, superior to Fortran 95 for floating-point work. Many C99
extensions are incompatible with C++; see David Tribble's excellent site for
more detail:

http://david.tribble.com/text/cdiffs.htm

I've recently been experimenting with C99 numeric extensions, in conjunction
with OpenMP, using the Intel Linux compiler.

> Note that C++ uses the same pragma handlers that C does (C++ uses
> c-pragma.c).  Scott, did you find any differences in the
> syntax/semantics of the OpenMP directives for C/C++?  If they are the
> same, we would only need c-openmp.c, no need for a cp-open.mp.c :-)

That's what I was trying to convey in my earlier message: The OpenMP syntax
is identical for C and C++. The only differences I found involve additional
requirements in C++ due to the nature of objects (construction, destruction,
etc. for private objects)

..Scott

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

[Steven Bosscher]

Op za 08-02-2003, om 14:09 schreef Scott Robert Ladd:
> > Then we could focus our efforts on the C++ front-end that is ready.
> > Once the C-fe will be rewritten in rd form, we'll port the OMP
> > bits to C-fe.
> 
> I don't really see a problem with implementing for C++ and porting to C.
> 
> The only practical difference in OpenMP between C and C++ is in the
> necessity for the latter to construct private objects via copy constructor
> from the original object.
 
Do you think this difference is significant enough to justify splitting
up parsing and callbacks: Have a c-pragma-openmp.c which parses the
pragmas for C and C++, and have separate c-openmp.c and cp/cp-openmp.c
files to apply the pragmas and make sure we're in the right syntactic
context?

Greetz
Steven

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

[Per Bothner]

David Edelsohn wrote:
 > Unfortunately, this is a public standard.

There are all kinds of "public" standards.

 > Somehow we need to be compatible.

"We" only need to be compatible if we make
a comittment to implementing OpenMP.  I don't
think we should make any comittment to accepting
an OpenMP implementation in the offical CVS tree.

Of course I'm not suggesting that a technical
discussion about the best way to the implement
OpneMP in Gcc is inappropriate; but it should
not any support for the design.

Scott Robert Ladd wrote:

> A concept of OpenMP is that a program maintains its logic whether its is
> compiled for serial or parallel execution. Thus the use of pragmas, which
> can be ignored (or warned about) by any non-OpenMP compiler.

The "official" Gcc line has always been that #pragmas are
generally a bad idea.  A major reason is that #pragmas
cannot be created by macros.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

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

[Neil Booth]

Per Bothner wrote:-

> The "official" Gcc line has always been that #pragmas are
> generally a bad idea.  A major reason is that #pragmas
> cannot be created by macros.

They can in C99, with _Pragma.

Neil.

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

[Scott Robert Ladd]

Per Bothner wrote
> There are all kinds of "public" standards.

OpenMP is a 5-year-old standard now in its second revision; it is
implemented by most commercial compilers and has wide support in academia.
It provides a cross-platform, cross-language syntax for parallelization, and
is defined in such a way as to be non-intrusive for environments that do not
support threads and processes.

So OpenMP is not something new and untested. Surely the gcc developers can
match the technical acumen of their commercial counterparts?

> "We" only need to be compatible if we make
> a comittment to implementing OpenMP.  I don't
> think we should make any comittment to accepting
> an OpenMP implementation in the offical CVS tree.

I wouldn't expect anyone to make a commitment until the "GOMP" developers
have proven the concept in code. On the other hand, it is short-sighted to
dismiss OpenMP out-of-hand.

> The "official" Gcc line has always been that #pragmas are
> generally a bad idea.  A major reason is that #pragmas
> cannot be created by macros.

And many modern software developers consider #macros to be bad programming
practice. And many people consider language extensions to be bad. The list
goes on and on; gcc today is not the gcc of yesterday or tomorrow.
"Official" lines change.

I assume the "official" stance on gcc can continue to grow as the field of
computer programming evolves.

..Scott

--
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Professional programming for science and engineering;
Interesting and unusual bits of very free code.

Re: Implementing OpenMP pragmas for the C front end

[Zack Weinberg]

Steven Bosscher <s.bosscher@student.tudelft.nl> writes:

> Pragmas are registered in cpplib with a handler that is called from
> cpplib.  So the lexer and parser never see the pragmas. This makes it a
> bit difficult to have elaborate interaction between the parser and the
> pragma handlers.  There are additional callbacks for most pragmas from
> c-decl (the maybe_apply_{weak,renaming_pragma} functions) because the
> compiler may encounted symbols that are affected by those pragmas long
> after the pragma itself was handled.
>
> In OpenMP, the pragmas are more like grammar productions.  Certain
> pragmas can only be followed or by a compound statement, some other
> pragmas can only appear inside a compound.  Some constructs need
> information about scope and/or about how deep they're nested.
>
> In fact, the OpenMP specifications present the OpenMP pragmas as grammar
> extensions for C/C++!

Pragmas are callbacks only for historical reasons: It was easier to
implement them that way at the time.  With the C/C++ front ends moving
to recursive descent parsers, it would make perfect sense to put them
back in the token stream.  Perhaps we would transform

#pragma foo bar baz

into

__builtin_pragma foo bar baz;

and feed that to phase 7.

zw

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

[Neil Booth]

Andi Kleen wrote:-

> C99 fixed that with _Pragma() 
> 
> I'm not sure gcc supports that fully yet though.

It should be fine in 3.2.2 and 3.3.  3.2.1 (I think) had a bug;
3.0 may or may not have had it correct.

Neil.

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

[Andi Kleen]

Per Bothner <per@bothner.com> writes:
> 
> The "official" Gcc line has always been that #pragmas are
> generally a bad idea.  A major reason is that #pragmas
> cannot be created by macros.

C99 fixed that with _Pragma() 

I'm not sure gcc supports that fully yet though.

-Andi