February 2016 - mpiwg-fortran - mailman3.cels.anl.gov

Re: [MPIWG Fortran] Provide Fortran datatypes if Fortran bindings not provided?
by Bill Long 18 Feb '16

18 Feb '16

On Feb 18, 2016, at 4:09 PM, Craig Rasmusen <rasmus(a)cas.uoregon.edu> wrote: > >> (1) mpi.h does not provide a specific MPI Fortran datatype > > > I think JeffH and Jed want (1). > > > I think I want (1), too. > > I'm good with (1) too. This issue would not arise for Cray, but JeffH's argument to match the wording used for C++ is persuasive. So I am OK with (1) also. I agree with Rolf that the MPI spec should explicitly state the policy. Cheers, Bill > > -craig > > On Thu, Feb 18, 2016 at 1:31 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > On Feb 18, 2016, at 3:55 PM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: > > > > I would prefer a solution where an application or middlware can check at > > runtime whether the Fortran MPI datatypes exist, i.e., I like mpich's > > solution. It is more simple than all methods that People must check prior > > to compile and must remove or Change parts of there software. > > The reason that JeffH and Jed hate this solution is because it makes it quite difficult for an application to know whether the MPI has Fortran support or not -- they basically have to compile an MPI application *and then run it* to see if the datatypes are actually MPI_DATATYPE_NULL. > > Doing this inside a GNU Autoconf/configure script is very, very difficult because of the huge differences in how you launch MPI applications across different HPC environments. > > Their (strong) preference is that you can have a simple compilation test in the GNU Autoconf/configure script that just tries to compile something like the following: > > ----- > #include <mpi.h> > MPI_Datatype foo = MPI_INTEGER; > ----- > > If that compiles, then your MPI has Fortran support. > If it doesn't compile, your MPI doesn't have Fortran support. > > > In the moment,in the case of a missing accompanying Fortran Compiler, > > an application or middleware that wants to handle > > MPI Fortran datatypes must handle both cases > > (1) mpi.h does not provide a specific MPI Fortran datatype > > (2) mpi.h provides this MPI Fortran datatype as MPI_DATATYPE_NULL > > > > The additional case, that it is mapped to a real datatype is not > > an exception, because it defines some sort of accompanying Fortran Compiler. > > > > I would prefer that the MPI standard defines, which of the two > > options should be implemented. > > I think JeffH and Jed want (1). > > I think I want (1), too. > > > As said at the beginning, I would prefer (1), > > - as mpich is doing it in general, and > > - OMPI is doing it partially, > > whereas (2) was not done by mpich nor by OMPI. > > I think you have (1) and (2) backwards in this paragraph. > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran Bill Long longb(a)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

1 0

Re: [MPIWG Fortran] Provide Fortran datatypes if Fortran bindings not provided?
by Craig Rasmusen 18 Feb '16

18 Feb '16

>> (1) mpi.h does not provide a specific MPI Fortran datatype > I think JeffH and Jed want (1). > I think I want (1), too. I'm good with (1) too. -craig On Thu, Feb 18, 2016 at 1:31 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com > wrote: > On Feb 18, 2016, at 3:55 PM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> > wrote: > > > > I would prefer a solution where an application or middlware can check at > > runtime whether the Fortran MPI datatypes exist, i.e., I like mpich's > > solution. It is more simple than all methods that People must check prior > > to compile and must remove or Change parts of there software. > > The reason that JeffH and Jed hate this solution is because it makes it > quite difficult for an application to know whether the MPI has Fortran > support or not -- they basically have to compile an MPI application *and > then run it* to see if the datatypes are actually MPI_DATATYPE_NULL. > > Doing this inside a GNU Autoconf/configure script is very, very difficult > because of the huge differences in how you launch MPI applications across > different HPC environments. > > Their (strong) preference is that you can have a simple compilation test > in the GNU Autoconf/configure script that just tries to compile something > like the following: > > ----- > #include <mpi.h> > MPI_Datatype foo = MPI_INTEGER; > ----- > > If that compiles, then your MPI has Fortran support. > If it doesn't compile, your MPI doesn't have Fortran support. > > > In the moment,in the case of a missing accompanying Fortran Compiler, > > an application or middleware that wants to handle > > MPI Fortran datatypes must handle both cases > > (1) mpi.h does not provide a specific MPI Fortran datatype > > (2) mpi.h provides this MPI Fortran datatype as MPI_DATATYPE_NULL > > > > The additional case, that it is mapped to a real datatype is not > > an exception, because it defines some sort of accompanying Fortran > Compiler. > > > > I would prefer that the MPI standard defines, which of the two > > options should be implemented. > > I think JeffH and Jed want (1). > > I think I want (1), too. > > > As said at the beginning, I would prefer (1), > > - as mpich is doing it in general, and > > - OMPI is doing it partially, > > whereas (2) was not done by mpich nor by OMPI. > > I think you have (1) and (2) backwards in this paragraph. > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran >

