Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
29236 Discussions

THE error:If the actual argument is scalar, the corresponding dummy argument shall be scalar unless the actual argument is an element of an array that is not an assumed-shape or pointer array, or a substring of such an element. [A]

vickyxin
Beginner
1,796 Views

Hi,all

I had compuiled for WRF model with intel fce 10.1.but there is a error in compiling process:If the actual argument is scalar, the corresponding dummy argument shall be scalar unless the actual argument is an element of an array that is not an assumed-shape or pointer array, or a substring of such an element. .Because the WRF program is too big ,so i wrote a simlified program to test.


module test
integer,pointer::a(:)

contains

subroutine ff(a)
integer a(100)
end subroutine

subroutine f
call ff(a(2))
end subroutine

end module test

ifort test.f :

If the actual argument is scalar, the corresponding dummy argument shall be scalar unless the actual argument is an element of an array that is not an assumed-shape or pointer array, or a substring of such an element.

How can i do if i dont wanna to modify the program (because the WRF souce codes are very big)?Can i use some compile option?

0 Kudos
8 Replies
Steven_L_Intel1
Employee
1,796 Views
The code you have posted is not legal Fortran. If A was not a POINTER, it would be ok, but there is no "sequence association" for POINTER arrays (since they can be discontiguous.)

There is no compile option to avoid this error - you will have to correct the code.

My understanding is that current versions of WRF do compile with Intel Visual Fortran, though I am not familiar with the details.
0 Kudos
vickyxin
Beginner
1,796 Views

Thank you for your reply.

There are some places in WRF(module_dm.f,module_domain.f,and so on ) which are using the codes like the example. And the same codes can be compiled sucessfully with intel fortran compiler 9.0 .

I just saw the netpage:http://support.intel.com/support/performancetools/sb/CS-028607.htm. Iplan todownload the correspondent version of WRF and Fortran compiler, wish suceed.

0 Kudos
Steven_L_Intel1
Employee
1,796 Views
9.0 had a bug in that it did not test for this error condition.
0 Kudos
ltaylor934
Beginner
1,796 Views
9.0 had a bug in that it did not test for this error condition.

How would you *correct* the sample code as given in the thread?

At present, all I get is a message that my code is wrong, and I have no guidance about what is right.

By the way, I interpret

integer, pointer :: a(:)

to be a pointer to an array, not an array of pointers. Why would it not be contiguous?

LAT

0 Kudos
Steven_L_Intel1
Employee
1,796 Views

To correct this example, I would make A an ALLOCATABLE instead of POINTER and change the declaration of the dummy argument A of FF to be (*) rather than (100).

You are correct that this is a pointer to an array but you could define the pointer as pointing to a non-contiguous slice of an array, for example:

A => B(1:10:2)

Because this is possible, "sequence association" is not available for pointer arrays. Since it is NOT possible with allocatable arrays, sequence association is allowed.

0 Kudos
van_der_merwe__ben
New Contributor II
1,796 Views
I have to compile some old code, and I got this same error on this code:


INTERFACE
SUBROUTINE GETBCPRESSURE(I,V)
!DEC$ ATTRIBUTES DLLEXPORT, ALIAS: '_getbcpressure' :: GETBCPRESSURE
!DEC$ ATTRIBUTES VALUE :: I
!DEC$ ATTRIBUTES REFERENCE :: V
INTEGER :: I
REAL :: V(*)
END SUBROUTINE
END INTERFACE

REAL :: PRESSURE

CALL GETBCPRESSURE(BCINV,PRESSURE)

It completely baffled me, but I managed to "fix" it as follows:

REAL, ALLOCATABLE :: PRESSUREA(:)

ALLOCATE(PRESSUREA(2))
PRESSUREA(1)=PRESSURE
CALL GETBCPRESSURE(BCINV,PRESSUREA)
PRESSURE=PRESSUREA(1)

Dunno how a single real could cause this error, but oh well.
0 Kudos
TimP
Honored Contributor III
1,796 Views
On the platform I learned on, pointer-to-scalar was incompatible with pointer-to-array. If I remember correctly, the latter had an additional level of indirection. Fortran rules support such platforms. At your own risk, you could turn off the checking and use non-portable code, if your intention is to make it break on those platforms while ignoring the problem on your favorite one.
0 Kudos
mecej4
Honored Contributor III
1,796 Views
Instead of placing an array element in place of the expected array argument, provide an array slice:

[fortran]        module test
        integer,pointer::a(:)

        contains

        subroutine ff(a)
        integer a(100)
        end subroutine

        subroutine f
                call ff(a(2:))
        end subroutine

        end module test
[/fortran]
I have no idea whether the actual subroutine (rather than this extract) will use only the slice that is given to it or will try to use the full array. The latter will cause an error, and the former would require that information on the length of the array slice be made available to the subroutine by the caller in some acceptable way.
0 Kudos
Reply