Error: the storage extent of the dummy argument...

[lklawrie]

I'm trying to compile an old (pre F77 even) code on IVF.

I'm getting the error:

"The storage extent of the dummy argument exceeds that of the actual argument."

Is there a compiler setting to ignore this error? (It's usually passing in a single word where the routine is expecting an array).

Thanks in advance.

Linda

[Steven_L_Intel1]

Are you compilng with interface checking enabled? Sounds like it. I don't see how the compiler could issue this message by default. Turn off /warn:interface and /gen-interface

[lklawrie]

I do not have either of those checks turned on.

Here are my "command line" checks:

/nologo /module:"$(INTDIR)/" /object:"$(INTDIR)/" /c

Linker:

/OUT:"Release/NewEPMacro.exe" /INCREMENTAL:NO /NOLOGO /SUBSYSTEM:CONSOLE

I get a similar message from CVF.

Linda

[Steven_L_Intel1]

Do you have an explicit interface for the called routine? That's the only way I can see you'd get this. Also, your description of the coding use doesn't match this message. You'd get it for something like this:

program foo
integer a(3)
call sub(a)
end
subroutine sub(a)
integer a(10)
end

You have to be passing a whole array (or array slice) whose nunber of elements is less than that of the declared dummy argument. Passing just a single element would not give an error and passing a scalar would give a different error. You'd get no errors unless some sort of cross-routine interface checking was being done.

[lklawrie]

Here's the actual program slice.

... calling program
integer ia4(4)
...
call a4a1( ia4, KARD(KARDI1), (len+3)/4 )
...
SUBROUTINE A1A4 ( I1, I4, N )
C---
C--- PACK 4*N WORDS OF A1 FORMAT IN I1 INTO N WORDS OF A4 FORMAT IN I4
C---
integer I1(80), I4(20)
character L1(4), L4(4)
INTEGER ITEMP,JTEMP
INTEGER N
EQUIVALENCE ( ITEMP, L1(1) ), ( JTEMP, L4(1) )
INTEGER I,J,K

J = 0
DO 200 I = 1 , N&n bsp;
DO 100 K = 1 , 4
J = J + 1
ITEMP = I1(J)
L4(K) = L1(1)
100 CONTINUE
I4(I) = JTEMP
200 CONTINUE
RETURN&n bsp;
END SUBROUTINE A1A4

error is happening:

The storage... [IA4]

I think I can get around it by not declaring the actual limits in the subroutine.

But don't seem to just be able to ignore the error.

Linda

[Steven_L_Intel1]

Ok, yes, it is the situation I described. But I don't see how you would get the error in Intel Fortran without an explicit interface or asking for interface checking. With CVF some of that happens by default. No, you can't turn it off individually.

[lklawrie]

do you want me to submit it as an issue for premier support?

It's all in one file -- I would just submit the full thing.

Linda

[Steven_L_Intel1]

Sure - I'd like to see it. Please ask that it be assigned to Steve Lionel.

It isn't a compiler bug, but I would like to understand how you see the error when I don't think you should.

[Steven_L_Intel1]

Linda,

Thanks for sending the source file. For a "pre-F77" program, it is quite forward-looking as it uses such features as MODULE, USE, derived types and CONTAINS. It is this last that is doing you in, since contained procedures create explicit interfaces that are then visible to all other contained procedures in that program unit and hence the compiler has the information it needs to notice the mismatch and give the error (which cannot be suppressed.)

You may want to consider using dimension (*) in the called routines if the array size is truly arbitrary.

[lklawrie]

The "forward looking" parts were really my doing when I thought I might be able to make the code readable or move it to Fortran 90.

Interestingly, Lahey compilers don't seem to care about the Module/Contains so it isn't building an explicit interface. Both CVF and IVF do -- as well, running even a correctly interfaced version in IVF leads to some illdefined vars.

Thanks for looking.

Linda

[Steven_L_Intel1]

I'm sure that Lahey does care about the module/contains and creates the explicit interface - if it didn't, it wouldn't be a Fortran compiler - but it may not do the error check we do.

I did notice in my testing that some of the routines reference variables not declared in the routine but are declared in the program. Whether that was intended or not, I don't know - it's a common trap that programmers fall into when switching to contained procedures and there's no way to "turn off" host association to catch such tings if they were unintended.

[jimdempseyatthecove]

Linda,

Your calling program has

integer ia4(4)
...
call a4a1( ia4, KARD(KARDI1), (len+3)/4 )

The first argument of the call to a4a1 is an integer array of size 4

The subroutine called a4a1 specifies the first argument is an integer array of size 80.

Your extraction loop is going to address beyond the end of the araay of thefirst argument when the len on the caller is .not a multiple of 4. Assuming
len = size(ia4)
Then the example call will work (although the dimension in the called routine is incorrect).
Bad coding - fraught with potential future problems.

However, if this technique is use on other arrays of differeing sizes and if those sizes are not a multiple of 4 elements then your code will be referencing beyond the end of the input array. I suggest you use

call a4a1( ia4, KARD(KARDI1),size(ia4) )

SUBROUTINE A1A4 ( I1, I4, Nx4 )
integer Nx4, I1(Nx4), I4(20)
IF(MOD(ia4,4) .ne. 0) call DebugThis
N=Nx4/4

or something to that effect.

Jim Dempsey

[ajay_panyala]

Hi Steve,

I am trying to compile an f90 program. I am getting the error
' The storage extent of the dummy argument exceeds that of the actual argument. [PERMUTATION]
CALL transpose_2(loC4,dimp,taC4,permutation) '

The transpose_2 subroutine is defined in another file which is a module(named trans.F90) and the specification part of the module contains an interface as follows:
interface transpose
module procedure transpose_2,transpose_3,transpose_4,transpose_5,transpose_6,transpose_7
end interface

and the contains part of the module has the transpose_2 subroutine implemented.

I have compiled the module file using ifort -c trans.F90.

The actual f90 program uses the .mod file created by the above compilation, but throws the error given above.

Thanks

[Steven_L_Intel1]

I'd need to see the actual declaration of "permutation" in the caller and the corresponding dummy argument in the called routine.

[ajay_panyala]

Quoting - Steve Lionel (Intel)

I'd need to see the actual declaration of "permutation" in the caller and the corresponding dummy argument in the called routine.

I got it. Thanks. It is not giving the error anymore. permutation was actually a 1D array. The subroutine was accepting
arrays of length 7 while the caller passed only an array of length 6. I corrected it and now its fine. This fortran code was auto-generated and I believed that it was right, but maybe it have a few bugs like this.

I've got one more question. Does fortran distinguish between uppercase and lowercase variable names automatically or should i specify some more compile time options for doing that. Because when I compile the same code above I am also getting errors like ' This name has already been assigned a data type '. The code contains integer declarations as follows:
INTEGER t_1, C1, A, t_2, C2, t_3, C3, B,....
INTEGER a, aI, aT, bI, bT, b, .....

errors:
error #6418: This name has already been assigned a data type.
INTEGER a, aI, aT, bI, bT, b, cI, cT, c, dI, dT, d, pI, pT, p, qI,
-----------^
4indexc.f(9): error #6418: This name has already been assigned a data type.
INTEGER a, aI, aT, bI, bT, b, cI, cT, c, dI, dT, d, pI, pT, p, qI,
------------------------------^

Thank you very much

[Steven_L_Intel1]

Fortran is not case-sensitive. Do not try to make it so. There is an option for it, /names:as_is, but I would rap your knuckles with a printout ruler if I ever caught you using it...

[ajay_panyala]

Quoting - Steve Lionel (Intel)

Fortran is not case-sensitive. Do not try to make it so. There is an option for it, /names:as_is, but I would rap your knuckles with a printout ruler if I ever caught you using it...

Thanks :)