entry point does not define all dummy variables

[martymike]

Last night a collegue of mine checked in a file that produced this warning in our nightly build:

Warning: This entry point does not define all dummy variables used in bounds or length expressions of automatic data objects.

This person is a meticulous tester, so I knew he'd run the code, but the warning caught my attention and I decided to look at it - and didn't like it. I posed it to him in this simplified form:

Subroutine E1(a)

integer a,b(n),n

integer temp(n)

...

entry E2(b,n)

...

The F90 standard says (section 5.1.2.4.1):

If an explicit-shape array has bounds tht are nonconstant specification expressions, the bounds, and hence shape, are determined at entry to the procedure by evaluating the bounds expressions

I take this to mean that even if, when calling E1, the code executed never references b or n, it will still attempt to allocate n integers on the stack - and n is not defined. This worries me, even though this code has been run and seems to work.

Does anyone know what the compiler will do with this? We are using CVF 6.6 but plan to upgrade to the current IVF compiler sometime in the next 6-9 months, so experience with/knowledge of either compiler will be of interest.

[Steven_L_Intel1]

I've tried and failed to come up with a compilable example that produces this warning with CVF, based on what you've written. Can you come up with a complete example that does this?

Note that the warning refers to automatic objects, so I suspect that the actual code is different from what you have represented here.

[martymike]

Subroutine countItems(aSize)
implicit none
integer aSize,dSize,nTypes,stuff(dSize,nTypes),ierr
character*(*) ids(nTypes)
integer ii,temp(dSize),icount

call get_size(icount)
aSize=icount
return

entry getData(stuff,dSize,nTypes,ids,ierr)
ierr=0
call get_size(icount)
if (icount>dSize) then
ierr=1
return
endif
do ii=1,nTypes
call compute_results(ids(ii),temp)
stuff(:icount,ii)=temp
enddo
end

I realize that in this case were aSize simply renamed dSize the warning goes away. This code does get the warning, however, and does compile. The point of the question is to verify my understanding of the consequences of ignoring the warning, for the purpose of convincing someone else to modify his seven 1000-line programs - or to find out that I am wrong and that it doesn't matter.

[Steven_L_Intel1]

Ok, I can reproduce it with your example (and cut down some.)

My initial reading of the standard suggests that the compiler is wrong here. IVF give sthe same complaint. I'll check with our standards committee rep to see whet he says, and to find out if there were any interpretations to the standard that affected this.

[Steven_L_Intel1]

We agree that this is a bug. I have passed it on to development to be fixed. I'll note that the code seems to work anyway, and it's unclear to us what was in the mind of whoever added this warning.

[martymike]

OK, I'm confused.

It didn't appear to be a bug to me, I thought the source code was wrong because there was an automatic array whose extents were defined by dummy arguments not present in all the entry points (unless you mean that the bug is that it ought to be an error not a warning).

I can accept that I'm wrong, but I'd like to know why. Can you explain?

[Steven_L_Intel1]

There should be no diagnostic at all. The standard permits the declaration as long as there is no reference to the automatic array in the executable code except through a code path that originated with a call to an entry point which defined the argument. The exact wording of the standard is:

If a dummy argument is used in a specification expression to specify an array bound or character length
of an object, the appearance of the object in a statement that is executed during a procedure reference
is permitted only if the dummy argument appears in the dummy argument list of the procedure name
referenced and it is present (12.4.1.6).

If subroutine countitems referenced array temp, that would be an error, though not one the compiler is likely to detect.