1 0

Re: [MPIWG Fortran] Provide Fortran datatypes if Fortran bindings not provided?
by Jeff Squyres (jsquyres) 18 Feb '16

18 Feb '16

On Feb 18, 2016, at 4:43 PM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: > >> I think JeffH and Jed want (1). >> I think I want (1), too. > > I see the point. > I have not a strong opinion and would like to know, > what the other representatives in the Forum would like to see, > because > > (2) MPI_DATATYPE_NULL is what they mainly have today. The standard currently requires that the Fortran datatypes *exist* in mpi.h, no matter what (which seems to be in contradiction to what we stated for the C++ datatypes). That's why the implementations are currently this way. > (1) "not existing" would be a real change. Agreed. I'll ask Martin if there's plenary time to get a straw vote. -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [MPIWG Fortran] Provide Fortran datatypes if Fortran bindings not provided?
by Jeff Hammond 18 Feb '16

18 Feb '16

On Thu, Feb 18, 2016 at 1:43 PM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: > > I think you have (1) and (2) backwards in this paragraph. > Yes, I did it with the wrong numbers. I corrected it below. > > > I think JeffH and Jed want (1). > > I think I want (1), too. > > I see the point. > I have not a strong opinion and would like to know, > what the other representatives in the Forum would like to see, > because > > (2) MPI_DATATYPE_NULL is what they mainly have today. > (1) "not existing" would be a real change. > > Real only in the sense that things will break at compile-time instead of run-time. We are not breaking any working programs if we make this change. Jeff > Rolf > > ----- Original Message ----- > > From: "Jeff Squyres" <jsquyres(a)cisco.com> > > To: "MPI-WG Fortran working group" <mpiwg-fortran(a)lists.mpi-forum.org> > > Sent: Thursday, February 18, 2016 10:31:23 PM > > Subject: Re: [MPIWG Fortran] Provide Fortran datatypes if Fortran > bindings not provided? > > > On Feb 18, 2016, at 3:55 PM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> > wrote: > >> > >> I would prefer a solution where an application or middlware can check at > >> runtime whether the Fortran MPI datatypes exist, i.e., I like mpich's > >> solution. It is more simple than all methods that People must check > prior > >> to compile and must remove or Change parts of there software. > > > > The reason that JeffH and Jed hate this solution is because it makes it > quite > > difficult for an application to know whether the MPI has Fortran support > or not > > -- they basically have to compile an MPI application *and then run it* > to see > > if the datatypes are actually MPI_DATATYPE_NULL. > > > > Doing this inside a GNU Autoconf/configure script is very, very difficult > > because of the huge differences in how you launch MPI applications across > > different HPC environments. > > > > Their (strong) preference is that you can have a simple compilation test > in the > > GNU Autoconf/configure script that just tries to compile something like > the > > following: > > > > ----- > > #include <mpi.h> > > MPI_Datatype foo = MPI_INTEGER; > > ----- > > > > If that compiles, then your MPI has Fortran support. > > If it doesn't compile, your MPI doesn't have Fortran support. > > > >> In the moment,in the case of a missing accompanying Fortran Compiler, > >> an application or middleware that wants to handle > >> MPI Fortran datatypes must handle both cases > >> (1) mpi.h does not provide a specific MPI Fortran datatype > >> (2) mpi.h provides this MPI Fortran datatype as MPI_DATATYPE_NULL > >> > >> The additional case, that it is mapped to a real datatype is not > >> an exception, because it defines some sort of accompanying Fortran > Compiler. > >> > >> I would prefer that the MPI standard defines, which of the two > >> options should be implemented. > > > > I think JeffH and Jed want (1). > > > > I think I want (1), too. > > > As said at the beginning, I would prefer (2), > >> - as mpich is doing it in general, and > >> - OMPI is doing it partially, > whereas (1) was not done by mpich nor by OMPI. > > > > > > -- > > Jeff Squyres > > jsquyres(a)cisco.com > > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > > _______________________________________________ > > mpiwg-fortran mailing list > > mpiwg-fortran(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > -- > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)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) > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [MPIWG Fortran] Provide Fortran datatypes if Fortran bindings not provided?
by Jeff Hammond 18 Feb '16

