Overwriting of variables in ifort 19 (19.0.0.117) when using -g flag

[Cibin_Joseph]

I'm running a numerical model that contains several class instances defined as modules. The code was validated using ifort17. However, on recently switching to ifort 19, I noticed--while using the -g flag--when a certain variable is initialized, unintended changes occur in other (independent) variables. It appears as if two variables share the same memory location. The following minimal example gives expected results when -O3 is used, but does not work when the -O0 and -g flags are used.

Minimal example:

main file:

program main
  use rotor_classdef

  type(rotor_class) :: rotor

  rotor%nx=2
  rotor%ny=5
  call rotor%init()

end program main

module file:

module rotor_classdef
  integer, parameter :: dp = kind(1.d0)    ! Double precision

  type rotor_class
    integer :: nx,ny
  contains
    procedure :: init
  end type rotor_class

contains

  subroutine init(this)
  class(rotor_class) :: this
    real(dp), dimension(this%nx) :: xvec
    real(dp), dimension(this%ny) :: yvec

    xvec=1._dp

    print*
    print*,'Value of xvec BEFORE assigning yvec'
    print*,xvec

    yvec=3._dp    ! ** This assignment appears to change the value of xvec **

    print*,'Value of xvec AFTER  assigning yvec'
    print*,xvec
    print*

  end subroutine init
end module rotor_classdef

when compiled with -O0 and -g flags, produces the output

 Value of xvec BEFORE assigning yvec
   1.00000000000000        1.00000000000000     
 Value of xvec AFTER  assigning yvec
   3.00000000000000        3.00000000000000     

instead of

 Value of xvec BEFORE assigning yvec
   1.00000000000000        1.00000000000000     
 Value of xvec AFTER  assigning yvec
   1.00000000000000        1.00000000000000     

Additional Details:

OS: Ubuntu 16.04

[new] ifort version: 19.0.0.117

[old/working] ifort version: 17.0.0

Any help in figuring out why this occurs is gratefully appreciated!

[Juergen_R_R]

I cannot reproduce your findings. Using Ubuntu 16.04 with the same build of ifort v19 that you use, I get two times 1.000 1.000.

[Cibin_Joseph]

I think the modules defined before this one have some sort of dependency although not in code. I still keep getting the discrepancy. Could you try using the files attached? There are a few modules that contain one or two variables each that seem to make a difference.

[Juergen_R_R · Accepted solution]

Indeed, with the files attached I can reproduce your findings. Using the -module flag does not have any impact, the issue happens also with the standard setting here. The -O0 flag is irrelevant, it is the -g flag that causes the issue. -O0 alone works. This really looks like an Intel bug. I would file a bug report.

[Cibin_Joseph]

Thanks Juergen for the prompt response!

Could you confirm that -O0 flag is irrelevant. I seem to come across the same discrepancy with only the -g flag. This happens after clearing the .obj and .mod files. And just to clarify, the make command I used when this occurred was 'make run_dbg' or 'make'.

[Juergen_R_R]

Dear Joseph, look above, I wrote that -O0 is irrelevant, and -g is the important flag. I ran your Makefile and also compiled it by hand. Same result. Using a specified object path doesn't matter. I compiled with gfortran, PGI and nagfor (with full debug flags and default flags). All compilers show the expected results.

[Cibin_Joseph]

Apologies for my confusion. You're right, -O0 is irrelevant. -g is the culprit.

[Hachenberg__Fabian]

We might have run into the same bug using ifort 19u1 under ubuntu 18.

Is there a bug report open yet?

[Cibin_Joseph]

For the record, this bug has been fixed in Intel Fortran 2020.