[Beowulf] Please help test compiler/hardware issue

[Peter St. John]

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 <james_cuff at harvard.edu> 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:
>
> jcuff at harold:~$ uname -a
> Linux harold 2.6.20-15-386 #2 Sun Apr 15 07:34:00 UTC 2007 i686 GNU/
> Linux
>
> jcuff at harold:~$ cat /proc/cpuinfo | grep "model name"
> model name      : Intel(R) Pentium(R) 4 CPU 2.53GHz
>
>
> jcuff at harold:~$ gfortran -O3 -o tt test.f90
> jcuff at harold:~$ 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:
>
> [jcuff at gw ~]$ cat /proc/cpuinfo  | grep "model name"
> model name      :                 Intel(R) Celeron(R) CPU 2.93GHz
>
> [jcuff at gw ~]$ 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
>
>
> [jcuff at gw ~]$ 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, <orion at cora.nwra.com> 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                  orion at cora.nwra.com
> > Boulder, CO 80301              http://www.cora.nwra.com
> >
> > _______________________________________________
> > Beowulf mailing list, Beowulf at beowulf.org
> > To change your subscription (digest mode or unsubscribe) visit
> > http://www.beowulf.org/mailman/listinfo/beowulf
> >
>
> _______________________________________________
> Beowulf mailing list, Beowulf at beowulf.org
> To change your subscription (digest mode or unsubscribe) visit
> http://www.beowulf.org/mailman/listinfo/beowulf
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.beowulf.org/pipermail/beowulf/attachments/20070504/e11ba066/attachment.html>