Compilation of f77 with intel2016: runs but all 0

[Christophe_O_]

Dear programmers,

In principle I develop my codes with C++/Python but today I am one of those lucky guys that must use a legacy code in fortran 77 parallelized with MPI. I have been using this code for years and it has been compiled and worked with different compilers, among which, intel 10.

Now we have installed the intel 2016 and it no longer works. It compiles successfully, runs...but the result is unexpected. All the data are 0.

Does it sound familiar to you? Do you know any compilation option to comply with the f77 standard and that could help me detect any error due to old format (for instance)?

I thank you very much in advance for any help.

Christophe

[Christophe_O_]

Reply to #21: The fact that in the case of intel-10 it is the file singleb.f that is compiled and, in the case of intel-2016 it is tabex.f, is just chance. I stopped the compilation of the code randomly to catch the options. There are many files to be compiled in this code. No problem there. Both singleb.f and tabex.f are compiled in each version.

Reply to #20: Difficult to see where both versions differ. With intel-10 it works, with intel-2016, it runs but just returns all 0. Since there are tens of subroutines/functions, thousands of lines, hard to know where to begin...I guess I'll have to do some sort of speleology in the code :-).

I'll let you know if I find something.

Christophe

[jimdempseyatthecove]

try adding option -nostandard-realloc-lhs

This option determines whether the compiler uses the current Fortran Standard rules or the old Fortran 2003 rules when interpreting assignment statements.

Option standard-realloc-lhs (the default), tells the compiler that when the left-hand side of an assignment is an allocatable object, it should be reallocated to the shape of the right-hand side of the assignment before the assignment occurs. This is the current Fortran Standard definition. This feature may cause extra overhead at run time. This option has the same effect as option assume realloc_lhs.

If you specify nostandard-realloc-lhs, the compiler uses the old Fortran 2003 rules when interpreting assignment statements. The left-hand side is assumed to be allocated with the correct shape to hold the right-hand side. If it is not, incorrect behavior will occur. This option has the same effect as option assume norealloc_lhs.

Jim Dempsey

[jimdempseyatthecove]

A second potential issue is whether or not the local declared arrays are implicitly SAVE or implicitly AUTOMATIC.

Jim Dempsey

[Christophe_O_]

Reply to #23: I tried option -assume norealloc_lhs and -assume realloc_lhs.  No effect.

Reply to #24: There are many SAVE statements in this code. No AUTOMATIC statement was found.

Christophe

[jimdempseyatthecove]

>>Reply to #24: There are many SAVE statements in this code. No AUTOMATIC statement was found.

The situation is NOT that you have explicitly SAVE or AUTOMATIC variables, but rather what the compiler implicitly does with locally declared arrays. Depending on compiler options, or lack thereof, a local array

real :: array(3,3)

The array may be save or automatic. When compiled with -auto, or -recursive, or -qopenmp (and I am guessing possibly when specifying mkl due to mkl using openmp) the local array is automatic. This will result in values not being preserved across calls. Without these options (and potentially without mkl) then local arrays are defaulted to SAVE... Excepting that newer Fortran standards ?F2008? may change the default behavior, thus requiring older programs to supply an option to revert back to older behavior.

You might try:     -noauto

** test the correctness of the program afterwards.

If (strong) this corrects this problem, or at least moves the problem, then this indicates that the programmer made assumptions about the default behavior of the compiler (code works in one compiler and not in another). If this is the case, then you have some deal of work to correct the program.

Often, when a program subroutine returns all 0's, it usually ends up being the code checks a condition to see if a loop is complete. This can be the result of testing an uninitialized (undefined) variable and in which the "junk" data causes the loop to exit before doing any work. A different situation is in code that test for convergence without regard to the precision of the calculations (e.g. using hard wired small numbers).

Jim Dempsey