allocatable arrays with Intel Composer

[arildh]

I am wondering how the Intel Composer compiler treats the following bad-practice(..?) program.

The piece of code that looks much like this:

Program main
use MSub
implicit none

real, allocatable :: A(:,:)
integer :: N
N = 5
allocate(A(1,1))

Call sub(A,N)
end Program main


Module MSub
contains
subroutine sub(A,N,...)
real, intent(out) :: A(N,N)
integer, intent(in) :: N

... do some computation with involved data ...
end subroutine sub
end Module Msub

is this dangerous? Say that the array A is never used in the subroutine sub, is there a possibility for A to somehow corrupt data (being declared larger than it is allocated in main) ?

[mecej4]

With this declaration

real, intent(out) :: A(N,N)

you are lying to the compiler. Doing so can be dangerous. The program is illegal, and the consequences of running it, should you succeed in compiling and linking it, are unpredictable.

A more interesting question would center on what is being sought to be achieved with the illegal statement. There may be a safe, valid way of achieving the same goal.

[arildh]

I do not think it is correct to say that the program is illegal. This code compiles and has seemed to work well (at least with with Intel Visual Fortran 10), assuming that A(N,N) is not being used in the subroutine. My question is if this code is potentially dangerous, assuming that A(N.N) is not being used in the subroutine. Is it so that, since A is passed by reference, only A(1,1) is passed and the declaration of A(N,N) does not conflict with the addresses of other data? (again assuming that A is not being used in the subroutine)

[psantos]

arildh,

I agree with mecej4. This program will "blow" sooner or later and despite it hadn't any semantic error, since it compiles and links, it is wrong because, like mecej4 said, your are "lying" to the compiler.

Just wondering, why don't you declared A to be allocatable inside the subroutine, instead of using a dummy array? In this way if you need to use A you allocate memory for it only inside the subroutine. Notice that the allocatable array A is automatically deallocated on entry to subroutine, so even if you had allocated A with a different storage outside the routine, no problem will occur when you try to allocate new memory. I think this way is pretty more robust than what you are doing...

Pedro

[arildh]

Thank you for considering this question, although I do not think you are actually addressing the core question.
I agree that the coding is bad, and that it could have been done in several different ways. However, my question is not how to improve this piece of code, but rather:

Consider this code. Given that A is decleared A(N,N) in the subroutine, but is not used within the subroutine. Can this potentially cause memory trouble, and why? Does the declaration itself claim memory (overwrite existing memory)?

Ok, so why dont I just re-code to avoid the potential problem? Because I would like to know if this piece of code may have caused erroneous behaviour in the some old programs.

BTW: Consider sending an undefined pointer into sub rather than A(1,1). This works with Visual Fortran (v10), but gives an error using Composer (v12).

[jimdempseyatthecove · Accepted solution]

>>Consider this code. Given that A is declared A(N,N) in the subroutine, but is not used within the subroutine. Can this potentially cause memory trouble, and why?

The answer is NO ** provided **"but is not used within the subroutine" continues to hold true.
What do you think will happen if "A(N,N)" is passed in today, for a future feature to be added later (by someone else)?

It is safer to eliminate the unused array dummy argument (or fix the indexing).
An alternate way is to use an interface anddeclare the array a A(:,:). But this may/will add a little call overhead (for an unused argument).

Jim Dempsey