RE: Circumventing Loop Index Tampering Restrictions w/ Contained Subprograms

[Javier Trelles <jtrelles at haifire dot com>]

Steve,

    Thank you.

    If possible, I would like to request that the gfortran development team
consider adding limited compile time checks for this type of problem.  I can
see how this would be a challenge across multiple files.  In principle it
should be possible for subprograms contained in modules that have already
been compiled.  However, since I do not know the structure of gfortran .mod
files, I don't know if it can be done in practice.  It does seem to me to be
possible to catch instances contained in the same file.  This will
definitely take care of problem for subprograms CONTAINed within another
program unit.  (Yes, this is the problem I'm most interested in.)  It would
also teach the programmer to look out for these sorts of problems.  Since
the mind of the programmer is still the best debugger that we have,
multi-file instances of this loop corruption problem might then be
investigated/caught at development time....  Thank you for considering my
request.

Best Wishes,

Javier

-----Original Message-----
From: Steve Kargl [mailto:sgk@troutmask.apl.washington.edu] 
Sent: Monday, February 15, 2010 11:52 PM
To: Javier Trelles
Cc: fortran@gcc.gnu.org
Subject: Re: Circumventing Loop Index Tampering Restrictions w/ Contained
Subprograms

On Mon, Feb 15, 2010 at 03:10:58PM -0500, Javier Trelles wrote:
>
> Is there a way to change this so that it catches the problem at compile
time
> (or, alternatively, at link time)?  Don't get me wrong, it's not as if I
> don't appreciate the current capabilities.  It's that the application I'm
> working with can take many days to complete a simulation.  Worse still,
> depending on inputs, bad code might not be accessed until someone
specifies
> the right combination.  I looked through the gfortran and gcc
documentation
> but could not find a way to activate compile time checks.  So, once again
I
> ask, with my chin on my sternum, can someone PLEASE point me to the
webpage
> that explains how to do this?
>

Unfortunately, the answer is 'no'.  Consider

program test
  integer i
  do i = 1, 10
     call prn(i)
  end do
end program test

subroutine prn(i)
   integer i
   i = i + 1
   print *, i
end subroutine

where the two subprograms are in different files.  There
is no way for gfortran at compile time to determine that
prn() has violated a prohibition placed on the program(mer)
by the standard.

With -fcheck=do, a simple check is written into each
loop to check if the iterator has changed.  It's
your only option, short of a full code audit, with gfortran.
--
Steve