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

[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.

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.
Or maybe someone else has a handle on these issues already?

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

> For the front ends, we'd really only need two different OpenMP-aware
> pieces of code: One for Fortran, and the other one shared by C/C++.
>
> The semantics differences would have to be resolved in the front ends,
> and that's the proper place to do it.  If there is to be concurrency
> awareness in the tree optimizers, then it should IMHO be independent of
> OpenMP, so that languages that have their own concurrency (Java, Ada
> have been mentioned) may benefit from this infrastructure too.

C++ would need to be a superset of C, due to object
construction/destruction.

..Scott

--
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Professional programming for science and engineering;
Interesting and unusual bits of very free code.