Array Indexing Error in Intel Composer 2017 (ifort 17.0.0)

[wilson__david]

program Bug
  call main()

!    contains
end program Bug


Module errorModule

double precision,allocatable,dimension(:) :: readInArray, tmpWork
integer :: n,i
character(len=300) :: filout


end Module errorModule


subroutine main()

use errorModule

n = 59925

allocate(tmpWork(n+10))
do i=1,n+10
    tmpWork(i) = i
enddo

allocate(readInArray(62267))
 write(filout,'("PhysicalMapInput.txt")')

open(unit=1001,file=trim(filout),status="old")



read(1001,*) readInArray(tmpWork(1:n))  


print *,readInArray

deallocate(readInArray)
deallocate(tmpWork)

end subroutine main

I believe I have found an error in the intel ifort compiler (the 2017 version). I have tested this with ifort 16 and the bug is not there.

I have written the above program to demonstrate this.

When I run the following:

ifort error.f90 -traceback -g -debug all -warn all -check bounds -check format -check output_conversion -check pointers  -ftrapuv -check all -gen-interfaces -warn interfaces 

I get the following error: 

forrtl: severe (194): Run-Time Check Failure. The variable 'var$76' is being used in 'error.f90(36,1)' without being defined

Image              PC                Routine            Line        Source             

a.out              000000010D72464C  _main_                     36  error.f90

a.out              000000010D725574  _MAIN__                     2  error.f90

a.out              000000010D723CAE  Unknown               Unknown  Unknown

As already mentioned. This does not happen in the 2016 version. 

[mecej4]

Does the error occur regardless of the content of the data file? Can the error be demonstrated with a much smaller value of n than 59925?

In any case, it would be helpful if you made the data file available.

[wilson__david]

The file is attached. The problem seems to exist regardless of the size of n. Also, apologies for not including the file yesterday, was half asleep when I wrote this up!

[Kevin_D_Intel]

Thank you for the input file. I will try reproducing this.

[mecej4]

The example code and data file are sufficient to reproduce the problem, but contain features, some not standard-conforming, that serve as distractions. For example, the use of a double precision array as a subscript expression, and the use of a data file with a single line of about 79,000 characters.

Here is a simplified reproducer. The file "phy.txt" is obtained by replacing blanks by newlines in "PhysicalMapInput.txt".

program idxbug
implicit none
integer, parameter :: NN = 65636
integer :: i
integer, dimension(NN) :: idx = [(i,i=1,NN)]
double precision, dimension(NN) :: phy
!
open(11,file='phy.txt',status='old')
read(11,*)phy(idx)
end program

To reproduce the error, it is sufficient to compile with the /check option and run the resulting program. An access violation occurs on line 9.

No error occurs if /check is not specified. I think that the checking code inserted by the compiler stumbles when attempting to issue a message about creating a temporary array used as index.

If the array section index idx on line 9 is replaced by 1:NN, the error goes away.

NOTE: I ran my tests on Windows, but it should be easy to run the simplified test program on Linux.

[wilson__david]

Hi  macej4,

thanks for cutting down the program. The reason my version was so verbose is that this error has in fact presented itself in a very large project. In this sample program, without the check compiler flag, no other errors present themselves. However, in our larger program (about 35 modules) this issue will later cause a segmentation fault. When I run this with valgrind it appears that the stack has been corrupted and I believe this is caused by the error found in this check.  As you say the error can be avoided with different syntax, but in some instances this is not possible without a significant rewrite of the code. As I say, not a major issue for us,  but still a bug that the compiler team should be aware of!

Thanks

David Wilson 

[mecej4]

david w. wrote:

As you say the error can be avoided with different syntax, but in some instances this is not possible without a significant rewrite of the code. 

I understand that completely! My comments were only about the reproducer, made with the aim of helping to pinpoint the bug in the compiler. It is often the case that a work-around offered for the reproducer is not feasible for the full program, and only a person who has access to (and knowledge of) the full program can make that assessment.

[Kevin_D_Intel]

I reproduced the error. Thank you for the reproducer and mecej4 for the further isolation and reduction. Whatever the underlying root cause, it is tied to the -check option with all checks enabled and not any one available single check option argument. I routed this to Development.

(Internal tracking id: DPD200414419)