Ah - thanks for clarifying, George, on both counts! :-) On Wed, Jun 3, 2009 at 11:43 AM, George Bosilca <bosi...@eecs.utk.edu>wrote:
> > On Jun 3, 2009, at 13:30 , Ralph Castain wrote: > > I'm not entirely sure what comment is being discussed. The comment in >> opal/util/arch.c (written by me long ago) should not be taken seriously - it >> was nothing more than a half-hearted attempt to appease the stormy >> controversy (mostly objections from George and a little from Brian) created >> by my moving this code to OPAL. It had no technical validity behind it at >> all. >> >> Somewhat amusing to see that comment now used as justification for leaving >> the code there by some of the same people. ;-) >> > > I think there is a misinterpretation of my justification. The architecture > code was, from the beginning, specifically crafted for the datatype engine. > Using it elsewhere, might make sense, however only the datatype engine can > really take full advantage of it. Therefore, I believe this code should stay > inside the datatype engine, whatever layer in Open MPI this engine will be. > > The question of whether or not we accurately deal with Fortran variable >> sizes was always present, even when this code was in the OMPI layer. It is a >> tad troublesome as Fortran advocates -do- occasionally set the flags that >> can cause the variables to differ from their C counterparts. Rather than >> some obscure comment in the source code, we should probably generate a >> warning and (hopefully) abort when someone uses those flags to avoid >> creating hard-to-debug errors. >> > > Most types existing in other programming languages will be supported to a > certain extent. As an example, all Fortran integer types __WILL__ be > supported. One notable exception will be the "QUAD" floating point type > provided by the Fortran compiler. While there is a similar type in C, it is > compiler and platform dependent, and the representation of the C and the > Fortran type differs. As a result, even if we would like to support this > type, we will not be able to do the conversions (by lack of knowledge about > the internal representation). > > However, this is the only type I'm aware of that we will not be able to > support. In fact, this type is not supported today in Open MPI, so there > will be no lost of functionality. > > george. > > > >> >> On Wed, Jun 3, 2009 at 10:58 AM, Iain Bason <iain.ba...@sun.com> wrote: >> >> On Jun 2, 2009, at 10:24 AM, Rainer Keller wrote: >> >> 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. >> The representation chosen is set in opal/util/arch.c and is conclusive as >> far >> as I can tell... >> >> 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? >> >> Iain >> >> >> _______________________________________________ >> devel mailing list >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel >> >> _______________________________________________ >> devel mailing list >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel >> > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel >
