topic That is not a "bug". The a in Intel® Fortran Compiler

detect bad array shape

Roman1 — Mon, 23 Nov 2015 20:37:29 GMT

The following program has a bug. Do you know if it is possible to have the compiler detect it? I have tried the following options without success:

/Qtrapuv /Qinit:snan /Qinit:arrays /fpe:0 /check:all

program test_shape
implicit none

real,allocatable,dimension(:):: a, b 
real c

allocate( a(5), b(2) )

b = 0.0
a = b   !!!

c = a(3)
print*, c  ! output: -4.3160208E+08  ???
stop
end program test_shape

That is not a "bug". The a

NotThatItMatters — Mon, 23 Nov 2015 20:47:38 GMT

That is not a "bug". The a array's first two entries are being set to the values in the b array. As should be expected, the third entry is not initialized. Therefore, it has a value that cannot be predicted. About the only thing you can do here is have the compiler initialize the array.

Are you aware of /assume

FortranFan — Mon, 23 Nov 2015 21:18:00 GMT

Are you aware of /assume:realloc_lhs and/or /standard-semantics compiler options and the role they play with treating allocatable objects?

https://software.intel.com/en-us/node/579519

https://software.intel.com/en-us/node/579529

You'll notice per standard Fortran i.e., starting with Fortran 2003, SIZE(a) should be 2 following the assignment on line #10, not 5 as allocated on line #7. But if I'm not mistaken, standard Fortran rules for allocatable object assignment, etc. are still not implemented by default in Intel Fortran, rather one has to turn them on using /standard-semantics, etc. So you may want to look into this aspect and whether you are making use of it; if not, see if you can and should.

Now if you go with standard Fortran rules for reallocation, you can look into /check:bounds compiler option which can trigger a run-time check when line 12 is executed since it should involve accessing an element outside the bounds, something worth doing with tests on your code run in Debug configuration:

https://software.intel.com/en-us/node/579521

Otherwise, look into /check:uninit and /check:pointers and whether they can help you, at least at run-time if not at compile-time.

Roman1 — Mon, 23 Nov 2015 21:47:24 GMT

Thanks for the information! Initially, I was hoping that since I used /Qinit:snan /Qinit:arrays , the value of c would be set to NaN, instead of -4.3160208E+08 . The /assume:realloc_lhs option was helpful.