Most common run-time errors?

21

I created xautofix.py to handle simple cases of errors (1) and (2) above.

Compile/runtime-driven first-pass auto-fixer for common Fortran errors.

Typical commands:

python xautofix.py foo.f90
python xautofix.py foo.f90 --in-place --diff
python xautofix.py foo.f90 --runtime
python xautofix.py foo.f90 --runtime --run --tee-both

Notes:

  • Supports compile-time and runtime fix loops (bounded by --max-iter).

  • Applies static allocatable safety fixes before build loops:

    • guards unsafe deallocate(x) as if (allocated(x)) deallocate(x).

    • inserts guarded deallocate before allocate(x(...)) in loop contexts.

  • Includes formatted-I/O mismatch fixes from static analysis and runtime diagnostics.

  • --runtime defaults to in-place editing unless --out is explicitly provided.

For example, python xautofix.py xalloc_bug.f90 --out temp.f90 transforms

program xalloc_bug
implicit none
integer :: i
real, allocatable :: x(:)
deallocate(x) ! wrong
do i=1,3
   allocate (x(1000)) ! wrong for i > 1
   call random_number(x)
   print "(i0)", sum(x)/size(x) ! wrong format
end do
end program xalloc_bug

to

program xalloc_bug
implicit none
integer :: i
real, allocatable :: x(:)
if (allocated(x)) deallocate(x)
do i=1,3
   if (allocated(x)) deallocate(x)
   allocate (x(1000))
   call random_number(x)
   print "(g0.6)", sum(x)/size(x)
end do
end program xalloc_bug

with more aggressive options –drop-deallocate --hoist-loop-allocate you get

program xalloc_bug
implicit none
integer :: i
real, allocatable :: x(:)
allocate (x(1000))
do i=1,3
   call random_number(x)
   print "(g0.6)", sum(x)/size(x)
end do
end program xalloc_bug
22

I would like this to be part of the compiler. LFortran catches most of these (eventually all) at runtime, and having stronger static analysis would help also to move as many runtime errors to compile time.

5 Likes
23

This is my most common error during development, that can be quite frustrating.
Typically I start with “write (98,*) …”, but after a while I will introduce a format statement to make the trace file more readable.
Then continue developing and introduce more variables in the I/O list; perhaps a shared format statement, then get a cryptic error. The (win) Gfortran version I am using often does not give a good traceback.
Looking for that quick patch, but too lazy !!