octave-maintainers
[Top][All Lists]
Advanced

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

Re: [OctDev] arpack: eigs crash with octave 3.0.5 compiled with --enabl


From: Jaroslav Hajek
Subject: Re: [OctDev] arpack: eigs crash with octave 3.0.5 compiled with --enable-64
Date: Sun, 7 Jun 2009 15:20:52 +0200

On Sun, Jun 7, 2009 at 3:12 PM, David Bateman<address@hidden> wrote:
> Alexander Barth wrote:
>>
>> On Fri, Jun 5, 2009 at 9:20 PM, David Bateman<address@hidden>
>> wrote:
>>
>>>
>>> Why not just use
>>> octave_idx_type if the fortran logical index is 8bit with --enable-64?
>>>
>>>
>>
>> This is in the end what I did, but I declared a macro
>> octave_f77_bool_type defined as octave_idx_type.
>>
>> The underlying assumption is that the Fortran compiler uses the same
>> amount of bytes for INTEGER and LOGICAL. I would prefer to "hide" this
>> assumption behind a macro since there might be some Fortran compilers
>> that handle things differently. (After all, it is quite wasteful to
>> allocate 8 bytes for a variable with only two states).
>>
>> I looked a bit around how the different Fortran compilers handle the
>> size of LOGICALs. For gfortran (with and without  -fdefault-integer-8)
>> and ifort (with and without -i8), the size of LOGICALs will always be
>> the size of INTEGER. However, with pgf90, the compiler option -i8,
>> leaves the size of LOGICALs to 4 bytes. Only the option -i8storage
>> allocates 8 bytes for INTEGER and LOGICAL.
>>
>> This reminds me also a bit of the assumption that size of a pointer
>> will always be the same as the size of an int in C. Such assumption is
>> the classical problem when porting a program to 64-bit CPU.
>>
>> Cheers,
>> Alex
>>
>
> Grrr, then we need an autoconf test that probes the number of bytes in a
> fortran logical type and sets your macro appropriately...
>
> D.

Do we? In fact, I think the Fortran standard requires the default
REAL, INTEGER and LOGICAL to be of equal size (numeric storage unit).
So, only some combinations of these flags are conforming in general. I
do not think Octave needs to be bulletproof in this regard, at least
not until a real need arises from practice. When you're altering the
sizes of default types, you're often breaking standard-conformance,
and you're therefore supposed to know what you're doing. Anyway, a
common practical advice is to avoid LOGICALs in external interfaces at
all and just use INTEGERs.

cheers

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz



reply via email to

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