gomp-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gomp-discuss] "#pragma omp" and GCC


From: Steven Bosscher
Subject: Re: [Gomp-discuss] "#pragma omp" and GCC
Date: 05 Feb 2003 14:12:37 +0100

Op wo 05-02-2003, om 13:25 schreef Biagio Lucini:
> What about dealing with all the syntax problems directly in the parser?
> For instance, you can set a flagt "parallel_region_flag = 1" whenever you
> have a
> 
> #pragma openmp parallel
> 
> Then, when you find #pragma omp sections, you check the value of
> parallel_region-flag; if it is different from 1, you return something like
> 
> "Error: the sections pragma can appear only inside a "#pragma omp
> parallel""
> 
> Then, again, if the check is correct, you keep parsing and you set
> parallel_sections_flag to 1. At the next "section" statement, you check
> that paralell_sections_flag is 1, otherwise you return an error. And so
> forth. This is very involved and full of sub-cases, I admit it, but
> probably safe and will allow you to do things all in one place.

I considered this approach and I didn't like it for two reasons:
- The number of subcases is just huge, this is error-prone.
- The changes to the parser are too invasive, and it clutters the
  code.  I even doubt a patch with this approach would be accepted.

Actually it may even be easier to move handling of "unregistered"
pragmas into the parser.

Right now you register a class of pragmas in GCC ("omp" is the class of
the ones we're discussing) and you give it a handler that the
preprocessor will call when it sees a pragma from that class.  We could
move pragma handling into the parser and call the handlers from there. 
That may be a bit too invasive too, though.
But it would help us a lot, because the OpenMP standard documents the
grammar changes that are required for OpenMP, but apparently under the
assumption that a pragma is handled in the parser....

> The same technique could be used for checking the validity of the clauses:
> you build a table of directives vs. clauses, and when you find a directive
> you also look if the following clause is legal. 

Right now I parse clauses one by one and I check for conflicting clauses
after a single clause is parser successfully.  The warning is about the
second clause in the list because we saw it later than the one it
conflicts with.
 
> Last thing to do: look that clauses are compatible. E.g. if I say
> 
> #pragma omp paralell private(x) shared(x) 
> 
> this is obviously illegal. This is trivial, but what is less trivial is
> that if you define
> 
> #pragma omp paralell private(x) reduction(+: x)
> 
> this is still illegal (at least according to the Intel compiler; some
> other compiler will happily accept it).
> 
> Any thoughts?

This I think is legal.  The OpenMP 2.0 C/C++ specification  states on on
page 31:

"Variables that are private within a parallel region or that appear in
the reduction clause of a parallel directive cannot be specified in a
reduction clause on a work-sharing directive that binds to the parallel
construct."

In this case, there is no "work-sharing directive" so there is no reason
to reject the clause.  Indeed, variables in a reduction list are
implicitly parallel already, according to this phrase on page 30:

"A private copy of each variable in variable-list is created, one for
each thread, as if the private clause had been used."

Greetz
Steven






reply via email to

[Prev in Thread] Current Thread [Next in Thread]