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

ifort does not notice array dimensions are wrong

I have run into a strange problem that was not diagnosed by ifort even with the -check all -warn all flags. The short code attached to this message compiles without complaning, but then produces wrong results (an array with intent(in) gets modified). There is a bug in the code, which is that the dimension of the c array is in this case (2,19) whereas the dimensions of y are (2,39). However, ifort doesn't pick this up, and instead produces wrong results.
I am using
Intel Fortran Intel 64 Compiler Professional for applications running on Intel 64, Version 11.1 Build 20090827 Package ID: m_cprof_p_11.1.067
Copyright (C) 1985-2009 Intel Corporation. All rights reserved.
0 Kudos
3 Replies
ifort can't pick this up because you prevented it from doing so. In routine b, you declared array y as (2*nx-1). The compiler takes your word for it and uses that as the dimension. If you had declared y as (:) instead not only would this avoid making a temporary copy for the non-contiguous array slice you pass, but now you'd get a run-time error like this:

forrtl: severe (408): fort: (2): Subscript #1 of the array Y has value 20 which is greater than the upper bound of 19

New Contributor I
I think the OP was hoping for a compile-time warning. Often, the compiler will warn if the actual array argument is too small, but I think that only works when the actual and dummy arguments both have a static size.

For example, change the subroutine b dummy argument to "y(100)" and the actual argument in the call from routine a to "C(1,1:5)". Then, both sizes are static, and 5 is too small, giving this error:

ifort_bug.f90(35): error #7983: The storage extent of the dummy argument exceeds that of the actual argument.
call b(size(x), c(1, 1:4), x)

Not also that a larger actual argument does not produce a warning.
In the original example, the compiler does not know, at compile time, what the extent of the actual argument is.