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!nntp.giganews.com!newscon06.news.prodigy.com!prodigy.net!newsdst02.news.prodigy.com!prodigy.com!postmaster.news.prodigy.com!newssvr11.news.prodigy.com.POSTED!2febb241!not-for-mail Reply-To: "Nasser Abbasi" From: "Nasser Abbasi" Newsgroups: comp.lang.ada,comp.lang.fortran References: <0ugu4e.4i7.ln@hunter.axlog.fr> <%P_cg.155733$eR6.26337@bgtnsc04-news.ops.worldnet.att.net> <6H9dg.10258$S7.9150@news-server.bigpond.net.au> <1hfv5wb.1x4ab1tbdzk7eN%nospam@see.signature> <4475DA61.3080001@comcast.net> <44762F55.4050106@cits1.stanford.edu> <87hd3d1472.fsf@ludovic-brenta.org> <1hfxsjh.t88mchrssv9cN%nospam@see.signature> <1hfxy4r.1sv2j76l6cgg1N%nospam@see.signature> Subject: Re: Bounds Check Overhead X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-RFC2646: Format=Flowed; Original Message-ID: NNTP-Posting-Host: 69.235.235.207 X-Complaints-To: abuse@prodigy.net X-Trace: newssvr11.news.prodigy.com 1148671524 ST000 69.235.235.207 (Fri, 26 May 2006 15:25:24 EDT) NNTP-Posting-Date: Fri, 26 May 2006 15:25:24 EDT Organization: SBC http://yahoo.sbc.com X-UserInfo1: OXZQRWKGPRRQBW@YOZOVOFXBWR\HPCTL@XT^OBPLAH[\RWYAKVUOPCW[ML\JXUCKVFDYZKBMSFX^OMSAFNTINTDDMVW[X\THOPXZRVOCJTUTPC\_JSBVX\KAOTBAJBVMZTYAKMNLDI_MFDSSOLXINH__FS^\WQGHGI^C@E[A_CF\AQLDQ\BTMPLDFNVUQ_VM Date: Fri, 26 May 2006 19:25:24 GMT Xref: g2news2.google.com comp.lang.ada:4511 comp.lang.fortran:10310 Date: 2006-05-26T19:25:24+00:00 List-Id: Hello "Richard Maine" wrote in message news:1hfxy4r.1sv2j76l6cgg1N%nospam@see.signature... > Nasser Abbasi wrote: > > Internal procedures are not compiled separately. Therefore, the odds of > catching things like this in an internal procedure are far better. It > still is not guaranteed. I might have seen some bugs resulting form > uncaught errors in that situation. But the odds are at least better. > Ok, you are correct, the Fortran example was using an external proc (even though it was in the same source file) while the Ada one used an internal proc. Here is a Fortran one that is using internal procedure that attempts to change the loop counter, so that now we have the same type of code. In Ada we call an internal proc to try to update a loop counter, and in Fortran we call an internal proc to try to update a loop counter. I hope this you'll find it to be a better test. $ cat a.f90 ---------------------- PROGRAM MAIN DO I=1,10 CALL foo(I) PRINT *,I END DO CONTAINS SUBROUTINE foo(I) I=I+1 END SUBROUTINE END PROGRAM MAIN ------------------ $ g95 a.f90 $ ./a.exe 2 4 6 8 10 12 14 16 18 20 Please note that I did not use the intent(in ) in the Fortran internal proc(), this is by purpose. I wanted to see if the compiler will detect that a call is being made to a proc which is taking a loop counter as an argument, where it does not have intent(in) on that argument declared. I do not think this is too hard for the compiler to check, but I can be wrong. I would have to assume then that this is a g95 issue where it just does not do this extra check if it is supposed to be part of the Fortran standard to try to check against loop counters updates. thanks, Nasser