Iain, OK, let's go back to the initial question, Jeff's comment ,-) I was referring to:
arch.h:53:** The fortran integer is dismissed here, since there is no arch.h:54:** platform known to me, were fortran and C-integer do not match > You can tell the intel compiler (and maybe others?) to compile > fortran with double-sized integers and reals. Are we disregarding > this? I.e., does this make this portion of the datatype > heterogeneity detection incorrect? IMHO the comment is correct. Let me rephrase my last email to be more exact: Within architectural representation, we disregard representation of Fortran INTEGER, as there needs to be some equivalent C integral type in order to support it. Please note, that other INTEGER* types (star-notation, probably the source of confusion in the first answer) may not be supported in Open MPI, as there is no C representation, e.g. on Linux x86-64: checking if Fortran 77 compiler supports INTEGER*16... yes checking size of Fortran 77 INTEGER*16... 16 checking for C type corresponding to INTEGER*16... not found configure: WARNING: *** Did not find corresponding C type Other types may have different alignment requirements, e.g. on Linux x86-64 using icc: checking size of short... 2 checking alignment of short... 2 while checking size of Fortran 77 INTEGER*2... 2 checking for C type corresponding to INTEGER*2... short checking alignment of Fortran INTEGER*2... 16 Do You have a suggestion to clarify the comment? With best regards, Rainer On Wednesday 03 June 2009 02:27:42 pm Iain Bason wrote: > On Jun 3, 2009, at 1:30 PM, Ralph Castain wrote: > > I'm not entirely sure what comment is being discussed. > > Jeff said: > > I see the following comment: > > > > ** The fortran integer is dismissed here, since there is no > > ** platform known to me, were fortran and C-integer do not match > > > > You can tell the intel compiler (and maybe others?) to compile > > fortran with double-sized integers and reals. Are we disregarding > > this? I.e., does this make this portion of the datatype > > heterogeneity detection incorrect? > > Rainer said: > > no, that's not an issue. The comment is correct: For any Fortran > > integer*kind > > we need to have _some_ C-representation as well, otherwise we > > disregard the > > type (tm), see e.g. the old and resolved ticket #1094. > > I said: > > Doesn't that mean that the comment is misleading? I interpret it as > > saying that a Fortran "default integer" is always the same as a C > > "int". I believe that you are saying that it really means that > > *any* kind of Fortran integer must be the same as one of C's > > integral types, or OpenMPI won't support it at all. Shouldn't the > > comment be clearer? > > I believe that you are talking about a different comment: > > * RHC: technically, use of the ompi_ prefix is > > * an abstraction violation. However, this is actually > > * an error in our configure scripts that transcends > > * all the data types and eventually should be fixed. > > * The guilty part is f77_check.m4. Fixing it right > > * now is beyond a reasonable scope - this comment is > > * placed here to explain the abstraction break and > > * indicate that it will eventually be fixed > > I don't know whether anyone is using either of these comments to > justify anything. > > Iain > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel -- ------------------------------------------------------------------------ Rainer Keller, PhD Tel: +1 (865) 241-6293 Oak Ridge National Lab Fax: +1 (865) 241-4811 PO Box 2008 MS 6164 Email: kel...@ornl.gov Oak Ridge, TN 37831-2008 AIM/Skype: rusraink
