[MPI3 Fortran] New Fortran proposal w.r.t. BIND(C)/logical/etc.

Fri Apr 26 07:47:16 CDT 2013

Yes, the two library versions may be a good idea.
But still we need to define the interceptable linker names,
i.e., the names according to A1 and A2 in my pdf, together
with a method that the tools can detect whether a 
 - A1 (no buffer or buffer as address pointer) or
 - A2 (buffer as descriptor according to the used Fortran compiler) 
interface is provided.

Rolf

----- Original Message -----
> From: "Jeff Squyres (jsquyres)" <jsquyres at cisco.com>
> To: "Craig Rasmussen" <rasmus at cas.uoregon.edu>
> Cc: "MPI-3 Fortran working group" <mpi3-fortran at lists.mpi-forum.org>
> Sent: Friday, April 26, 2013 2:28:28 PM
> Subject: Re: [MPI3 Fortran] New Fortran proposal w.r.t. BIND(C)/logical/etc.
> I don't think I understand Bill's counter proposal.
> 
> However, I think Craig just (accidentally?) hit on what might be a
> good compromise: implementations are free to provide multiple Fortran
> libraries:
> 
> A. One library can use CONTAIN/be inlined and be what 99.999% of the
> world will use. It can even be the default library (e.g., for
> implementations that have mpifort wrapper compilers).
> 
> B. The other can have interceptable symbols.
> 
> And therefore since the implementation supports interceptable Fortran
> symbols, it's compliant.
> 
> With clever source code and/or build system in the implementation, the
> same Fortran wrappers could probably be compiled twice to provide both
> libraries.
> 
> 
> 
> On Apr 24, 2013, at 12:56 PM, Craig Rasmussen <rasmus at cas.uoregon.edu>
> wrote:
> 
> > I actually like Bill's counter proposal. My only suggestion is that
> > an implementation must implement all of one or more of the options.
> > I think splitting the symbols up into various subsets needlessly
> > complicates things for everyone: the standard, the implementations,
> > the casual Fortran tool writer, and the C tool community.
> >
> > Some MPI implementations could easily create a compile time option
> > to build separate libraries with one providing C symbol
> > interceptability and the other providing Fortran symbol
> > interceptability.
> >
> > By the way, Bill has a lot of experience on the Fortran standard's
> > committee writing "standard legalese", something that is completely
> > outside my skill set given my experience in writing text for
> > scientific journals. So perhaps he can help with some of the text.
> >
> > Dictionary definition of legalese: the formal and technical language
> > of legal documents that is often hard to understand
> >
> > Craig Rasmussen
> > CAS Scientific Programmer
> > rasmus at cas.uoregon.edu
> >
> >
> > On Apr 24, 2013, at 7:46 AM, Bill Long wrote:
> >
> >>
> >>
> >> On 4/24/13 8:41 AM, Jeff Squyres (jsquyres) wrote:
> >>> On Apr 24, 2013, at 9:36 AM, Bill Long <longb at cray.com> wrote:
> >>>
> >>>>> You're imposing a specific implementation scheme. We can't allow
> >>>>> that in the MPI spec.
> >>>>
> >>>> I disagree with the first sentence. I'm wanting to merely ALLOW a
> >>>> new scheme (which is better one that the current lot, in my
> >>>> opinion).
> >>>
> >>> Rolf's proposal mandates 3 specific implementation schemes. So I
> >>> should have said "Rolf", not "you". :-)
> >>>
> >>>> So you are saying that disallowing better implementations is part
> >>>> of the mandate of the MPI spec?
> >>>
> >>> Don't be like that.
> >>>
> >>
> >> I didn't mean to be mean. The Fortran standard has a lot of
> >> instances of disallowing things, and I was not sure if the same was
> >> true of MPI.
> >> [I'm in the middle of a symposium all day today, so sorry about not
> >> being prompt with replies.]
> >>
> >>>>> One of the reasons I really, really dislike Rolf's proposal text
> >>>>> is that it mandates one of three implementation choices. Not
> >>>>> only does the MPI standard specifically stay away from all
> >>>>> implementation issues in normative text, none of the 3
> >>>>> implementation choices that Rolf outlined are how Open MPI is
> >>>>> implemented.
> >>>>
> >>>> Then I see that as a problem. We should be looking at ways to
> >>>> allow the OpenMPI implementation rather than prohibiting
> >>>> implementations that are different.
> >>>
> >>>
> >>> The MPI spec takes great pains to not mandate any particular
> >>> implementation at all.
> >>>
> >>
> >> My view (inexperienced as it is) is that this section is mainly
> >> about specifying what symbol names need to be available so that the
> >> tools know what to look for/intercept. I'd be in favor of just
> >> listing the names and characteristics without commentary about how
> >> they get produced (i.e. remove the discussion about the
> >> implementation detail). Something like to following:
> >>
> >> Class 1: For an MPI routine MPI_xxx with a void * choice argument,
> >> or with no choice argument, the implementation shall provide at AT
> >> LEAST ONE of the following:
> >>
> >> 1) An external with the C name MPI_xxx and C calling conventions as
> >> specified in the C prototype in Annex A.
> >>
> >> 2) An external with the name "......" that uses the Fortran calling
> >> conventions and has INTEGER handle arguments, as specified in Annex
> >> A.
> >>
> >> 3) An external with the name "....." that uses the Fortran calling
> >> conventions and has derived type handle arguments, as specified in
> >> Annex A.
> >>
> >>
> >> Class 2: For an MPI routine MPI_xxx with a descriptor choice
> >> argument, the implementation shall provide AT LEAST ONE of the
> >> following:
> >>
> >> 1) An external with the C name MPI_xxx_cdesc and C calling
> >> conventions...
> >>
> >> 2), 3) Similar to above.
> >>
> >> With rules like these, a tool would have a small list of names to
> >> look for, and the correct calling information about each.
> >>
> >> Cheers,
> >> Bill
> >>
> >>
> >>
> >> --
> >> Bill Long longb at cray.com
> >> Fortran Technical Support & voice: 651-605-9024
> >> Bioinformatics Software Development fax: 651-605-9142
> >> Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101
> >>
> >>
> >
> 
> 
> --
> Jeff Squyres
> jsquyres at cisco.com
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
> 
> 
> _______________________________________________
> mpi3-fortran mailing list
> mpi3-fortran at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

-- 
Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner at hlrs.de
High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530
University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832
Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner
Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)