The initial value of variables was changed when switching from other subroutine

The initial value of variables was changed when switching from other subroutine


A problem is found that the value of a variable declared in one subroutine will be changed by the IVF compiler after the code direction is switched from another subroutines. I made a test to show the problem with a test code as shown below.

====================================test code=============================================

program main
    implicit double precision(A-H,O-Z)
    call entry1
    call sub2
    call entry2

    write(*,*) "Test end."


subroutine sub1
    implicit double precision(A-H, O-Z)
    entry entry1
    write(*,*) "Before switching from entry1 to sub2, Q: ", Q
    entry entry2
    write(*,*) "After the code switching from the sub2 to the sub1, Q:", Q

end subroutine sub1


subroutine sub2

implicit double precision(A-H,O-Z)

!!............. (no declaration and precess is related to the variable Q)


end subroutine sub2

====================================test code=============================================

A variable Q with an initial value 0.05 is declared in the sub1, while no process is applied in the sub2.

Main program will enter the sub1 through the entry1, return to the main, enter the sub2, return to the main, and then enter the sub1 through the entry2. The values of Q in the sub1 at the entry1 and entry2 are outputted on the monitor.

The result of the test is shown in the following figure. The value of Q before switching to the sub2 is the same as the declaration, while it changed to an extremely large negative value automatically when the code get back to the sub1 from the sub2.

The test code can work normally (Q values are the same) with the old Fortran compiler (e.g. Digital VIsual Fortran) so I think the problem would be due to the IVF.

Any suggestion?   


8 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

I am sorry, the figure didn't show in the post correctly.
Please check the figure at


You are confusing "declaration" with executable statements. Secondly, there is no "problem". The variable Q is a local variable in the subroutine. Regardless of the presence of ENTRY, local variables are, by default in IFort, not saved (whereas CVF, by default, saved local variables).

The history of variables is reproducible only within the subprogram to which they belong as local variables, and then only if they have values assigned before being used. The presence of ENTRY, a particular sequence of calls to subroutines, etc. -- such details are irrelevant because the Fortran standards are quite clear that the program behavior is "undefined" if undefined, i.e., uninitialized, local variables are used.

If you want Q to be saved across calls, add the SAVE attribute to the declaration of Q.

You may find this article helpful (in particular, read the section "Behavior differences")

Well you learn something new every day! I have never seen the ENTRY statement before in many years of using Fortran and now having seen its usage I hope to never see it again!

App4619, don't shy away from a feature because you've gotten, or seen someone get, burned by an example of misuse.

Using the burn, or should I say burn-not, as a premise for your programming practice, and the above example, you would then make the decision that all variables should be SAVE, eh?   ....

But then that would break code elsewhere, and this would place you in an avoidance-avoidance pickle.

ENTRY serves its purpose (served) in older code where you may not have had generic interfaces and/or optional number of arguments.

I am not suggesting you use ENTRY with today's language features, rather I am suggesting that if you see it used in older working code, that you do not take it out because of your distaste of its use.

Jim Dempsey

ENTRY statement has been marked as obsolescent in Fortran 2008 standard.  But one can expect that most compilers, including Intel Fortran, will keep supporting it for a long time, perhaps forever!  Sure, with all the features for modules, optional arguments, procedure overloading with generic interfaces, etc., there is no need for ENTRY statement in new code; in fact, it should be considered a major violation.  But with legacy code, I suppose one should keep the "don't fix if it ain't broken" rule in mind.

Legacy code often used ENTRY in a non-standard way, as evidenced by this thread.  The feature came in several incompatible proprietary varieties before it was added to F77, and typically source code was fixed just enough to run with a specific compiler option group.

Hi everyone,

Very appreciate the suggestions. I have fixed the phenomenon by turning on the function of "All variables save(Qsave)". The original code I used is legacy, which was programed based on F77. Hence, it uses lots of entry. However, there are other error occurs which didn't occur when execute with CVF. I think the "all variables save" breaks the legacy in somewhere, so I still debugging the code....

BTW, can you share more information about how to substitute the function of Entry with generic interface?

Leave a Comment

Please sign in to add a comment. Not a member? Join today