gomp-discuss
[Top][All Lists]
Advanced

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

Re: [Gomp-discuss] The draft ... issues


From: Biagio Lucini
Subject: Re: [Gomp-discuss] The draft ... issues
Date: Thu, 13 Mar 2003 09:06:39 +0000 (GMT)

A revised tex file is enclosed. Just in case, if you don't know what to do
with it
a) install if needed tetex-latex on a Linux system
b) the command

        pdflatex gompspec.tex

should produce the corresponding gompspec.pdf


On Thu, 13 Mar 2003, Lars Segerlund wrote:

>
>   Now here follows my opinions on this, and are to be treated as such.
>
>   In the introduction I would like an additional statement right after
> 'introducing openMP directives in the compiler' along the lines of, '
> and provide a general concurrency aware framework for gcc internals, in
> order to handle all forms of concurrency and memory models'.
>   I believed that this was what we strived for as related to the IR, (
> trees and such ). It might also better be placed in the 'GCC and
> concurrency' section, but I'm not sure about this.
>

Added a slightly weaker statement in the introduction. Basically, it means
that we try to be as general as possible unless generality becomes
unrealistically difficult.

>   In the from directives to IR section I would like to se the openMP
> fortran spec included, to single out C/C++ seem's a bit narrow. I do
> however agree on first targetting C/C++. ( not much difference anyway ).

This is based on a discussion we have had here about the immaturity of the
Fortran frontends. I care about fortran, so I want it in at some point as
well! Added a carifying footnote.

>
>   In the thread creation part, I think we can safely say that the Posix
> thread model is a good starting point, ( whatever underlying library
> used this is a standard model with standard semantics, and nobody has
> objected to it on the list ).
>

Taken on board.

>   I have some issues with the last part, since locks and
> synchronizations are most often implemented ontop of mutexes, semaphores
> and other 'more' primitive elements. I also believe that the term
> threading model here should be exchanged with threading implementation
> in this context.
>

I am not expert on that and I still have to look at the related issues. If
you like you can rewrite that part. For the time being, I have added a
visible disclaimer at the beginning of the section.

Thanks,
Biagio




reply via email to

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