Compiler error #8284

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).

real(8), allocatable, target :: PARG(:)
real(8), pointer :: PAR(:)

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

PAR => PARG(1:NPTS(K))

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.

9 帖子 / 0 全新
最新文章
如需更全面地了解编译器优化,请参阅优化注意事项
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

www.quickthreadprogramming.com
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.

Steve Lionel (Intel)的头像

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

Steve
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 :

real(8), pointer :: PAR(:)

by
real(8) :: PAR(1)

pointer (lpPAR, PAR)

and use :
lpPAR = loc(PARG(1))

instead of :
PAR => PARG(1)

The compiler error vanished. I assume that this should work, however is it correct ?

Best regards,

Phil.

Steve Lionel (Intel)的头像

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).

Steve
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,

Steve Lionel (Intel)的头像

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/processori...

While your pointers may be contiguous, the possibility that they aren't is what triggers the restriction in the standard on sequence association.

Steve
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.

登陆并发表评论。