Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!
26734 Discussions

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

Cibin_Joseph
Beginner
124 Views

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!

0 Kudos
1 Solution
Juergen_R_R
Valued Contributor I
124 Views

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.

View solution in original post

8 Replies
Juergen_R_R
Valued Contributor I
124 Views

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
Beginner
124 Views

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
Valued Contributor I
125 Views

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.

View solution in original post

Cibin_Joseph
Beginner
124 Views

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
Valued Contributor I
124 Views

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
Beginner
124 Views

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

Hachenberg__Fabian
124 Views

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

Is there a bug report open yet?

Cibin_Joseph
Beginner
124 Views

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

Reply