Re: [mpi-21] F90 bindings

["William Yu" <wyu@xxxxxxxxxx>]

Do people use f03 specifc features already? Or do they settle with f90 features with some vendor proprietary ones like void*? 

I was thinking the standard can be written for f03 but with f90+void* in mind? Messy tho. Of course, that is assuming that is the only major issue and difference. Which is a big one.

________________ Reply Header ________________
Subject:	Re: [mpi-21] F90 bindings
Author:	"Joe Ratterman" <jratt0@xxxxxxxxx>
Date:		December 07th 2007 8:57 pm

The IBM XL Fortran compilers for AIX, Linux, and Blue Gene claim
"enhanced compliance" with F2003.  However, I do not have much
experience.
http://www-306.ibm.com/software/awdtools/fortran/xlfortran/features/f2003.html

Quote (they are now on v11.1):
Beginning with the V8.1 release, XL Fortran has delivered many Fortran
2003 standard features, including:
    * BIND(C) for portable interoperability with C code
    * Allocatable objects beyond just Fortran 95 arrays
    * Stream I/O support
    * ASSOCIATE and ENUM statements
    * READ with BLANK= and PAD= specifiers
    * WRITE with DELIM= specifier
    * IEEE and Fortran environment modules
This release of XL Fortran builds on that work to arrive at the most
complete Fortran 2003 implementation currently available, with Derived
Type Parameters being the only major feature not yet implemented.


On Dec 7, 2007 9:01 AM, William Emmanuel S. Yu <wyu@xxxxxxxxxx> wrote:
>
> I think the more critical issue is what people actually use (and plan
> to use) out there. I don't quite know about the developments in the
> Fortran space in general. But, in the open source world, we were just
> able to get a decent F90 compiler out recently.
>
> Are there any decent F03 (open source or not) compilers out there? Are
> there people who use F03 over F90? I remember the MM5 folk are using
> F77/F90. The rest of the tools we use are written in C.
>
>
>
>
> Quoting Purushotham Bangalore <puri@xxxxxxxxxxx>:
>
> > Jeff raises an important issue here. In it's current form are the
> > F90 bindings really useful? Should we just move on to the next
> > version of Fortran (2003 or 2008) and deprecate the F90 bindings?
> > Anyone received any feedback on this issue from F90 users?
> >
> > Puri
> > ----- Original Message -----
> > From: "Jeff Squyres" <jsquyres@xxxxxxxxx>
> > To: mpi-21@xxxxxxxxxxxxx
> > Sent: Friday, December 7, 2007 7:23:57 AM (GMT-0600) America/Chicago
> > Subject: [mpi-21] F90 bindings
> >
> > The F90 bindings specified in MPI-2 currently require nearly 7 million
> > interface functions in the Fortran 90 module (!).  This large number
> > of interfaces is required because F90 is a strongly-typed language and
> > has no analogue of (void*).  MPI_SEND, for example, has to be
> > overloaded with function signatures for every possible type of choice
> > buffer.  Worse, many collectives have *2* choice buffers... the end
> > result is that nearly 7M interfaces are needed.  As result, many MPI
> > implementations implement only a fraction of the MPI F90 module
> > interface functions.
> >
> > Additionally, user-defined F90 types cannot be supported.
> >
> > This is clearly a [big] bug in the F90 bindings.  What does the Forum
> > want to do about this for MPI-2.1?  Perhaps add some clarification
> > language?  Or ...?
> >
> > Can this issue be added to the discussion list for the bindings
> > subcommittee?
> >
> > --
> > Jeff Squyres
> > Cisco Systems
> >
> >
> >
>
>
>
> -------------------------------------------------------
> William Emmanuel S. Yu
> Department of Information Systems and Computer Science
> Ateneo de Manila University
> email  :  wyu at ateneo dot edu
> blog   :  http://hip2b2.yutivo.org/
> web    :  http://CNG.ateneo.edu/cng/wyu/
> phone  :  +63(2)4266001 loc. 4186
> GPG    :  http://CNG.ateneo.net/cng/wyu/wyy.pgp
>
> Confidentiality Issue:  This message is intended only for the use of the
> addressee and may contain information that is privileged and
> confidential. If you are not the intended recipient, you are hereby
> notified that any use or dissemination of this communication is strictly
> prohibited.  If you have received this communication in error, please
> notify us immediately by reply and delete this message from your system.
>
>
>