18 Feb '16

On Thu, Feb 18, 2016 at 1:31 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com > wrote: > On Feb 18, 2016, at 3:55 PM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> > wrote: > > > > I would prefer a solution where an application or middlware can check at > > runtime whether the Fortran MPI datatypes exist, i.e., I like mpich's > > solution. It is more simple than all methods that People must check prior > > to compile and must remove or Change parts of there software. > > The reason that JeffH and Jed hate this solution is because it makes it > quite difficult for an application to know whether the MPI has Fortran > support or not -- they basically have to compile an MPI application *and > then run it* to see if the datatypes are actually MPI_DATATYPE_NULL. > > Well, technically, I can look up how every implementation implements this when it isn't supported and do a compile-time check for it, but this is a truly terrible solution (which I have demonstrated below). I do not want an MPI application to compile if it is certain to not work. #if defined(MPICH) #if defined(MPI_INTEGER) && MPI_INTEGER=="((MPI_Datatype)MPI_DATATYPE_NULL)" #error If you want Fortran, get a Fortran! #endif #endif Doing this inside a GNU Autoconf/configure script is very, very difficult > because of the huge differences in how you launch MPI applications across > different HPC environments. > > Indeed. It makes cross-compilation impossible on systems like Blue Gene and Cray, which do not allow one to launch an MPI application on the login node, and likely not the service node. > Their (strong) preference is that you can have a simple compilation test > in the GNU Autoconf/configure script that just tries to compile something > like the following: > > ----- > #include <mpi.h> > MPI_Datatype foo = MPI_INTEGER; > ----- > > If that compiles, then your MPI has Fortran support. > If it doesn't compile, your MPI doesn't have Fortran support. > > Exactly. > > In the moment,in the case of a missing accompanying Fortran Compiler, > > an application or middleware that wants to handle > > MPI Fortran datatypes must handle both cases > > (1) mpi.h does not provide a specific MPI Fortran datatype > This is what I want. > > (2) mpi.h provides this MPI Fortran datatype as MPI_DATATYPE_NULL > > > I think this is what is implemented today and it is the only reasonable implementation of what the text says (and doesn't say) right now. > > The additional case, that it is mapped to a real datatype is not > > an exception, because it defines some sort of accompanying Fortran > Compiler. > > > > I would prefer that the MPI standard defines, which of the two > > options should be implemented. > > I think JeffH and Jed want (1). > > I think I want (1), too. > > You are as intelligent as your name suggests :-) > > As said at the beginning, I would prefer (1), > > - as mpich is doing it in general, and > > - OMPI is doing it partially, > > whereas (2) was not done by mpich nor by OMPI. > > As I showed earlier, MPICH does 2. Do I misunderstand you? > I think you have (1) and (2) backwards in this paragraph. > > I think I am confused now. Jeff > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [MPIWG Fortran] Provide Fortran datatypes if Fortran bindings not provided?
by Rolf Rabenseifner 18 Feb '16

18 Feb '16

