Hello,
Compilation of the following test code
PROGRAM test_cmplx
! Double precision
INTEGER, PARAMETER :: dp = SELECTED_REAL_KIND(15)
! Variables
COMPLEX(dp) :: z
REAL(dp) :: x, y
! Assign a value to the complex number
z = CMPLX(3.14159_dp,-0.12345_dp,dp)
PRINT *, z
! Split out the parts
x = REAL(z,dp); y = AIMAG(z)
PRINT *, x, y
END PROGRAM test_cmplx
on an IBM P6 using the AIX v11.1 xlf95 compiler with the -qlanglvl=95pure
switch produces
the output:
v1n3:scratch : xlf95 -qlanglvl=95pure test_cmplx.f90
"test_cmplx.f90", line 13.7: 1518-256 (L) The intrinsic procedure real
(with
these arguments) is not permitted by the Fortran 95 standard.
"test_cmplx.f90", line 13.23: 1518-256 (L) The intrinsic procedure aimag
(with
these arguments) is not permitted by the Fortran 95 standard.
** test_cmplx === End of Compilation 1 ===
1501-510 Compilation successful for file test_cmplx.f90.
I believe the code in question is standard Fortran95 and that the compiler
is
incorrect in producing these warnings. Section 4.3.1.3 (Complex Types) of
the Fortran95
standard states:
"Each approximation method used to represent data entities of
type real shall be available for both the real and imaginary
parts of a data entity of type complex. 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."
Section 13.14.6 of the Fortran95 standard states:
AIMAG (Z)
Description. Imaginary part of a complex number.
Class. Elemental function.
Argument. Z shall be of type complex.
Result Characteristics. Real with the same kind type parameter as Z.
Result Value. If Z has the value ( ), the result has value .
Example. AIMAG ((2.0, 3.0)) has the value 3.0.
and Section 13.14.88 of the Fortran95 standard states (case(ii) is the
pertinent one here):
REAL (A [, KIND])
Description. Convert to real type.
Class. Elemental function.
Arguments.
A shall be of type integer, real, or complex.
KIND (optional) shall be a scalar integer initialization expression.
Result Characteristics. Real.
Case (i): If A is of type integer or real and KIND is present,
the kind type parameter is that specified by KIND. If
A is of type integer or real and KIND is not present,
the kind type parameter is the processor-dependent kind
type parameter for the default real type.
Case (ii): If A is of type complex and KIND is present, the kind
type parameter is that specified by KIND. If A is of type
complex and KIND is not present, the kind type parameter
is the kind type parameter of A.
Result Value.
Case (i): If A is of type integer or real, the result is equal to a
processor-dependent approximation to A.
Case (ii): If A is of type complex, the result is equal to a
processor-dependent approximation to the real part of A.
Examples. REAL (-3) has the value -3.0. REAL (Z) has the same kind
type
parameter and the same value as the real part of the complex
variable Z.
An IBM person has since told me that:
<quote>
....I suspect the standard does not require an implementation to sup****t
any precision in
complex intrinsic functions other than the default. Therefore aimag(z) is
only standards
compliant if z is a default precision complex number.
</quote>
I replied that I disagreed since the above quotes from the standard do not
contain any
mention of a restriction for default types only.
I should also note that this happens with the compiler for intrinsics with
complex
arguments in general (e.g. SIN or EXP). In these cases the results
characteristics state
they should be the same as the argument, and there is no restriction
placed on the kind
type of the argument.
The v10 xlf95 compiler did not produce these warnings for the same code.
It has been recommended I simply don't use the standards compliance check
flag with v11.1
so as to remove the warnings during compilation. Not ideal.
Any language lawyers out there care to offer an opinion on any of this?
cheers,
paulv
|
