Missing C declaration for MPI_REAL2 and implementation for MPI_COMPLEX4

[omor1]

ompi/include/mpi.h.in is missing a declaration for MPI_REAL2. The datatype exists (ompi_mpi_real2), but the macro is missing.
It should be as simple as adding the following:

#if OMPI_HAVE_FORTRAN_REAL2
#define MPI_REAL2 OMPI_PREDEFINED_GLOBAL(MPI_Datatype, ompi_mpi_real2)
#endif

A related issue is the missing MPI_COMPLEX4 type. This isn't as trivial as the above, but should follow the same patterns as for the other complex types. Of course, as per the MPI standard, it is optional; but since MPI_REAL2 is clearly supported, I don't think there's a reason for not supporting MPI_COMPLEX4.

[bosilca]

As there is no guarantee that the C half-precision is the same type as the REAL2 in Fortran, we have decided that language specific types should only be defined in that specific language.

I know there is a growing need for application for support for half-precision types, but the correct solution is a little bit more complex and extremely compiler-dependent.

[omor1]

That makes sense. While IEEE 754-2008 does specify a format for half-precision floating point types (binary16), it is not standardized in C, though it has been implemented as extensions in some compilers (for instance, I think GCC supports _Float16, though only on ARM and AArch64).
Why then is the ompi datatype declared in the C header (OMPI_DECLSPEC extern struct ompi_predefined_datatype_t ompi_mpi_real2;), if it's never meant to be used?

As for the second part, If a particular environment supports MPI_REAL2 (REAL*2), then it should also be able to support MPI_COMPLEX4 (COMPLEX*4), correct?

[bosilca]

This is actually pretty funny...

program main
   COMPLEX*4 :: bogus_variable
end program

generates a compilation error:

COMPLEX4 :: bogus_variable
1
Error: Old-style type declaration COMPLEX4 not supported at (1)

while

program main
   COMPLEX*8 :: bogus_variable
end program

compiles just fine.

[omor1]

That just means that the compiler doesn't support REAL*2 and COMPLEX*4.
In mpi.h, I have

#define OMPI_HAVE_FORTRAN_REAL2 0

so my compiler (GNU Fortran 6.3.0) doesn't support it either (and trying the same tests as you nets the same results).

However, if one does have a compiler with support for REAL*2 (and thus a defined MPI_REAL2 type in the Fortran Open MPI module), it presumably would have support for COMPLEX*4, so that MPI_COMPLEX4 could be defined as well.

[bosilca]

According to the gcc documentation COMPLEX*4 should always exist. Moreover, according to the same page, the kind for a complex type refers to each of it's components (imaginary and real part) so this is just puzzling.

[omor1]

I think I've figured out what's going on. When using old-style kind specifications, GCC states that

... size is a byte count corresponding to the storage size of a valid kind for that type. For COMPLEX variables, size is the total size of the real and imaginary parts.

For modern declarations (using KIND), it is as you stated,

The KIND value matches the storage size in bytes, except for COMPLEX where the storage size is twice as much (or both real and imaginary part are a real value of the given size).

So

COMPLEX*32 :: bogus_variable

is equivalent to

COMPLEX(KIND=16) :: bogus_variable

The GCC documentation states that it supports KIND parameters 4, 8, 10, and 16, with 4 being the default (unless -fdefault-real-8 is used) and 10 and 16 not available on all systems. This means that the smallest type is COMPLEX*8 (which is equivalent to COMPLEX(KIND=4)), which aligns with the previous tests.

[omor1]

The Intel documentation says the same thing. It does not appear to support REAL*2 and COMPLEX*4.

[kawashima-fj]

#6205 resolved the issue. MPI_REAL2 and MPI_COMPLEX4 macros will be defined in mpi.h if REAL*2 and COMPLEX*4 respectively are usable with your Fortran compiler. If some problems still exist, feel free to reopen the issue.