Porting fortran program-compile error ambiguous use of intrinsic Real

[saleemhasan]

Hello,

I had started an earlier thread on porting this same program to linux. In that thread I had asked about padding (align) issues. It may turn out that the padding messages may only be warnings and I have shelved that problem. A more critical issue is the one error on ambiguous use of intrinsic Real.

Ambiguous use of intrinsic `REAL' at (^) [info -f g77 M CMPAMBIG]
maindpx.f:2862:
HD(I,J) = DCMPLX(DBLE(REAL(H(I,J))),DBLE(DIMAG(H(I,J))))
^
Ambiguous use of intrinsic `REAL' at (^) [info -f g77 M CMPAMBIG]
make: *** [maindpx.o] Error 1

I went to the info page for gcc
http://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77/CMPAMBIG.html

From what I could decipher, f90 interprets the use of intrinsic Real differently than other compilers. The gcc.gnu page also gives two different compile commands for f90 and nof90 interpretation.

James Craig Burley, who presumably wrote the man page, graciously included a short fortran program that can identify whether the compiler uses the f90 interpretation or the nof90. This will allow me to identify how the Real is interpreted on the compiler where our program runs fine. I will also run the short program by JC Burley on the linux to determine its interpretation.

PROGRAM JCB003
C
C Written by James Craig Burley 1997-02-23.
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

I tried to compile this program on linux and got three types of errors

[hasan@dual ~]$ f77 ambig.f
ambig.f:3:
C Written by James Craig Burley 1997-02-23.
^
Invalid form for PROGRAM statement at (^)
ambig.f: In program `MAIN__':
ambig.f:13:
R = REAL(Z) - R
^
Ambiguous use of intrinsic `REAL' at (^) [info -f g77 M CMPAMBIG]
ambig.f:18:
R = AIMAG(Z) - R
^
Ambiguous use of intrinsic `AIMAG' at (^) [info -f g77 M CMPAMBIG]
ambig.f: Outside of any program unit:
ambig.f:22:
C
^
Continuation indicator at (^) invalid on first non-comment line of file or following END or INCLUDE [info -f g77 M LEX]
ambig.f:23:
C Just to make sure compiler doesn't use naive flow

I do not know anything about the first error. The second one about Ambiguous use is the problem that I am trying to solve. It appears when I compile our program on linux. The third error, continuation indicator - C (comment line) is on the 6th column. It may be appearing due to some earlier problem

I would appreciate it if someone could help interpret these error messages and to get the program to compile. I will try the two different commands (for f90 and nof90 interpretation) with this program to resolve the ambiguity issue. However, I cannot do that until the other errors have been corrected.

I copied the JC Burley program from the internet and pasted it into notepad in windows and saved it as a text file so that there would not be problems with control characters such as new line or carriage return. Later, I copied and pasted it into a file using the vi editor.

Thank you.

Edit: As expected, when I compile the JC Burley program with f90 or nof90 commands, the ambiguity error goes away. However, the Invalid form for PROGRAM statement error and the continuation indication errors remain.

 

[saleemhasan]

OK, so I solved the compile errors. The comment statements should have had the C in column 1 instead of column 6 which is for continuation statements. Now, I have to figure out (using this program) how the intrinsic Real is interpreted by the compilers with which the programs runs (sgi irix) as well as those where the program still does not run (RedHat EL 5 and Centos 5.9).

 

[saleemhasan]

I used the two different compile options: 1. that uses f90 interpretation for intrinsic reals and 2. that uses nof90 interpretation. In the program that I am trying to port, there are two make files that have to be compiled. The first make file compiled fully with both the first and the second options. Even though the padding warnings are still appearing, the compilation was complete and the object files were created.

The second make file however, does not compile. Although, I cannot find any error (except at the end, it says Error 1), there the following warnings:

Common block `headin' is 38520 bytes in length at (1) but 113 bytes at (2)
setup1dpx.f: In subroutine `rhocor':
setup1dpx.f:5263: warning:
COMMON/HEADIN/HEAD(12),DDAT,DZEIT,VTITLE,CTITLE,PTITLE

I found the following explanation on the internet at http://lists.apple.com/archives/fortran-dev/2004/Jul/msg00026.html

...My guess with the common blocks problem is that the variable "temp" is being
declared double precision (real*8) in some routines, but not others. This
would cause common blocks to have different lengths in different routines...

This person goes on to say that these are only warnings. In my case also, these are only warnings but the compilation does not go to completion. I saved the compile output in a file and searched for the error but could not find any. I do not believe the padding warnings are the problem because the other make file compiled with padding warnings.

 

[saleemhasan]

In my original post is the JC Burley test program to see how the compile interprets the intrinsic Real
I am expected to compile his program with the two different compile options below.

Compile with the g77 option -ff90, to enable the Fortran 90 interpretation.
Compile with the g77 options `-fno-f90 -fugly-complex', to enable the non-Fortran-90 interpretations.

When I compiled and executed the Burley program on the centos 5.9 linux to which I am trying to port our fortran program, the output was

REAL() is Fortran 90
AIMAG() is Fortran 90

[hasan@dual ~]$ f77 -fno-f90 -fugly-complex ambig.f
[hasan@dual ~]$ a.out

REAL() is not Fortran 90
AIMAG() is not Fortran 90

On the other hand, when I ran the same program on the sgi unix machine, it did not recognize the -ff90 or the other -fno-f90 and the -fugly-complex options. So I compiled it without any options and the output was

suphys 16% a.out
REAL() is not Fortran 90
AIMAG() is Fortran 90

In this case the Real() Not a Fortran 90 while the AIMAG() is Fortran 90

For the linux compiler, above both Real and AIMAG were either Fortran 90 or Not Fortran 90

J. C. Burly also says, "If the above program prints contradictory results on a particular compiler, run away!" :)

To sum it all up. I managed to compile (on the linux) one of the two make files. The problem with the other make file is described in the earlier post.

 

[LudusRex]

Hello,

Thank you for providing all the information about your issue. From what I can gather, the main problem seems to be the ambiguous use of the intrinsic Real in your program. This error occurs when the compiler is not able to determine which version of the Real function to use, either the Fortran 90 or the non-Fortran 90 version. This can happen if there are conflicting declarations or if the compiler is not able to interpret the code correctly.

To resolve this issue, you can try using the f90 or nof90 command as suggested by the gcc.gnu page. This will force the compiler to use a specific interpretation of the Real function. However, this may not solve the other errors that you are getting.

The Invalid form for PROGRAM statement error indicates that there is an issue with the format of the PROGRAM statement in your code. This could be due to incorrect syntax or a missing keyword. I would suggest checking the PROGRAM statement in your code and comparing it with the one in the JC Burley program to see if there are any differences.

The continuation indicator error is most likely due to the code not being properly formatted. In Fortran, the continuation character must be in the sixth column of the line and it must be followed by a space. Make sure that all your continuation characters are in the correct position and are followed by a space.

I hope this helps. Good luck with your program!