Overwritten values after switching to ifix compiler - Help!

[warre371]

I'm using a program that, for years, ran without a problem with ifort. However, when I recently switched to ifx, my code began to blow up. It appears the issue is that one of the arrays in my code (I'll call it array1) is being overwritten with values from another array, as if these two arrays are being assigned to the same memory location.

There are dozens of arrays throughout the code, and I have yet to figure out which one is overwriting array1. Also, the memory blocks are only slightly overlapping; only the tail end of array1 is being overwritten.

The code never crashes. I never receive a seg error. Instead, the alien values being saved into array1 eventually cause all the values in array1 to turn into NaNs (because of the nature of the calculations I'm doing).

I don't know why this error would pop up as soon as I change compilers, especially since this code has been running without a problem for a decade.

[Ron_Green]

Is this with the ifx compiler from 2024.1.0 or 2024.2.0 packages?  What does ifort from the new package do with this code?  

Is this Windows or Linux?

can. you share the code and it's input files (if any)? 

[warre371]

I'm running it with 2024.0.2 ifx on a linux system. I haven't tried compiling the code with the new package's ifort; intel is discontinuing ifort in late 2024, which is the reason I have to switch to ifx.

Unfortunately the code isn't public, so I can't share it.

Thanks in advance for any thoughts!

[jimdempseyatthecove]

Build you code with runtime array bounds checking

If your code is indexing out of bounds, this may catch it if your calls are like

call foo(Array)
...
subroutine Foo(Array)
  implicit none
  real :: Array(:) ! use the callers array size
...

It will not necessarily detect if your code is passing array size as an argument

call Foo(Array, N) ! N = size of array (but could be wrong)
...
subroutine Foo(Array, N)
  implicit none
  integer :: N
  real :: Array(N)
...

Jim Dempsey

[warre371]

This checks out with the way the code is formatted. I definitely believe the problem to be something along these lines.

Now, do you know of any efficient way for me to figure out which two arrays are overwriting each other (e.g. is there a debugger that I could use for this?). I'm working with a massive legacy code, only the surface of which I've ever interacted with. I've been trying to find the problem by brute force for several weeks and have yet to be successful.

[jimdempseyatthecove]

MS VS

Data Breakpoint

Then use loc function to get the address of the cell of interest

This will require you to identify the cell being erroneously overwritten (before it is overwritten).

Alternate Scenario

If you know a point in your code where you know the array that gets clobbered is built and not modified, snapshot the array into a new array. Then, as you transition from procedure to procedure, you can compare the contents of the array that gets clobbered with the snapshot taken of that array. In this manner you can discover the procedure causing the problem. Place the code in a module

Something like:

module FindMyBug
real, allocatable :: Snapshot(:) ! change for your array type and rank
contains
subroutine Snapshot(YourArray)
  implicit none
  real :: YourArray(:) ! change for your array type and rank
  Snapshot = YourArray
end subroutine Snapshot
subroutine CheckSnapshot(YourArray)
  implicit none
  real :: YourArray(:) ! change for your array type and rank
  integer :: i
  do i=1,size(Snapshot)
    if(Snapshot(i) /= YourArray(i)) then
     print *,"Bug, place breakpoint here"
    endif
  end do
end subroutine CheckSnapshot
end module FindMyBug
...
subroutine foo(args here)
  use FindMyBug
  ...
  ! build your array
  call Snapshot(YourArray)
  ...
  call CheckSnapshot(YourArray)
  call aProcedure(args)
  call CheckSnapshot(YourArray)
  call anotherProcedure(args)
  call CheckSnapshot(YourArray)
  ...

The above is sketch code and untested.

As indicated, you will have to modify it for your array type and rank.

Jim Dempsey