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.

If it were C like this:

int *a;
a = malloc(10);
for(i = 0; i< 10; i++) a[i] = i;
*(a[5]) = 5;

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.

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.

Peter



On 5/3/07, James Cuff <[EMAIL PROTECTED]> wrote:


Hi Orion,

I'm thinking you may have bad memory/hardware on one of those nodes
here mate...

Compiles and runs fine here in 32 bit ubuntu fiesty:

[EMAIL PROTECTED]:~$ uname -a
Linux harold 2.6.20-15-386 #2 Sun Apr 15 07:34:00 UTC 2007 i686 GNU/
Linux

[EMAIL PROTECTED]:~$ cat /proc/cpuinfo | grep "model name"
model name      : Intel(R) Pentium(R) 4 CPU 2.53GHz


[EMAIL PROTECTED]:~$ gfortran -O3 -o tt test.f90
[EMAIL PROTECTED]:~$ time ./tt
^C
real    8m11.766s
user    8m5.862s
sys     0m4.280s


Also your 64 bit static compiled version runs fine even on a rather
crappy "64 bit" Celeron I have on FC 5:

[EMAIL PROTECTED] ~]$ cat /proc/cpuinfo  | grep "model name"
model name      :                 Intel(R) Celeron(R) CPU 2.93GHz

[EMAIL PROTECTED] ~]$ uname -a
Linux 2.6.20-1.2312.fc5 #1 SMP Tue Apr 10 15:14:58 EDT 2007 x86_64
x86_64 x86_64 GNU/Linux


[EMAIL PROTECTED] ~]$ time ./testatob
^C
real    5m5.794s
user    3m38.785s
sys     0m9.890s


Hope this helps.

Best,

j.

--
James Cuff, D. Phil.
Director of Research Computing, Life Sciences Division.
Bauer Laboratory, 7 Divinity Avenue, Cambridge, MA. 02138
Tel: 617-384-5065   Direct Dial: 617-384-7647


On May 3, 2007, at 8:34 PM, <[EMAIL PROTECTED]> wrote:

> >
> > Okay, I have a test case for the problem I reported before
>
> Statically compiled binary at http://www.cora.nwra.com/~orion/
> testatob.bz2
> for those of you without the PGF compiler to try.
>
> --
> Orion Poplawski
> Technical Manager                     303-415-9701 x222
> NWRA/CoRA Division                    FAX: 303-415-9702
> 3380 Mitchell Lane                  [EMAIL PROTECTED]
> Boulder, CO 80301              http://www.cora.nwra.com
>
> _______________________________________________
> Beowulf mailing list, [email protected]
> To change your subscription (digest mode or unsubscribe) visit
> http://www.beowulf.org/mailman/listinfo/beowulf
>

_______________________________________________
Beowulf mailing list, [email protected]
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf

_______________________________________________
Beowulf mailing list, [email protected]
To change your subscription (digest mode or unsubscribe) visit 
http://www.beowulf.org/mailman/listinfo/beowulf

Reply via email to