Compiler error #8284

[netphilou31]

Hi,

I am experiencing a strange behavior with Intel(R) Visual Fortran Compiler XE on IA-32, version 12.1.6 Package ID: w_fcompxe_2011.12.369.

I have a file which compiles and works fine with CVF 6.6c. Hoever when I try to compile the same file with the Intel compiler I get the error #8284: If the actual argument is scalar, the dummy argument shall be scalar unless the actual argument is of type character or is an element of an array that is not assumed shape, pointer, or polymorphic.

I understand what does this means, but what I don't understand is why the error is generated.

The file I try to compile is probably too complex to send it as is so I will try to explain what I am doing.

The file contains one subroutine in which I have two arrays of doubles, one being declared as allocatable with the target attribute (PARG) and the second one is declared with the pointer trribute (PAR).

[fortran]real(8), allocatable, target :: PARG(:)

real(8), pointer :: PAR(:)[/fortran]

During the execution, the PAR array is mapped to the PARG array:

[fortran]PAR => PARG(1:NPTS(K))[/fortran]

I have a lot of calls to other subroutines in which some of the arguments are passed as part of the PAR array (let say PAR(JP) for example),

In the called subroutines, the dummy argument is declared as an array (let say P(N) for example) and is in fact a sub-array of the main array PAR and this is the source of the compiler error.

What I don't understand is why I cannot do like this (I guess that if the PAR array did not have the pointer or allocatable attribute the error will not be triggered).

As mentioned at the beginning, this is working fine with CVF 6.6c. Is it really an error? or is it possible to ignore it ?

Best regards,

Phil.

[jimdempseyatthecove]

>> some of the arguments are passed as part of the PAR array (let say PAR(JP) for example), Is the dummy argument that receives PAR(JP) a scalar or an array? If array, then the interface to the subroutine (implicit or explicit) must be obscured (such that older FORTRAN calling conventsions are observed). When the interface to such a subroutine (implicit or explicit) if visible (not obscured), then the calling argument (in this case) must be an array, say PAR(JP:KP). Jim Dempsey

[netphilou31]

Hi Jim, Thanks for the reply, Yes the dummy argument is an array (P(N)). I am not sure to understand what do you mean by "obscured". I do not have any interface declaration of the called subroutine in the caller. I have already seen that if I replace the actual argument PAR(JP) by PAR(JP:JP+N-1) the compiler error vanishes. However I have several routines that have tens of arguments and modifying all of them could be a tough and error prone work. What happens if I add an interface declaration in the calling routine? Did you mean that this would solve the problem ? Best regards, Phil.

[Steven_L_Intel1]

Read http://software.intel.com/en-us/blogs/2009/03/31/doctor-fortran-in-ive-come-here-for-an-argument - especially the section on Sequence Association.

[netphilou31]

Steve thank you for this very interesting article... Ultimately, even after more than 20 years of Fortran practice you can still learn things or change your mind on things that you were sure about. Just a comment about my problem. If I change the declaration : [fortran]real(8), pointer :: PAR(:)[/fortran] by [fortran]real(8) :: PAR(1) pointer (lpPAR, PAR)[/fortran] and use : [fortran]lpPAR = loc(PARG(1))[/fortran] instead of : [fortran]PAR => PARG(1)[/fortran] The compiler error vanished. I assume that this should work, however is it correct ? Best regards, Phil.

[Steven_L_Intel1]

Well, you've replaced a standard language feature with an extension, but yes, this should work. The issue is that a standard pointer can point to a discontigous array section, but an "integer pointer" cannot. I would suggest using (*) instead of (1).

[netphilou31]

Thanks for the advice, You are probably right about the fact that a standard pointer can point to a dis-contiguous array section as an "integer pointer" cannot, however in my case this should not be a problem because I am sure that the array section is contiguous. Furthermore, I did not remember that the "integer pointer" feature was an extension (and I use a lot of them for exemple in order to get the proc addresses from an external dll and associate the pointer to a subroutine). Best regards,

[Steven_L_Intel1]

There is a standard-conforming way to do procedure pointers. You can see an example of it in http://software.intel.com/sites/default/files/comment/1632025/processorinfo.f90 While your pointers may be contiguous, the possibility that they aren't is what triggers the restriction in the standard on sequence association.

[netphilou31]

Thanks again Steve You really deserve your title of Dr Fortran ! I will look at the related document to see if I can use this method for loading procedures from external dynamically loaded dlls. Best regards, Phil.