<div>I don't understand what "allocatable" and "allocate" do. It would seem that atob writes an integer (assigned by a(i) = i) to an address which had also been specified by the a(i)=i assignment, and was not necessarily allocated to a. That would be expected to generate random errors, and since the example has hardcoded numbers like 8460901, it could write to a range that **normally** is writeable in user space, but which is not guaranteed to be by the allocation.
</div>
<div> </div>
<div>If it were C like this:</div>
<div> </div>
<div>int *a;</div>
<div>a = malloc(10);</div>
<div>for(i = 0; i< 10; i++) a[i] = i;</div>
<div>*(a[5]) = 5;</div>
<div> </div>
<div>that is, I'm presuming that the contents at the address "5" can be written with the value 5, but "5" is not necessarily in the address space allocated by malloc.</div>
<div> </div>
<div>I'm thinking this must not be what the subroutine ATOB does, maybe a call by reference instead of call by value confusion (to me). However, the example looks like it was written to show up a compiler dependency and not to stress test a CPU. In fact, it looks like it was written by a malicious C programmer :-) but I have an alibi.
</div>
<div> </div>
<div>Peter</div>
<div><br><br> </div>
<div><span class="gmail_quote">On 5/3/07, <b class="gmail_sendername">James Cuff</b> <<a href="mailto:james_cuff@harvard.edu">james_cuff@harvard.edu</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><br>Hi Orion,<br><br>I'm thinking you may have bad memory/hardware on one of those nodes<br>here mate...
<br><br>Compiles and runs fine here in 32 bit ubuntu fiesty:<br><br>jcuff@harold:~$ uname -a<br>Linux harold 2.6.20-15-386 #2 Sun Apr 15 07:34:00 UTC 2007 i686 GNU/<br>Linux<br><br>jcuff@harold:~$ cat /proc/cpuinfo | grep "model name"
<br>model name : Intel(R) Pentium(R) 4 CPU 2.53GHz<br><br><br>jcuff@harold:~$ gfortran -O3 -o tt test.f90<br>jcuff@harold:~$ time ./tt<br>^C<br>real 8m11.766s<br>user 8m5.862s<br>sys 0m4.280s<br><br><br>Also your 64 bit static compiled version runs fine even on a rather
<br>crappy "64 bit" Celeron I have on FC 5:<br><br>[jcuff@gw ~]$ cat /proc/cpuinfo | grep "model name"<br>model name : Intel(R) Celeron(R) CPU 2.93GHz<br><br>[jcuff@gw ~]$ uname -a
<br>Linux 2.6.20-1.2312.fc5 #1 SMP Tue Apr 10 15:14:58 EDT 2007 x86_64<br>x86_64 x86_64 GNU/Linux<br><br><br>[jcuff@gw ~]$ time ./testatob<br>^C<br>real 5m5.794s<br>user 3m38.785s<br>sys 0m9.890s<br><br><br>Hope this helps.
<br><br>Best,<br><br>j.<br><br>--<br>James Cuff, D. Phil.<br>Director of Research Computing, Life Sciences Division.<br>Bauer Laboratory, 7 Divinity Avenue, Cambridge, MA. 02138<br>Tel: 617-384-5065 Direct Dial: 617-384-7647
<br><br><br>On May 3, 2007, at 8:34 PM, <<a href="mailto:orion@cora.nwra.com">orion@cora.nwra.com</a>> wrote:<br><br>> ><br>> > Okay, I have a test case for the problem I reported before<br>><br>> Statically compiled binary at
<a href="http://www.cora.nwra.com/~orion/">http://www.cora.nwra.com/~orion/</a><br>> testatob.bz2<br>> for those of you without the PGF compiler to try.<br>><br>> --<br>> Orion Poplawski<br>> Technical Manager 303-415-9701 x222
<br>> NWRA/CoRA Division FAX: 303-415-9702<br>> 3380 Mitchell Lane <a href="mailto:orion@cora.nwra.com">orion@cora.nwra.com</a><br>> Boulder, CO 80301 <a href="http://www.cora.nwra.com">
http://www.cora.nwra.com</a><br>><br>> _______________________________________________<br>> Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org">Beowulf@beowulf.org</a><br>> To change your subscription (digest mode or unsubscribe) visit
<br>> <a href="http://www.beowulf.org/mailman/listinfo/beowulf">http://www.beowulf.org/mailman/listinfo/beowulf</a><br>><br><br>_______________________________________________<br>Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org">
Beowulf@beowulf.org</a><br>To change your subscription (digest mode or unsubscribe) visit <a href="http://www.beowulf.org/mailman/listinfo/beowulf">http://www.beowulf.org/mailman/listinfo/beowulf</a><br></blockquote></div>
<br>
!DSPAM:463b491b69781396896698!