This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: runtime array bounds checking in intrinsics


On Thu, 14 Apr 2005 12:40:21 -0700
Steve Kargl <sgk@troutmask.apl.washington.edu> wrote:

> On Thu, Apr 14, 2005 at 09:24:47PM +0200, Thomas Koenig wrote:
> > Looking at the code to spread, it would be fairly easy to add
> > runtime dimension checks to the code.  The nice thing is that it
> > could all be done in the setup phase, so there would be relatively
> > additional overhead for the bounds checking and none during the
> > execution of the actual operation.  The same goes for a lot of other
> > array intrinsics.
> > 
> > The main problem I see is how to handle this when bounds checking is
> > turned off.  We could
> > 
> > - issue an error anyway
> 
> This looks like the program will incur a performance penalty.
> 
> > - Add an extra argument or a flag saying "don't check this" (yuck)
> 
> yuck :-)
> 
> > - Multiply the number generated files by two
> 
> I think this is the best option of the three given.  Since
> the files are generated, there should be a minimum of effort
> for maintenance and a program will not incur performance
> penalties in absences of bounds checking.
> 
> -- 
> Steve

 I think we might have a third option, a set of stubs which do array bounds checking
 and uses the regular routines in the lib. the stubs should be much smaller than a
 complete second lib.
 If one is careful in the linking phase, ( perhaps an own section ), the stubs can be
 kept apart from the regular libs in memory and thus not even mapped if not used,
 and therefore will not incur any performance degradation even from memory locality.

 Thus to compile for bounds checking we only generate code with another prefix for
 the lib, fx. GFC_LIB_BC_<name>, this is only one suggestion on how to do this.
 The main thing is that we get rid of the table and hopefully do the same thing without
 one level of indirection, also its easy to extend the compiler to generate the
 necessary code, it's only a flag.

 / regards, Lars Segerlund.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]