Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] MPI_REAL16
From: Iain Bason (Iain.Bason_at_[hidden])
Date: 2009-06-22 13:48:20


(Thanks, Nick, for explaining that kind values are compiler-dependent. I
was too lazy to do that.)

Jeff Squyres wrote:
> Given that I'll inevitably get the language wrong, can someone suggest
> proper verbiage for this statement in the OMPI README:
>
> - MPI_REAL16 and MPI_COMPLEX32 are only supported on platforms where a
> portable C datatype can be found that matches the Fortran type
> REAL*16, both in size and bit representation. The Intel v11
> compiler, for example, supports these types, but requires the use of
> the "_16" suffix in Fortran when assigning constants to REAL*16
> variables.

The _16 suffix really has nothing to do with whether there is a C
datatype that corresponds to REAL*16. There are two separate issues here:

   1. In Fortran code, any floating point literal has the default kind
      unless otherwise specified. That means that you can get surprising
      results from a simple program designed to test whether a C
      compiler has a data type that corresponds to REAL*16: the least
      significant bits of a REAL*16 variable will be set to zero when
      the literal is assigned to it.
   2. Open MPI requires the C compiler to have a data type that has the
      same bit representation as the Fortran compiler's REAL*16. If the
      C compiler does not have such a data type, then Open MPI cannot
      support REAL*16 in its Fortran interface.

My understanding is that the Intel representative said that there is
some compiler switch that allows the C compiler to have such a data
type. I didn't pay enough attention to see whether there was some reason
not to use the switch.

She also pointed out a bug in the Fortran test code that checks for the
presence of the C data type. She suggested using a _16 suffix on a
literal in that test code. Nick pointed out that that _16 suffix means,
"make this literal a KIND=16 literal," which may mean different things
to different compilers. In particular, REAL*16 may not be the same as
REAL(KIND=16).

However, there is no standard way to specify, "make this literal a
REAL*16 literal." That means that you have to do one of:

    * Declare the variable REAL(KIND=16) and use the _16 suffix on the
      literal.
    * Define some parameter QUAD using the SELECTED_REAL_KIND intrinsic,
      declare the variable REAL(KIND=QUAD), and use the _QUAD suffix on
      the literal.
    * Assume that REAL*16 is the same as REAL(KIND=16) and use the _16
      suffix on the literal.

That assumption turns out to be safer than one might imagine. It is
certainly true for the Sun and Intel compilers. I am pretty sure it is
true for the PGI, Pathscale, and GNU compilers. I am not aware of any
compilers for which it is not true, but that doesn't mean there is no
such compiler.

All of which is a long winded way of saying that maybe the README ought
to just say:

    MPI_REAL16 and MPI_COMPLEX32 are only supported on platforms where a
    portable C datatype can be found that matches the Fortran type
    REAL*16, both in size and bit representation.

Iain