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-2008AIM/Skype: rusraink
