Re: [Gomp-discuss] corrections to gompspecs.tex

[Biagio Lucini]

Hello Melvin, glad you joined us :-)

As you have understood, the project is in standby at the moment because we 
need tight integration with the tree-ssa middle end, which is still under 
heavy development, and because we need a more evolved C parser (whose state I 
ignore: it was supposed to be almost ready one year ago). 

At that time, we decided to start from C because Fortran 77 did not look a 
good investment for the future and F95 was far from being complete. Now 
things have probably changed, and F95 could be a more suitable target for our 
hack. In any case, Steven and Paul should be reading this mailing list, so 
they can give their opinion on this topic.

Final thought: the more technical people in this mailing list (I'm not one of 
them) are heavily busy either with tree-ssa or with gcc- f95; probably we 
will make no progress here until those projects are in a more advanced stage 
or new enthusiastic and fresh forces join gomp.

Cheers
Biagio  

On Monday 19 January 2004 19.02, Melvin Hadasht wrote:
> Hi all,
>
> I've just discovered this project after reading comments on gcc's ML about
> the possibility of merging tree-ssa to 3.5. I should say that as a CFD
> engineer (researcher), I am very interested in seeing both a GNU fortran 95
> and an OpenMP implementation.
>
> I found that the gompspec.tex seems to be based on pre 2.0 OpenMP: the
> example says that a private variable has to be initialized to zero, but
> OpenMP specifications 2.0  say:
>
> ------8< From: fspecs20_bar.pdf, p35:
>
> 1162:
> 3. Variables declared as PRIVATE are undefined for each thread on entering
> the construct, and the corresponding shared variable is undefined on exit
> from a parallel construct.
> ------>8
>
> This was added in the 2.0 specs. As you have agreed to only support 2.0,
> maybe this should be modified. I attached a small patch.
>
> There is also a typo in savannah.nongnu.org summary page: the title has
> "imp*r*ementation" instead of "imp*l*ementation".
>
> According to the http://gcc.gnu.org/cvs.html, the gomp branch is in an
> inactive state due to limitations to the C parser. I read this ML and if I
> understand correctly it was decided to start with the C/C++ because
> gfortran was at that point not really usable. How about the current status
> of gfortran? IIRC, it does have a specific parser. Could gfortran be
> sufficiently mature to allow resuming the work on gomp? I am willing to
> help, but I have currently not sufficiently knowledge with compiler
> internals (but I capable of bug hunting). Though, I am currently reading
> libgfortran and specifically its I/O part to see if it is thread safe and
> how to make it suitable for parallel programs.
>
> Apple is now building dual CPU machines and has an OS that has a POSIX
> API. Apple also contributes and uses GCC as its standard compiler.
> According to their website and to a pdf presenting Xserve, they have the
> OpenMP compiler is from VAST which supports OpenMP 1.1 (2.0 is coming
> soon). There is also http://phase.hpcc.jp/Omni/, a OpenMP C/F77 to C +
> library translator (and OdinMP). Would they be interested in helping a GCC
> implementation of OpenMP?
>
> My experience in coding is primarly fortran77 and 90 on vectorial machines
> (Cray, NEC SX5, 4 years) and some short experience with OpenMP on SGI
> 2000. I extended a CFD code and optimized it on these architectures. I am
> also involved in non-engineering software (contributing to Sylpheed-Claws
> mailer, and currently working on a multi-threaded mailer (XetPan)).
>
> Best regards,

-- 
=========================================================

Biagio Lucini                                 
Institut Fuer Theoretische Physik
ETH Hoenggerberg      
CH-8093 Zuerich - Switzerland           
Tel. +41 (0)1 6332562  
 
=========================================================