Incorrect results from optimised code with 2016 ifort

[Richards__Simon]

We have discovered an error which only occurs in optimised (-O2) code. The following example illustrates the problem. Note that this is cut down version of the full production code just to illustrate the problem

MODULE mod1
  IMPLICIT NONE
  TYPE neuts_type
    INTEGER, POINTER :: no_total=>null()
    INTEGER, POINTER :: no_prompt=>null()
  END TYPE neuts_type
  TYPE (neuts_type), SAVE :: neuts

CONTAINS
  SUBROUTINE cp_file1(neuts_out)
    TYPE(neuts_type), INTENT(INOUT) :: neuts_out
    INTEGER, TARGET, SAVE  :: total_neuts=0
    CALL total()
    total_neuts = neuts_out%no_total
    neuts_out%no_prompt => total_neuts
    total_neuts = neuts_out%no_prompt 
    neuts_out%no_total => total_neuts
  CONTAINS
    SUBROUTINE total()
      INTEGER, TARGET, SAVE :: no_neutrons=0
      REAL, TARGET, SAVE :: nubar=0.0
      no_neutrons = 4
      neuts_out%no_total => no_neutrons
    END SUBROUTINE total
  END SUBROUTINE cp_file1
 
END MODULE mod1

PROGRAM abc
  USE mod1
  IMPLICIT NONE
  CALL cp_file1(neuts)
  PRINT *,neuts%no_total
END PROGRAM abc

This code should produce the answer neuts%no_total=4, but if I build this with -O2 using the 2016 version of the ifort compiler it produces the answer neuts%no_total=0. If I build with -O0 it produces the correct answer, so the issue only occurs with optimised code. I have also tried using gfortran, NAG fortran and the 2017 version of ifort and the results are correct in all cases, so only the 2016 compiler demonstrates the issue. Unfortunately 2016 is our current release version as we need to support RHEL5 users.

The issue appears to be related to the assignments and pointer associations after the call to total(). I realise that these lines appear confusing and redundant, but that is because this is a cut down version of something which is more complicated in the production code. The error has been fixed in the production code by some minor code changes, but what I really want to understand is why we are seeing this error in the first place. Is this caused by a bug in the compiler or is there something wrong with the Fortran? Thanks.

[Steve_Lionel · Accepted solution]

You have provided fairly solid evidence of a compiler bug, and also that the bug is not present in newer versions (it seems ok in version 19 as well.) 

[Juergen_R_R]

Yep, indeed, if I do a print statement in the cp_file1 (forcing a side-effect), also ifort v16 produces the correct result. So indeed an optimization bug.