Re: moving toward a 3.0 release

[Joe Koski]

on 9/28/06 4:38 PM, John W. Eaton at address@hidden wrote:

> On 28-Sep-2006, David Bateman wrote:
> 
> | I'll have difficulties duplicating this work as my 4.0.1 gfortran gives
> | an error
> | 
> | "Fortran runtime error: Array reference out of bounds"
> | 
> | which no indication of the variable involved or the variable name.
> | Frankly quite useless. What version of gfortran are you using?
> 
> It's 4.1.2.
> 
> | So I therefore don't understand how this can happen..
> 
> I didn't get it either.
> 
> | Are we perhaps debugging a gfortran problem rather than an arpack
> | problem? I'll try installing g77 and see, but can't easily do that till
> | tomorrow..
> 
> I suppose that's possible.  I tried with g77 3.4.6 and haven't been
> able to duplicate the bounds error, but I still get random crashes in
> free() that look like they might be caused by buffer overruns.
> 
> jwe

John, David,

As a Fortran programmer for 40+ years, I have chased similar bugs. Here are
some off-the-wall thoughts that may or, more likely, may not help.

You mentioned common blocks. If you are working with routines that were
converted from 32 bits to 64 bits, or you have mixed 32 bit and 64 bit
variables, watch the common block declarations, even in routines that are
not directly involved. Implicit declarations such as real*8 (a-h,o-z) can be
killers if not applied uniformly in every routine.

What can happen is that, since only the array start is passed to a Fortran
subroutine, if the common blocks count differently in different routines,
you can get out of sync, and a routine that you aren't suspecting can
overrun an array by using 64 bits in one routine which was 32 bits in
another. Sometimes variables that are typed outside the integer Fortran
rules (mu as viscosity, for example) can be 32 bits in some routines and 64
bits in others. 

Have you applied the -r8 declaration to gfortran to see if that solves the
problem?

Right now gfortran-4.2 is broken for building octave on Macs, so I have been
using g95 for that. The g95 compiler seems to be more stable and further
developed than gfortran. That's just a personal opinion based on compiling
twenty or thirty different Fortran codes. On the negative side, I don't
thing g95 gets along that well with gdb.

Good luck. The answer to dilemmas such as these usually came to me while
jogging at lunch. Walking away usually helps.

Joe