From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM
	autolearn=ham autolearn_force=no version=3.4.4
X-Google-Thread: 103376,c4cb2c432feebd9d
X-Google-Thread: 1094ba,c4cb2c432feebd9d
X-Google-Attributes: gid103376,gid1094ba,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!wn13feed!worldnet.att.net!bgtnsc04-news.ops.worldnet.att.net.POSTED!b680011b!not-for-mail
From: Dick Hendrickson <dick.hendrickson@att.net>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US;
 rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
Newsgroups: comp.lang.ada,comp.lang.fortran
Subject: Re: Bounds Check Overhead
References: <mubcg.13522$fb2.853@newssvr27.news.prodigy.net>
	<epcs4e.qb8.ln@hunter.axlog.fr>
 <tHkcg.6937$kR6.484@trnddc05>	<0ugu4e.4i7.ln@hunter.axlog.fr>
	<PkHcg.90575$Fs1.7198@bgtnsc05-news.ops.worldnet.att.net>
	<To_cg.10095$S7.4017@news-server.bigpond.net.au>
	<%P_cg.155733$eR6.26337@bgtnsc04-news.ops.worldnet.att.net>
	<6H9dg.10258$S7.9150@news-server.bigpond.net.au>
	<XVadg.76594$_S7.45873@newssvr14.news.prodigy.com>
	<1hfv5wb.1x4ab1tbdzk7eN%nospam@see.signature>
	<pan.2006.05.25.12.11.52.919554@linuxchip.demon.co.uk.uk.uk>
	<4475DA61.3080001@comcast.net>
 <m2mzd569l9.fsf@grendel.local>	<44762F55.4050106@cits1.stanford.edu>
 <87hd3d1472.fsf@ludovic-brenta.org> <3cBdg.6255$oa3.2407@trnddc08>
In-Reply-To: <3cBdg.6255$oa3.2407@trnddc08>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <SuEdg.167361$eR6.86840@bgtnsc04-news.ops.worldnet.att.net>
NNTP-Posting-Host: 2b3741ab6b778678a38624d05f07a9e4
X-Complaints-To: abuse@worldnet.att.net
X-Trace: bgtnsc04-news.ops.worldnet.att.net 1148654642
 2b3741ab6b778678a38624d05f07a9e4 (Fri, 26 May 2006 14:44:02 GMT)
NNTP-Posting-Date: Fri, 26 May 2006 14:44:02 GMT
Organization: AT&T Worldnet
Date: Fri, 26 May 2006 14:44:02 GMT
Xref: g2news2.google.com comp.lang.ada:4492 comp.lang.fortran:10289
Date: 2006-05-26T14:44:02+00:00
List-Id: <comp.lang.ada>



Dan Nagle wrote:
> Hello,
> 
> Ludovic Brenta wrote:
> 
> <snip>
> 
>> And that's why Ada specifies that I cannot change inside the loop, and
>> is undefined outside the loop; see ARM 5.5 (9, 10).
>>
>> You seem to imply that Fortran has a similar rule, but that compilers
>> do not enforce that rule, and therefore have to perform range checking
>> to enforce a non-existent language rule about array access.  I am
>> confused.  Could you clarify?
> 
> 
> A loop index cannot be changed within the loop.
It's actually a stronger rule, or maybe Dan's statement
could have been worded stronger.  The loop index can't
be changed while the loop is executing.  This covers
direct assignment in the loop and also in procedures
called from within the loop.
      Given something like
      COMMON I
      DO I = 1,10
         call something (I)
         call something_else()
      enddo
"something" is not allowed to change it's argument and
neither "something" nor "something_else" is allowed to
change the variable in common.  This prohibition flows
down the entire call tree from these routines.  And that's
why it's hard to check.

Dick Hendrickson
> Some compilers may have an option to allow older code
> to work without modification by allowing modification
> within the loop.  (Basically, this is to avoid re-certification
> costs incurred when the code is modified in any way.)
> 
> The value at loop termination is defined to be the last value
> within the loop, plus the increment.  For a concurrent loop
> or for a forall, the index values are undefined outside
> the loop.
>