RE: [Gomp-discuss] Plan ... coments wanted !

[Steven Bosscher]

Op vr 31-01-2003, om 02:55 schreef Scott Robert Ladd:
> Hi,
> 
> > Depending on how big the differences are, we could decide to drop the
> > idea of a language independent OpenMP interface. Does anybody know how
> > big the OpenMP semantics differences mentioned by Scott really are
> > between the specifications for C/C++ and Fortran?
> 
> The differences exist in subtle areas. Some examples:
> 
> 1) For C++, OpenMP allows programmer-controlled scoping of static class
> members (something that is not a language feature of Fortran).
> 
> 2) The default scoping for loop variables is different between C/C++ and
> Fortran.
> 
> 3) C and C++ allow variable declarations at any point; the compiler must
> understand this and scope variables accordingly.
> 
> 4) C++ must account for constructor and destructor calls for private objects
> in a parallel region or loop. Fortran 95 does not need to be concerned with
> this.

Those are pretty big differences.  Yes, this should definitely suggest
to leave OpenMP in the front ends and define "parallel GENERIC" etc.
instead.
 
> There's more; it's been a long day, and I've probably screwed something up
> in that list because I'm pulling it from memory.
> 
> Is it possible to create a common subset? Maybe; I'd have to analyze the
> differences between Fortran and C++; I certainly suspect Intel uses common
> code between their C++ and Fortran compilers.
> 
> Before making any absolute pronouncements, I'd want to go over the OpenMP
> standards, and take a closer look at what Intel does.
> 
> I'm willing to do this in the next few days, if people think it has value.

I think it does has a lot of value (maye you can even sell it ;-)

> Or maybe someone else has a handle on these issues already?

For the library I looked at this already.  C/C++ share the same
interface of course.  The Fortran interface is the same as the C
interface with the current data layout from g95 except that we don't
have Cray pointers so we'd need a separate INTEGER kind for locks (as
suggested in the OMP Specs).

> > Actually, keeping all of OpenMP in the separate front ends may be the
> > better design choice even if the differences are really small.  Code for
> > parsing/analyzing OpenMP directives is specific to each front end
> > anyway, and like Diego suggested, we could introduce new tree codes *in
> > the parsers* already, e.g. a "for"-loop following a #pragma OMP for is
> > not parsed as just a normal FOR_STMT, but as a PARALLEL_FOR_STMT.
> > PARALLEL_FOR_STMT would have to be able to express the semantics of the
> > OpenMP directive, but it should not be OpenMP-specific.
> 
> This sounds good -- but then, I haven't written a compiler since I was in
> college in the 1970s!

Feel reassured that I have never written a compiler before?  And maybe
Lars and Biagio haven't either.  Oh well, we're smart people, aren't we?
O:-)

Greetz
Steven