octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: new branch in CVS archive


From: Clinton Chee
Subject: Re: new branch in CVS archive
Date: Mon, 04 Apr 2005 13:44:04 +1000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2

John,

Thanks for integrating the 64 bit changes, as well as the 32-64 switch
in the configure script.

Regarding the long long and similar issues, I guess we just need to be
careful and test it on each new 64bit systems. In a recent Intel Itanium
workshop I attended, I found this:

Unix/Linux (I32, LP64 model)
        => int-32   long-64   pointers-64

Windows 64 ( IL32, P64 model)
        => int-32   long-32   pointers-64

.... should we assume long long int in Windows64 is 64bit?


Another Note - for the fortran part (eg libcruft),  it should be
compiled with a -i8 switch, unless it default to 8 byte for fortran
integers.


Speaking of systems, I'm having rough time with our new Itanium64.
Things were fine when I completed the 64bit port on our old SGI IRIX
(MIPS compilers).

On the new Intel Itanium2, Intel IA64 compilers (icc.icpc, ifort)
compiles but hangs octave upon startup.
I tried GCC with g95 and it runs but fails with certain functions like
LU decomposition - may be g95 bug as you said).

PowerMAC G5 - have to rely on GCC and G95 - fail to link at the last
moment - complain about undefined functions.

My other options, are to verify the G95 bug if possible, find a new
Compiler???, or a another 64bit machine like an AMD64 cluster???









John W. Eaton wrote:
> On  1-Apr-2005, David Bateman <address@hidden> wrote:
> 
> | Shouldn't the default behavior for now be to have this disabled by 
> | default, at least till its tested a bit more? It seems without either 
> | --enable-64 or --disable-64 the default is to enable it....
> 
> I can switch the default when the branch is merged.  I ran the current
> configure script on an Itanium system with --disable-64 and it prints
> 
>   64-bit array dims and indexing:     false
> 
> at the end of the run, so it seems to work for me.
> 
> | I'd also suggest including the "long long" class as a possible index, 
> | since there is no reason to exclude this codes use on 32-bit platforms 
> | even if it will be significantly slower....
> 
> Sure, I can include long long easily enough, but for 64-bit indexing
> to really work, don't you also need 64-bit pointers?  Are there any
> 32-bit systems (what would that mean, 32-bit ints only?) that have
> 64-bit pointers, 32-bit ints, 32-bit long ints, and 64-bit long long
> ints?
> 
> jwe
> 

-- 


----------------------------------------------------------------------------
Clinton Chee
Computational Scientist
High Performance Computing Unit
Room 2075, Red Centre
University of New South Wales
Australia 2035
chee at parallel stop hpc stop unsw stop edu stop au
Tel: 61 2 9385 6915
----------------------------------------------------------------------------



reply via email to

[Prev in Thread] Current Thread [Next in Thread]