ieee_get_flag behavior varies for externally linked procedures?

[kostas85]

Hello all, 

I have noticed a wierd behavior when using ieee_get_flag.

As an example consider the following.

Compiling the following as a whole (from a single .f90 file, without any compilation options), gives a False for the ieee_invalid flag for 0/0 [ attached file test2.f90 ]:

[fortran] 

module my_subs

implicit none

contains

subroutine NaNsub(r1)
real,intent(out) :: r1
r1 = 0./0.
end subroutine NaNsub

end module my_subs

program test2

use ieee_exceptions
use my_subs

implicit none

logical :: NaN_found
real :: r1

call NaNsub(r1)

call ieee_get_flag(ieee_invalid,NaN_found)

print *, NaN_found

end program test2

[/fortran]

However, if I put the module in a seperate file [test3.f90 + NaNsub.f90] compile it and link it to the main code the answer flag becomes true (no compilation options). So I think that something strange happens. Could you please check if you can reproduce this ? Could this behavior be related to the default optimizations used? I'm using v13.1.2 running in Ubuntu 13.01. 

Many Thanks,

Kostas

[Steven_L_Intel1]

You need to compile with -fp-model strict when using the IEEE modules or trying things such as 0./0..  Does this help?

[Steven_L_Intel1]

I would also recommend using IEEE_VALUE(0.,IEEE_SIGNALING_NAN) rather than rolling your own NaN.

[kostas85]

Hello Steve,

Thank you very much for your answer. 
Indeed using -fp-model strict (or removing the optimizations say -check all) gives the desired answer. But still, does this explain the same code having a different behavior based on whether:

1. I compile the module and main both included in the same .txt file : test2.f90

        ifort test2.f90
        -> gives False 

2. I compile the module first (or just the subroutine - nansub.f90) and link it to the the main (test3.f90)

         ifort -c nansub.f90
         ifort test3.f90 nansub.o
         -> gives True

So the same code has produces a different based on whether the linking is implied or not. Should this happen ? Shouldn't I obtain the same result independently on how the executable is produced (when using default compilation options)? 

Thank you!

Kostas

[Steven_L_Intel1]

No - when you have the caller and callee together, the optimizer can inline the call and it may do additional optimizations that interfere with your assumptions about IEEE behavior. With the separate compilation it can't do that (unless you also use -ipo).

[kostas85]

Thank you Steve!

-ipo produces false in both cases

So would you suggest -ipo as a recommended practise when linking seperately ?

[Steven_L_Intel1]

-ipo is an optimization option. If your program is correct, it should not change the behavior. In your case, it was the missing -fp-model that caused the problem. You are encouraged to use -ipo to improve performance of applications, as long as you understand that it will increase build time and resource usage.