Composed 13:35, 7 Nov. 2000
> Date: Mon, 6 Nov 2000 15:10:18 -0500
> From: Tom Clune <[log in to unmask]>
> To: [log in to unmask]
> 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 it does [have 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.
Some F77 compilers did provide bounds checking, but
of those that did, some resorted to tricks on the
pretext of "saving time", pretending that they did
(proper) subscript checking.
One was that if the computed address was within the
array, then it was "valid" (even if one or more subscripts
was out-of-bounds).
Subscript checking in F90 and F95 compilers is, in general, more rigorous
than in the days of F77.
> 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.
That doesn't mean that the code is correct.
> 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.
Use an INCLUDE for the offending code, or an extra parameter
in the existing INCLUDE to cover the offending subscript.
> 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))
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|