Hello,
At 15:10 06-11-2000 -0500, you wrote:
>
>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'
>:
! work around:
integer :: QWERTY = 6
!... Number of diamonds mapped to a local process (5 or 10):
parameter(nd= 5)
! ..
real z(0:nt,nt+1,nd,3,nr+1), s(6)
! Now z has dimension( , , 5 , 3 , )
>:
>:
> 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(4) = z(0,1,1,2,ir) - z(0,1, QWERTY,2,ir) <== (line 671.5)
I did not try to look it up in the Standard, nor did I try
this fragment on one of the available Fortran compilers, but ...
I suppose that the compiler may consider this to be out of bounds
because constant 6 > constant ND (=5).
> 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))
--
Meilleures Salutations,
Kindest Regards,
/---
Jan van Oosterwijk
Computing Centre
Delft University of Technology
Postbus 354
2600 AJ Delft
Netherlands / Pays-Bas
mailto:[log in to unmask]
Phone: +31 15 27 85017
Fax: +31 15 27 83787
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
