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=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no 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!news3.google.com!news4.google.com!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!cyclone1.gnilink.net!spamkiller.gnilink.net!gnilink.net!trnddc04.POSTED!87bf9b22!not-for-mail
From: Dan Nagle <dannagle@verizon.net>
Reply-To: dnagle@erols.com
Organization: Purple Sage Computing Solutions, Inc.
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
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>
   <SuEdg.167361$eR6.86840@bgtnsc04-news.ops.worldnet.att.net>
   <1148655583.421963.226740@j55g2000cwa.googlegroups.com>
   <rTEdg.167474$eR6.62378@bgtnsc04-news.ops.worldnet.att.net>
 <1148668910.867823.99110@j73g2000cwa.googlegroups.com>
In-Reply-To: <1148668910.867823.99110@j73g2000cwa.googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <AbIdg.258$lN5.55@trnddc04>
Date: Fri, 26 May 2006 18:56:32 GMT
NNTP-Posting-Host: 70.108.4.182
X-Complaints-To: abuse@verizon.net
X-Trace: trnddc04 1148669792 70.108.4.182 (Fri, 26 May 2006 14:56:32 EDT)
NNTP-Posting-Date: Fri, 26 May 2006 14:56:32 EDT
Xref: g2news2.google.com comp.lang.ada:4507 comp.lang.fortran:10306
Date: 2006-05-26T18:56:32+00:00
List-Id: <comp.lang.ada>

Hello,

gary.l.scott@lmco.com wrote:
> I was just thinking that if the loop counter was in fact declared to be
> volatile, that the declaration of such should cause the compiler to
> diagnose it as an incompatible loop index variable (i.e. F2k8+).

In 04-007, at 167[22:23], the <do-index> may not be redefined.

The volatile attribute, at 85[5:6], specifies that the variable may
become undefined or redefined by a means outside the program.

I suppose it's a theorem left for the reader to prove that
a do-index should not be volatile, or at worst, if it is,
the volatile part is ineffective.

I'll ask on the J3 list to see whether there's sentiment
for addressing this directly, or if I missed something
in my quick perusal of the standard.

-- 
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.