- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Just a small program.
REAL(8) FUNCTION DUMMY(i) implicit none integer, intent(in) :: i DUMMY=dble(i) write(*,*) 'i=', dble(i),'res=',DUMMY RETURN END FUNCTION program test real(8) :: xxx xxx=DUMMY(2) write(*,*) 'xxx=',xxx stop end program
If I do ifort -o test test.f the result is
i= 2.00000000000000 res= 2.00000000000000
xxx= 2.00000000000000
But with ifort -g -o test test.f the result is
i= 2.00000000000000 res= 2.00000000000000
xxx= 0.000000000000000E+000
The result is also depend on type of my function. If I put REAL DUMMY(i) instead of REAL(8) DUMMY(i) then the result will be always correct.
ifort -V
Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 14.0.2.144 Build 20140120
Copyright (C) 1985-2014 Intel Corporation. All rights reserved.
FOR NON-COMMERCIAL USE ONLY
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As you've demonstrated, incorrect interfaces aren't guaranteed to behave the same when you vary compiler options. Presumably, interprocedural optimizations when you don't set -g have saved you in this case.
In case you still want to use Fortran styles of 30 years ago, ifort offers the option -warn interfaces
People who got used to Compaq Fortran, which had only the equivalent of ifort ia32 /arch:IA32 x87 stack register function value return, may have thought this aspect of Fortran rules could be ignored.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As Tim implies, the issue arises because you don't declare DUMMY as REAL(8) in your main program.
Beyond that, -g changes the default optimization level from -O2 to -O0. At -O2, DUMMY gets inlined, so the compiler can see and cope with the argument mismatch, as Tim says. At -O0, the inlining is disabled, so the function result gets passed back incorrectly - the main program expects and uses only 32 bits, not 64.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks a lot.
You are right. I have to declare explicitly type of my function and check interfaces.
"the main program expects and uses only 32 bits, not 64." is logical, but It is surprise for my.
Thus the agreement on implicit types of variables don't applicable to functions.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page