Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
1 View

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

Jump to solution

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

Accepted Solutions
Highlighted
Valued Contributor I
1 View

Indeed, with the files

Jump to 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.

View solution in original post

0 Kudos
8 Replies
Highlighted
Valued Contributor I
1 View

I cannot reproduce your

Jump to solution

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.

 

0 Kudos
Highlighted
Beginner
1 View

Could you try using the files

Jump to solution

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.

0 Kudos
Highlighted
Valued Contributor I
2 Views

Indeed, with the files

Jump to 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.

View solution in original post

0 Kudos
Highlighted
Beginner
1 View

Thanks Juergen for the prompt

Jump to solution

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'.

0 Kudos
Highlighted
Valued Contributor I
1 View

Dear Joseph, look above, I

Jump to solution

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.

0 Kudos
Highlighted
Beginner
1 View

Apologies for my confusion.

Jump to solution

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

0 Kudos
Highlighted
1 View

We might have run into the

Jump to solution

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

Is there a bug report open yet?

0 Kudos
Highlighted
Beginner
1 View

For the record, this bug has

Jump to solution

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

0 Kudos