Re: [PATCH] New pragma handling mechanism.

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Fri, 15 Apr 2005, Mark Mitchell wrote:

> Dmitry Kurochkin wrote:
> > Mark, I think there are some issues with your approach.
> > 1. Some pragmas have language-dependent constructs. For example if
> > statements. They require different handlers or should be parsed by
> > each front end internally. I think the second one is a better variant.
> > 2. If we attach pragmas to statements, this will require extra
> > checking later. For example some pragmas require for statement, omp
> > atomic requires only i++, i--, etc. expressions.
> > If we handle them in front end, we know what should be the next statement.
> 
> I understand, but I think those are minor issues, and orthogonal.  The first
> issue is simply about the code that parses a partciular #pragma; if it has to
> be different, it has to be different, wehther or not there is a "struct
> pragma".  As for the second, you have to do the checking somewhere: either in
> the #pragma handler, where you issue an error if the right statement isn't
> found, or in the statement-parser if the wrong #pragma is present.

In practice I think this needs to be done in the statement parser, given 
that it depends on fine details of the syntax (e.g. absence of parentheses 
in certain cases) which aren't available after then.

The OpenMP specification describes the pragmas as syntactic constructs 
(openmp-directive and openmp-construct) that appear in the statement 
syntax, and which may contain the following statement, so I think there 
should be pragma parser functions, called when #pragma omp tokens are 
encountered, which parse both the pragma and the subsequent statement it 
affects as described in the grammar.

The pragma parsers need to know about the rest of the parser just to 
handle the #pragma line, since they need to parse expressions on that 
line.  Inside templates, this will be parsing those expressions just like 
other expressions in templates.

I think the present handling in the C++ front end (where a pragma which 
isn't ignored or handled by the preprocessor is a kind of statement or 
toplevel declaration handled in the token stream) is the right way to go 
about things - with the extension of allowing pragmas which are specified 
to involve subsequent statements to do so in their parsing.

Some OpenMP constructs are literally statements - those whose syntax is 
given as openmp-construct (and which contain statements themselves) - and 
as such can appear as immediate substatements in "if" statements, etc.; 
others (openmp-directive) are alternatives to declarations and statements 
inside compound statements, but may not appear in other places where 
statements are permitted.  These restrictions on which cases can appear 
where are naturally implemented in the parser, following the standard 
OpenMP syntax.

I don't see the advantages of separating the pragma handling from the 
parsing of statements which according to the specification are part of the 
same syntax production which starts with the #pragma.

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