topic It is usually the case that in Intel® Fortran Compiler

-O0 modifies variable value

Stefanos_K_ — Sat, 16 Feb 2013 14:04:35 GMT

I came across a weird situation while trying to debug my code. I tried to reproduce it in a smaller program but unfortunately couldn't, so let me start by posting the relevant snippets:

[fortran]

subroutine sub(H)
    implicit none
    type(derived), intent(inout) :: H
    integer :: i, N
...
    N = size(H%field1) ! yields 24
...
        do i = 1,N
...
            print*,i,N
            call module_sub(H%field2,H%field3)
            print*,i,N

        end do
...
end subroutine sub

[/fortran]

The full program, including the module containing sub (file ops.f90), compiles OK:

[bash]

$ make
...
ifort -O0 -c ops.f90

...

$ ifort -V
Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 13.0.1.117 Build 20121010
Copyright (C) 1985-2012 Intel Corporation. All rights reserved.
FOR NON-COMMERCIAL USE ONLY

[/bash]

There are no warnings when compiled with any / all of -warn all -debug full -check all -check bounds. Here is the relevant output of the two print statements shown above:

[bash]

...

3 24
3 0

...

[/bash]

Note that the variable N is defined in the beginning and never touched again and that it is not passed to module_sub. It is only used as an upper DO-loop bound after the second print. There is no connection to global variables whatsoever. The weird behavior disappears for -O1 and above and the code always prints the same initial value of N (=24 in the example above).

Is there any O0-related reason why ifort changes the value of this variable? If not, is this perhaps a known issue? If not and not, would it make sense to provide the full code (modified version that makes it easy to spot the relevant point, of course)?

Thanks in advance.

Hi Stefane,

kostas85 — Sat, 16 Feb 2013 21:03:00 GMT

Hi Stefane,

I've just written a test program to simulate your case. If you don't describe mod_sub then its difficult to tell what's happening. Could you please write a toy module_sub that replaces my module_sub and does what yours is doing (or at least as similar as possible) ?

With the code I posted, I don't get the same behaviour (version 13.1.0.146), so in my opinion module_sub is essential.

BR,

Kostas

It is usually the case that

Steven_L_Intel1 — Sun, 17 Feb 2013 23:52:00 GMT

It is usually the case that when one can't reproduce the problem in a smaller case, the actual issue is somewhere different than you think. It is almost always the case that a "snippet" bears little or no bearing on the real problem.

You can run the program under the debuggger and step through it, watching the variable to see when and where it changes. This may give you a clue as to what is wrong. For problems such as this, it is almost always a coding error in the application.