Fortran Porting fortran program-compile error ambiguous use of intrinsic Real

  • Thread starter Thread starter saleemhasan
  • Start date Start date
  • Tags Tags
    Error Fortran
AI Thread Summary
The discussion focuses on porting a Fortran program to Linux, highlighting issues with ambiguous use of the intrinsic `REAL` function and various compilation errors. Initially, padding warnings were noted but deemed less critical than the ambiguous `REAL` error encountered during compilation. The user successfully compiled a test program by James Craig Burley to determine how different compilers interpret `REAL`, revealing that the Linux compiler treats both `REAL` and `AIMAG` as Fortran 90, while the SGI Unix machine does not recognize the Fortran 90 options. Despite resolving some compilation issues, a second make file fails to compile, attributed to potential discrepancies in common block variable declarations. Overall, the user is working to understand and resolve these compilation challenges across different environments.
saleemhasan
Messages
9
Reaction score
0
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.
 
Last edited:
Technology news on Phys.org
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).
 
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.
 
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.
 
Dear Peeps I have posted a few questions about programing on this sectio of the PF forum. I want to ask you veterans how you folks learn program in assembly and about computer architecture for the x86 family. In addition to finish learning C, I am also reading the book From bits to Gates to C and Beyond. In the book, it uses the mini LC3 assembly language. I also have books on assembly programming and computer architecture. The few famous ones i have are Computer Organization and...
I had a Microsoft Technical interview this past Friday, the question I was asked was this : How do you find the middle value for a dataset that is too big to fit in RAM? I was not able to figure this out during the interview, but I have been look in this all weekend and I read something online that said it can be done at O(N) using something called the counting sort histogram algorithm ( I did not learn that in my advanced data structures and algorithms class). I have watched some youtube...

Similar threads

Replies
16
Views
2K
Replies
6
Views
3K
Replies
2
Views
3K
Replies
2
Views
3K
Replies
1
Views
3K
Replies
1
Views
3K
Replies
2
Views
5K
Replies
5
Views
3K
Replies
2
Views
6K
Back
Top