/alt_kind does not work as intended for COMPLEX(4) type

Many legacy Fortran codes contain declarations of the type REAL4, INTEGER2, etc., with the expectation that the suffix number is the byte size of the variable (for COMPLEX, the suffix number is the byte size of each part, real and imaginary).

The alternative syntax, REAL(4), etc., is slightly less common, but FTN95 supports this syntax (and the *n type syntax) with the /alt_kinds option. This support does not work as expected for COMPLEX(4), which is rejected by FTN95 /alt_kind; the compiler accepts but with a non-traditional meaning the type COMPLEX(8).

The following program illustrates the inconsistency. Please see, for example, https://gcc.gnu.org/onlinedocs/gfortran/KIND-Type-Parameters.html#KIND-Type-Parameters , for a description of the traditional meaning of COMPLEX(4) and COMPLEX(8).

program tst
complex(4) x
complex(8) y
complex z
complex*16 w

write(*,10)'COMPLEX(4) : ',kind(x),range(x),precision(x)
write(*,10)'COMPLEX(8) : ',kind(y),range(y),precision(y)
write(*,10)'COMPLEX    : ',kind(z),range(z),precision(z)
write(*,10)'COMPLEX*16 : ',kind(w),range(w),precision(w)

10 format(A13,3i5)
end program

The two lines that pertain to x are rejected by FTN95 with the /alt_kinds option. Furthermore, FTN95 regards the complex variable y as a pair of 4-byte reals, whereas y is expected to be a pair of 8-byte reals.

The results from GFortran and Intel Fortran:

COMPLEX(4) :     4   37    6
COMPLEX(8) :     8  307   15
COMPLEX    :     4   37    6
COMPLEX*16 :     8  307   15

With the lines containing the variable x commented out, FTN95 /alt_kinds gives:

COMPLEX(8) :     4   37    6
COMPLEX    :     4   37    6
COMPLEX*16 :     8  307   15

Thank you for the feedback.

FTN77, FTN90 and FTN95 have always used COMPLEX8 and COMPLEX16 so it is unfortunate that this is different from other compilers.

It is not obvious to me how this can be resolved other than by adding another compiler option to FTN95 in order to allow the new alternative kinds. In view of the existing complexity of alternatives within FTN95, this could be quite tricky.

Do you have any thoughts on how to resolve this issue either by adapting your code or by our changing FTN95?

Paul, there is no issue with COMPLEX8 and COMPLEX16, and declarations of this type, though not specified in the Fortran standard, are allowed by all Fortran compilers (F77 and later, at least).

The issue is with specifying a variable to be COMPLEX(n), where n is a literal constant. The Fortran 95 standard (draft version at http://j3-fortran.org/doc/standing/archive/007/97-007r2/pdf/97-007r2.pdf ) says in 4.3.1.3, second paragraph:

A kind type parameter may be specified for a complex entity and selects for both parts the real approximation method characterized by this kind type parameter value.

The standard does not specify the kind numbers to be used, but does constrain their choice. Therefore, when a vendor allows COMPLEX(8), either natively or optionally through a switch such as /ALT_KINDS, the kind number 8 must be the value returned by the KIND intrinsic function for the complex variable, its real part and its imaginary part. FTN95 with /ALT_KINDS, however, returns the kind number 4 for all three. I think that the constraint in the standard is violated.

I strongly think that /ALT_KINDS should be fixed. Creating a new compiler option is not indicated -- I doubt that any user of FTN95 uses COMPLEX(8) with the expectation that such variables are made up of a pair of 32-bit floats. Perhaps the question could be posed to the forum members.

Thank you for the clarification. I will make a note that it needs to be fixed. If anyone has used COMPLEX(8) in their existing code then the fix will given them more precision and so should not be a problem.

I hope that you will concede that having smilies in Fortran source code is non-traditional!

One of the user preferences/settings of these forums allows you to choose if smilies are displayed with emoticons.

This has now been fixed for the next release.