- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Am I correct to assume that it is impossible in the Intel Visual Fortran compiler 10.1, to use arguments in routines that are extended/quadruple precision?
Initially I had written my code in double precision, though recently I found out that double precision aint precise enough to obtain the correct results, thus I tried changing my fortran code to a version with extended or quadruple precision, using REAL(16) and COMPLEX(16). This includes (dummy) arguments of functions and subroutines, the call statements of each and every subroutine or function now gives the following error:
Error: The type of the actual argument differs from the type of the dummy argument.
Which certainly seems odd to me since I am 100% sure that the actual and the dummy arguments do have equal types.
As a test I have tried to generalize my code by changing any REAL(n) to REAL, deleting any kinds n specified and I added the compiler option: /real-kind:##. First, I tried the compiler-option /real-kind:64 and I was able to build my code without a single error, subsequently I changed the compiler-option to /real-kind:128 and my build suddenly was flooded with errors, such as the one specified above. If anyone could shed some light on the matter I would dearly appreciate it.
Jeroen H
Am I correct to assume that it is impossible in the Intel Visual Fortran compiler 10.1, to use arguments in routines that are extended/quadruple precision?
Initially I had written my code in double precision, though recently I found out that double precision aint precise enough to obtain the correct results, thus I tried changing my fortran code to a version with extended or quadruple precision, using REAL(16) and COMPLEX(16). This includes (dummy) arguments of functions and subroutines, the call statements of each and every subroutine or function now gives the following error:
Error: The type of the actual argument differs from the type of the dummy argument.
Which certainly seems odd to me since I am 100% sure that the actual and the dummy arguments do have equal types.
As a test I have tried to generalize my code by changing any REAL(n) to REAL, deleting any kinds n specified and I added the compiler option: /real-kind:##. First, I tried the compiler-option /real-kind:64 and I was able to build my code without a single error, subsequently I changed the compiler-option to /real-kind:128 and my build suddenly was flooded with errors, such as the one specified above. If anyone could shed some light on the matter I would dearly appreciate it.
Jeroen H
Link Copied
2 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jeroen,
Try deleting any file.mod and file_mod.* files that may have been created as well as any intermediary files that may have been created by gen-interfaces, check-interfaces. Also it may help if you declare interface blocks for the subroutine and functions. Keep the default real kind to 4 or 8 bytes.
If you still have problems then encapsulating the real(16) inside a user defined type and pass that around.
One of the Intel guys (gals) may have something better to say about this.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Very much to my surprise, deleting all module files (file.mod and file_mod.*) and rebuilding the solution actually did the job for me. Right now I am using the default real kind on 8 bytes and changed the parts of my program where its needed to real(16)/complex(16). Every now and than when I change something I still get the previously described error, but then I just delete the module files, after that everything works fine,
so thanks for the help!
Jeroen H
so thanks for the help!
Jeroen H
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page