This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [gomp] Challenges in Implementing OpenMP
Scott Robert Ladd wrote:
>> This example becomes easy again. libgomp is not a minor feat, an
>> gomp.c is not, but less overwhelming than what your source code
>> showed.
>
> I'm spend so much of my life writing cross-platform code, I tend to
> ignore compiler-specific facilities such as nested functions in C.
In this case, it is *very* useful to implement OpenMP, because it lets you
isolate a code block (still referring to local variables and scopes) into a
function that you can pass to a library. In other words, you greatly reduce the
code transformation needed.
> The initial design should work toward unifying the three languages to
> the greatest extent; that why I'm working on a document that defines
> where C, C++, and Fortran differ. The output of all three language
> parsers should end up being a language-neutral form that can be
> handled by later passes.
>
> The C, C++, and Fortran frontends are quite different, so much so
> that I see little opportunity for code sharing between them. Perhaps
> I'm wrong...
Well, it looks to me that this is already done in GCC. Both C, C++ and Fortran
emits (hi-)GIMPLE at some point, which is a tree-based language-neutral
representation of the code. They should emit GENERIC, but C/C++ go to GIMPLE
directly. This is not such a big problem as I was proposing to handle OpenMP
exactly in gimplification or immediatly after it.
Giovanni Bajo