> I think you have (1) and (2) backwards in this paragraph. Yes, I did it with the wrong numbers. I corrected it below. > I think JeffH and Jed want (1). > I think I want (1), too. I see the point. I have not a strong opinion and would like to know, what the other representatives in the Forum would like to see, because (2) MPI_DATATYPE_NULL is what they mainly have today. (1) "not existing" would be a real change. Rolf ----- Original Message ----- > From: "Jeff Squyres" <jsquyres(a)cisco.com> > To: "MPI-WG Fortran working group" <mpiwg-fortran(a)lists.mpi-forum.org> > Sent: Thursday, February 18, 2016 10:31:23 PM > Subject: Re: [MPIWG Fortran] Provide Fortran datatypes if Fortran bindings not provided? > On Feb 18, 2016, at 3:55 PM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: >> >> I would prefer a solution where an application or middlware can check at >> runtime whether the Fortran MPI datatypes exist, i.e., I like mpich's >> solution. It is more simple than all methods that People must check prior >> to compile and must remove or Change parts of there software. > > The reason that JeffH and Jed hate this solution is because it makes it quite > difficult for an application to know whether the MPI has Fortran support or not > -- they basically have to compile an MPI application *and then run it* to see > if the datatypes are actually MPI_DATATYPE_NULL. > > Doing this inside a GNU Autoconf/configure script is very, very difficult > because of the huge differences in how you launch MPI applications across > different HPC environments. > > Their (strong) preference is that you can have a simple compilation test in the > GNU Autoconf/configure script that just tries to compile something like the > following: > > ----- > #include <mpi.h> > MPI_Datatype foo = MPI_INTEGER; > ----- > > If that compiles, then your MPI has Fortran support. > If it doesn't compile, your MPI doesn't have Fortran support. > >> In the moment,in the case of a missing accompanying Fortran Compiler, >> an application or middleware that wants to handle >> MPI Fortran datatypes must handle both cases >> (1) mpi.h does not provide a specific MPI Fortran datatype >> (2) mpi.h provides this MPI Fortran datatype as MPI_DATATYPE_NULL >> >> The additional case, that it is mapped to a real datatype is not >> an exception, because it defines some sort of accompanying Fortran Compiler. >> >> I would prefer that the MPI standard defines, which of the two >> options should be implemented. > > I think JeffH and Jed want (1). > > I think I want (1), too. > As said at the beginning, I would prefer (2), >> - as mpich is doing it in general, and >> - OMPI is doing it partially, whereas (1) was not done by mpich nor by OMPI. > > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)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)

1 0

Re: [MPIWG Fortran] Provide Fortran datatypes if Fortran bindings not provided?
by Jeff Squyres (jsquyres) 18 Feb '16

18 Feb '16

On Feb 18, 2016, at 3:55 PM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: > > I would prefer a solution where an application or middlware can check at > runtime whether the Fortran MPI datatypes exist, i.e., I like mpich's > solution. It is more simple than all methods that People must check prior > to compile and must remove or Change parts of there software. The reason that JeffH and Jed hate this solution is because it makes it quite difficult for an application to know whether the MPI has Fortran support or not -- they basically have to compile an MPI application *and then run it* to see if the datatypes are actually MPI_DATATYPE_NULL. Doing this inside a GNU Autoconf/configure script is very, very difficult because of the huge differences in how you launch MPI applications across different HPC environments. Their (strong) preference is that you can have a simple compilation test in the GNU Autoconf/configure script that just tries to compile something like the following: ----- #include <mpi.h> MPI_Datatype foo = MPI_INTEGER; ----- If that compiles, then your MPI has Fortran support. If it doesn't compile, your MPI doesn't have Fortran support. > In the moment,in the case of a missing accompanying Fortran Compiler, > an application or middleware that wants to handle > MPI Fortran datatypes must handle both cases > (1) mpi.h does not provide a specific MPI Fortran datatype > (2) mpi.h provides this MPI Fortran datatype as MPI_DATATYPE_NULL > > The additional case, that it is mapped to a real datatype is not > an exception, because it defines some sort of accompanying Fortran Compiler. > > I would prefer that the MPI standard defines, which of the two > options should be implemented. I think JeffH and Jed want (1). I think I want (1), too. > As said at the beginning, I would prefer (1), > - as mpich is doing it in general, and > - OMPI is doing it partially, > whereas (2) was not done by mpich nor by OMPI. I think you have (1) and (2) backwards in this paragraph. -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [MPIWG Fortran] Provide Fortran datatypes if Fortran bindings not provided?
by Rolf Rabenseifner 18 Feb '16

