Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
29001 Discussions

Why the result depends on -g option and type of function

V__Vadim
Beginner
498 Views

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

0 Kudos
3 Replies
TimP
Honored Contributor III
498 Views

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.  

0 Kudos
Martyn_C_Intel
Employee
498 Views

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.

0 Kudos
V__Vadim
Beginner
498 Views

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.

0 Kudos
Reply