Re: [gomp] parse OpenMP directives

[Sebastian Pop <sebastian dot pop at cri dot ensmp dot fr>]

Many thanks Joseph for your comments.

On Wed, Oct 13, 2004 at 10:40:02AM +0000, Joseph S. Myers wrote:
> Has there been any discussion - on the main public GCC lists - of the 
> design?
> 

One year ago there were some messages on the gcc mailing list that
discussed the OpenMP problems.  However there were no other design
discussions on the GOMP project as far as I remember.

http://gcc.gnu.org/ml/gcc/2003-02/msg00367.html
http://gcc.gnu.org/ml/gcc/2003-02/msg00498.html

> The approach in this patch seems reasonable in principle, but the patch 
> doesn't include any of the hard parts, such as the directives involving 
> expressions, and those that have effects on the handling of a subsequent 
> statement and restrict its form.  I don't think at present you'll easily 
> get a single directive parser working for both C and C++, though you may 
> be able to unify handling after parsing.
> 

For this I think that the solution is to generate a tree node per
pragma, then handle the code generation issues after the parser,
probably on GENERIC or even on GIMPLE level.  The far goal is to use a
part of this information to direct our loop nest optimizers.

> The diagnostics in the patch do not follow the GNU Coding Standards, 
> section 4.3, which describes how diagnostics are formatted.  In particular 
> note:
> 
>    The string message should not begin with a capital letter when it
>    follows a program name and/or file name, because that isn't the
>    beginning of a sentence. (The sentence conceptually starts at the
>    beginning of the line.) Also, it should not end with a period.
> 
> For this to go on mainline there should be testcases covering every 
> diagnostic, every conditional in the implementation and every constraint 
> in the OpenMP standard - for both C and C++ as far as the implementations 
> differ.  I strongly recommend adding testcases from the beginning.  Of 
> course there also need to be execution tests of all OpenMP constructs as 
> well.  Similarly, maintain a section of extend.texi discussing the state 
> of OpenMP support from the beginning, and update it as the support 
> improves.
> 

I will correct these and will keep these remarks in mind.  Many
thanks,

Sebastian