18 Feb '16

I would prefer a solution where an application or middlware can check at runtime whether the Fortran MPI datatypes exist, i.e., I like mpich's solution. It is more simple than all methods that People must check prior to compile and must remove or Change parts of there software. In the moment,in the case of a missing accompanying Fortran Compiler, an application or middleware that wants to handle MPI Fortran datatypes must handle both cases (1) mpi.h does not provide a specific MPI Fortran datatype (2) mpi.h provides this MPI Fortran datatype as MPI_DATATYPE_NULL The additional case, that it is mapped to a real datatype is not an exception, because it defines some sort of accompanying Fortran Compiler. I would prefer that the MPI standard defines, which of the two options should be implemented. As said at the beginning, I would prefer (1), - as mpich is doing it in general, and - OMPI is doing it partially, whereas (2) was not done by mpich nor by OMPI. The MPI Forum may do a straw vote on that. Best regards Rolf ----- Original Message ----- > From: "Jeff Squyres" <jsquyres(a)cisco.com> > To: "MPI-WG Fortran working group" <mpiwg-fortran(a)lists.mpi-forum.org> > Sent: Thursday, February 18, 2016 7:42:05 PM > Subject: Re: [MPIWG Fortran] Provide Fortran datatypes if Fortran bindings not provided? > On Feb 18, 2016, at 1:31 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >> >> > Please tell me why we want to do something different for Fortran. >> >> Seems to be a good point. >> What is mpich doing if there is no accompanying Fortran compiler? >> >> Full mpi.h from my Clang MPICH builds with FC=false attached. Relevant excerpt >> below. >> /* Fortran types */ >> >> #define MPI_COMPLEX ((MPI_Datatype)MPI_DATATYPE_NULL) > > It looks like OMPI does a mix of setting some Fortran datatypes to (effectively) > MPI_DATATYPE_NULL and others to what we guess/assume they should be equivalent > to (e.g., MPI_INTEGER --> MPI_INT). > >> Middleware that compiles but cannot be used in any nontrivial way because >> MPI_DATATYPE_NULL may (at least with Open-MPI) cause the program to abort. I >> don't see a problem in breaking compilation when successful compilation today >> leads to unsuccessful execution. > > +1 > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)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)

1 0

Re: [MPIWG Fortran] Provide Fortran datatypes if Fortran bindings not provided?
by Jeff Hammond 18 Feb '16

18 Feb '16

On Thu, Feb 18, 2016 at 11:06 AM, Bill Long <longb(a)cray.com> wrote: > > On Feb 18, 2016, at 11:55 AM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > > > From MPI 3.1, page 674: > > > > "If an accompanying C++ compiler is missing, then the MPI datatypes in > this table are not defined." > > > > Please tell me why we want to do something different for Fortran. > > I agree that this is a good point. Although an increasingly strange one > in the C++ case since the C and C++ compilers are often the identical same > compiler these days. The choice of cc or CC just sets a different mode > internally. > > <tangent> We still need to be careful, because C99 and C11 are not strict subsets of any ISO C++. And at least one MPI Forum member (Microsoft) has the audacity to not support ISO C at all, except insofar as it is a subset of C++, which is why lots of folks (e.g. MPICH) are limited to C89, which is - as far as I know - a proper subset of C++. While we do not have C++ bindings and our C bindings are compliant with C89, there is some potential for this to change in the future, particularly if Squyres and Hammond follow-through on their intent to solve the large-count problem with C11/C++98 polymorphism. </tangent> > Cheers, > Bill > > > > > Bill Long > longb(a)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 > > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [MPIWG Fortran] Provide Fortran datatypes if Fortran bindings not provided?
by Bill Long 18 Feb '16

18 Feb '16

On Feb 18, 2016, at 11:55 AM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > From MPI 3.1, page 674: > > "If an accompanying C++ compiler is missing, then the MPI datatypes in this table are not defined." > > Please tell me why we want to do something different for Fortran. I agree that this is a good point. Although an increasingly strange one in the C++ case since the C and C++ compilers are often the identical same compiler these days. The choice of cc or CC just sets a different mode internally. Cheers, Bill > Bill Long longb(a)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

1 0