Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] opal / fortran / Flogical
From: Ralph Castain (rhc_at_[hidden])
Date: 2009-06-03 13:47:36


Ah - thanks for clarifying, George, on both counts! :-)

On Wed, Jun 3, 2009 at 11:43 AM, George Bosilca <bosilca_at_[hidden]>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.Bason_at_[hidden]> 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
>> devel_at_[hidden]
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>
>> _______________________________________________
>> devel mailing list
>> devel_at_[hidden]
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>
>
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>