EXC!TING - run-time error undefined variable

[Tobias Burnus]

Hello,

Maybe someone has an idea. I don't know whether this is a compiler error or an Exciting error.

this is with exciting-0.9.53 running on
examples/Al.

This example runs just fine with a debugging optimized ifort 9.1 (ifort -C -check all -warn all,nodec,interfaces -gen_interfaces -traceback -fpe0 -fpstkchk -g -O0).

However, if I run it with the NAGWare compiler 5.1, it crashes with an uninitialized variable in
spline.f90.

I traced it back up to rhoinit. Here, the array rhomt(:,:,:) is nicely initialized with 0.0.
Then rfmtctof is called with rhomt(:,:,:).
In rfmtctof this variable is rfmt(lmmaxvr,nrmtmax,natmtot).
lmmaxvr = 64 and natmtot = 1.

In rfmtctof rfinterp is called with:  rfmt(lm,1,ias). But this is only one single number and no array????

In rfinterp the fourth and eigth element are supposed to be arrays of the size fi(ldi,ni) and fo(ldo,no). Here, ldi = 256 and ni=107.

If I now do a write(*,*) fi in rfinterp, NAG's checking claims (undefined can mean: not initialized):

Reference to undefined variable FI
Program terminated by fatal error
In RFINTERP, line 43 of rfinterp.f90

Actually, I don't understand how it can possibly work, but seemingly it does. What do I (and NAG f95) overlook here?

Tobias

[exciting]

Thanks for the careful testing!

That piece of code is OK though: it's a standard Fortran trick to pass in an array element into a subroutine instead of the array itself, and the routine will treat it as an array indexed from that point. This is because Fortran always works with pointers.

NAG may be checking things too zealously to alow this (very useful) technique.

Kay.

[Tobias Burnus]

> That piece of code is OK though: it's a standard
> Fortran trick to pass in an array element into a
> subroutine instead of the array itself, and the
> routine will treat it as an array indexed from
> that point. This is because Fortran always works
> with pointers.

Thanks for pointing out. I probably need to find a book with tricks in Fortran. (Or maybe re-reading the Fortran 95/2003 book is enough.)

> NAG may be checking things too zealously to alow
> this (very useful) technique.

Hmm, I'm not sure. I tried a simple program, but here it worked ok with NAG -C=all -C=undefined. I still need to find a minimal program which causes this error.

I re-tested with an unmodified exciting tree and NAG does not crash anymore (NAG 5.1(216) and no checks). I think it did crash with the rather buggy 5.1(210) w/o checks. (With -C=undefined -C=all it still claims F is undefined.)

With gfortran (current trunk version) it crashes unless I apply the patch (-> bug 1503149), but then it works. (Using the boundary check with gfortran does not work [gfortran bug 27965] as valid code produces the array bound error.)

Tobias

[Tobias Burnus]

I played around a bit more and I see a problem with the array length. Maybe I missunderstand something as NAG spits out a different error message in my sample case than in the real case.

For the Al example, I get at the call of rfmtctof:
  real(8),intent(inout) :: rfmt(lmmaxvr,nrmtmax,natmtot)
with
  lmmaxvr = 64, nrmtmax = 425, natmtot = 1
this are 64*425*1 = 27200 elements.

In
  call rfinterp(nrcmt(is),...,ld,rfmt(lm,1,ias),
nrcmt(1) = 107 and ld = 256, which are 27392 items.

As 27392 > 27200 I see a problem here.

Tobias

PS: ifort -check uninit all does not catch uninitialized values as it currently only checks scalars and not vectors. It also does not detect such array-size problems.

[exciting]

There is no problem:

The element accessed by rfinterp is

lm + (i-1)*ld

where i runs from 1 to ncrmt(is). Therefore the first element is when lm=1 and i=1, which is 1. The last element accessed is when lm=lmmaxvr and i=nrcmt(is). In the case of Al this is

64 + (107-1)*256
= 27200

Kay.

[Tobias Burnus]

With NAG f95 5.1(224) and EXC!TiNG 0.56 it finally does not crash anymore when turning off checking. -- hooray! (With all checking turned on, there is still the uninitialized-variable "F" error in SPLINE, line 42 of spline.f90, which I will ignore for now.)

With gfortran 4.2.0 20060621 and EXC!TiNG 0.56 it does not crash anymore either -- another hooray! (Thanks for fixing bug 1503149.)

As before: No problems with Intel Fortran 9.1 and (new compiler) no problems with Sun Fortran 95, 8.3_18.

Tobias