Fortran 77 subroutine input output - compatibility with intel fortran

[abaraldi]

Good morning,
I would like to ask somebody about a F77 feature, and its compatibility with intel fortran.
I am using part of an old code, and I found the following syntax:

subroutine A

real, dimension(:), pointer :: x,y

...

call B(x(1),y(1),x(1))

end subroutine A

!------------------------------------------------

subroutine B(u,v,u1)

dimension u(IM,JM)
dimension v(IM,JM)
dimension u1(IM,JM)

do i=1,IM
do j=1,JM

u1(i,j) = some function of u(i,j) and v(i,j)

end do
end do

return
end subroutine B


Ok, here is the question. subroutine A calls B passing the first element of pointers, and subroutine B expects arrays of a given dimension. I assume B reads the contiguous memory from the location of the first element of each pointer, onwards, according to the column major convention. That's ok.
Now, subroutine B: it receives the same two vectors u and u1 from vector x in subroutine A. So u and u1 are the same. Then u1 gets modified, while u doesn't.

1)What happens to the values in the memory associated with pointer x, when B returns? will it be u1?

2) is the memory x points to only re-written when subrouitne B returns? So are u1 and u stored in a sort of scratch space where all the computation takes place?

I am used to F90 where I declare the intent, so I never thought about these issues. Thanks a lot, if somebody could step in and explain it to me.
Regards

[TimP]

Why would you mix Fortran 90 and 77 in this way? I suppose a compiler would be entitled to reject it.
Looking at the subroutine by itself, yes, if it is called in a valid manner, the array section is updated by the time control returns to the caller. As to whether it is updated immediately while the subroutine is active, that is implementation dependent. With Intel Fortran, the updates would be delayed only to the extent to which that helps with optimization.

[Steven_L_Intel1]

This program is not legal Fortran for at least two reasons. But ignore the notion of "mixing F90 and F77" - there is really no such thing. All of the language syntax in this program is legal F90, but the way it is used violates two rules. INTENT is not relevant.

First, it is normally fine to pass an element of an array to a routine that accepts an array. You get what Fortran calls "sequence association" here, where the dummy argument is the passed element and subsequent elements in array element order.

However, you are NOT allowed to do this with a pointer array because a pointer array may be discontiguous. The compiler will give you an error about this if you compile with -warn interface.

Second, there are restrictions on what you can do to a dummy argument if it is aliased to another dummy argument. In this program, u and u1 are aliased. If that is the case, and you don't have the TARGET attribute on both arrays, you are not allowed to store to either argument. Therefore, the assignment to an element of u1 is illegal. The Intel compiler cannot diagnose this, and the results are unpredictable. You can tell the compiler to ignore this rule by specifying -assume dummy_alias . This disables all optimizations that assume no illegal aliasing of dummy arguments, COMMON and module variables. If you do this, then array x gets updated on each assignment, possibly modifying the value of future evaluations of the "some function".

[TimP]

As Steve says, I'm incorrect in loosely referring to an incompatible combination of syntax as "mixing f77 and f90." I thank him for explaining in more detail how you can't use the pointer where the context demands sequence association.
I missed your statement that u1 and u are aliased. As Steve said, ifort supports it as an extension by the -assume dummy_alias option. Although it was common practice in the past to depend on such extensions, it was not allowed in f66 nor f77, so it always depended on extensions such as the one mentioned here. If you are careful that your code doesn't depend on when the u1 updates occur, it may work single threaded even without the option, but this is specifically disallowed by the Fortran standard.