Re: [PATCH] New pragma handling mechanism.

[Mark Mitchell <mark at codesourcery dot com>]

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.

> OpenMP pragmas are tight to the other code, so I think most of them
> should be parsed by front end and not by handlers. And if I'm not
> mistaking at present there are no other pragmas, that require such
> functionality, so the question is do we need it now?

Yes, that's RTH's sentiment as well.  My feeling is that the 
functionality I'm suggesting isn't very heavyweight, and the 
encapsulation will likely be useful.

OpenMP #pragma's are not the only ones that people apply to statements. 
 For example, I've seem #pragmas that turn off a particular warning for 
the duration of the next statement, or which provide information about 
where to put the next variable declaration in memory.

Like I said earlier, I don't think either RTH or myself wants to see 
OpenMP fail to get into the compiler on account of some nitpicking over 
internal datastructures.  So, it's going to get worked out.  I'm hoping 
that the other front-end maintainers will chime in; if either RTH or 
myself represents a tiny minority, then we'll have a pretty easy 
resolution.

Otherwise, I'll just get out of the way.  Either RTH will turn out to be 
right, in which case I'll be happy that the compiler is ever-so-swell, 
or wrong, in which case I'll have the satisfaction of making little 
clucking sounds later. :-)

--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304