Forwarded for a colleague:
I have a question about what the F77/F90 standards say about making
out of bounds references in arrays. I have looked at them, but my
problem seems to fall in a gray area. From a client, I have a code
which logically has no out of bounds indexing problems, but may
actually not be standard conforming -- it's unclear to me. Although I
compile this code with several F95 compilers, it is really just an F77
code.
Here is an excerpt from the routine in question with extraneous lines
deleted.
subroutine nospin(z)
include 'size.h'
:
:
:
real z(0:nt,nt+1,nd,3,nr+1), s(6)
:
:
:
do ir=1,nr+1
s(3) = 0.
s(6) = 0.
if(mynum.eq.0 .and. nd.eq.10) then
s(1) = 2.
s(2) = 2.
s(4) = z(0,1,1,2,ir) - z(0,1,6,2,ir) <== (line 671)
s(5) = z(0,1,6,1,ir) - z(0,1,1,1,ir) <== (line 672)
elseif(mynum .eq. 0) then
s(1) = 1.
s(2) = 1.
s(4) = z(0,1,1,2,ir)
s(5) = -z(0,1,1,1,ir)
elseif(mynum.eq.mproc .and. nd.le.5) then
s(1) = 1.
s(2) = 1.
s(4) = -z(0,1,1,2,ir)
s(5) = z(0,1,1,1,ir)
else
s(1) = 0.
s(2) = 0.
s(4) = 0.
s(5) = 0.
endif
:
:
:
:
Note that the declared dimensions of z are specified with Fortran
parameters. These are included through the file 'size.h' and listed
at the bottom of this message. In particular, note the third
dimension specified by 'nd'. That parameter is always set to either 5
or 10 depending on the case to be run. This code compiles and
executes fine with the Cray F90, MIPSPro F90, and PGHPF (F95)
compilers. However, the NAG compiler "NAGWare Fortran 95 compiler
Release 4.0a(341)" compiles and gives the following errors:
Error: solver.cpp.f, line 671: Third subscript (6) is greater than upper bound (5) for array Z
Error: solver.cpp.f, line 672: Third subscript (6) is greater than upper bound (5) for array Z
It is true that the listed lines WOULD reference outside the bounds of
z's third dimension, IF those lines were executed. The if test
explicitly prevents this by checking if 'nd' is 10 or not. So
logically and in execution, there is no problem.
Does the standard say this is expressly illegal, that the behavior is
undefined so vendor determined or does the code meet the standard?
I'm not asking about style convention or ways to fix this. As I said,
several other compilers handle this code just fine. I am interested
because NAG gives an error rather than just a warning and I can find
no way to disable it or lessen the severity.
Thanks for your input.
Spencer
$> cat size.h
c... Number of grid intervals along icosahedral diamond edge:
parameter(mt= 32)
c... Number of grid intervals along edge of local subdomain:
parameter(nt=16)
c... Number of diamonds mapped to a local process (5 or 10):
parameter(nd= 5)
c... Note: Number of processes is given by (mt/nt)**2*10/nd.
c... Number of radial layers:
parameter(nr= mt/2)
c... Number of diamonds dimension for opr array (1, 5 or 10):
parameter(ndo= nd)
c... Note: If there is no lateral viscosity variation, ndo may
c... be set to 1; otherwise, it must be set equal to nd.
c... Number of grid points (vertices) in local subdomain:
parameter(nv= (nt+1)**2*nd*(nr+1))
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|