Standards question regarding intrinsics with complex arguments

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 support 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

.

Relevant Pages

  • Re: Standards question regarding intrinsics with complex arguments
    ... precision on all IBM machines. ... these arguments) is not permitted by the Fortran 95 standard. ... 1501-510 Compilation successful for file test_cmplx.f90. ... A kind type parameter ...
    (comp.lang.fortran)
  • Re: C# -- Good or Bad?
    ... ECMA standard. ... These implementations use JIT compilation, ... > need languages which allow to work close to the hardware, ... Finally, I'd note that in some cases, interpretation can actually ...
    (comp.lang.cpp)
  • Re: Inconsistent Program Results
    ... including one of them might trivially slow down compilation, ... I wrote the above (starting with "The standard headers"). ... return void, but there's no advantage in using that. ... You're cheating yourself by ignoring warning messages. ...
    (comp.lang.c)
  • Re: Forth Frustrations
    ... information on the data stack all the way through compilation, ... Forth-like language, not on top of ISO Forth. ... Forth-94 on top of my simpler language. ... compiler that fits the new simpler "standard", it will be easy to add ...
    (comp.lang.forth)
  • Re: SAME AS (02 Standard) Clause - and circulatiy
    ... "the standard does NOT tell implementers in what order ... As far as "6.4 Logical conversion" as described on page 28 and following, ... "If the compilation stage were described in such terms, ...
    (comp.lang.cobol)
Quantcast