Go to the first, previous, next, last section, table of contents.


CMPAMBIG

Ambiguous use of intrinsic intrinsic ...

The type of the argument to the invocation of the intrinsic intrinsic is a COMPLEX type other than COMPLEX(KIND=1). Typically, it is COMPLEX(KIND=2), also known as DOUBLE COMPLEX.

The interpretation of this invocation depends on the particular dialect of Fortran for which the code was written. Some dialects convert the real part of the argument to REAL(KIND=1), thus losing precision; other dialects, and Fortran 90, do no such conversion.

So, GNU Fortran rejects such invocations except under certain circumstances, to avoid making an incorrect assumption that results in generating the wrong code.

To determine the dialect of the program unit, perhaps even whether that particular invocation is properly coded, determine how the result of the intrinsic is used.

The result of intrinsic is expected (by the original programmer) to be REAL(KIND=1) (the non-Fortran-90 interpretation) if:

The result of intrinsic is expected (by the original programmer) to be REAL(KIND=2) (the Fortran 90 interpretation) if:

Once you have determined whether a particular invocation of intrinsic expects the Fortran 90 interpretation, you can:

If you don't want to change the code, and you are certain that all ambiguous invocations of intrinsic in the source file have the same expectation regarding interpretation, you can:

See section REAL() and AIMAG() of Complex, for more information on this issue.

Note: If the above suggestions don't produce enough evidence as to whether a particular program expects the Fortran 90 interpretation of this ambiguous invocation of intrinsic, there is one more thing you can try.

If you have access to most or all the compilers used on the program to create successfully tested and deployed executables, read the documentation for, and also test out, each compiler to determine how it treats the intrinsic intrinsic in this case. (If all the compilers don't agree on an interpretation, there might be lurking bugs in the deployed versions of the program.)

The following sample program might help:

      PROGRAM JCB003
C
C Written by James Craig Burley 1997-02-23.
C Contact via Internet email: burley@gnu.org
C
C Determine how compilers handle non-standard REAL
C and AIMAG on DOUBLE COMPLEX operands.
C
      DOUBLE COMPLEX Z
      REAL R
      Z = (3.3D0, 4.4D0)
      R = Z
      CALL DUMDUM(Z, R)
      R = REAL(Z) - R
      IF (R .NE. 0.) PRINT *, 'REAL() is Fortran 90'
      IF (R .EQ. 0.) PRINT *, 'REAL() is not Fortran 90'
      R = 4.4D0
      CALL DUMDUM(Z, R)
      R = AIMAG(Z) - R
      IF (R .NE. 0.) PRINT *, 'AIMAG() is Fortran 90'
      IF (R .EQ. 0.) PRINT *, 'AIMAG() is not Fortran 90'
      END
C
C Just to make sure compiler doesn't use naive flow
C analysis to optimize away careful work above,
C which might invalidate results....
C
      SUBROUTINE DUMDUM(Z, R)
      DOUBLE COMPLEX Z
      REAL R
      END

If the above program prints contradictory results on a particular compiler, run away!


Go to the first, previous, next, last section, table of contents.