>> On 2008-08-01 22:24+0100 Andrew Ross wrote:
>>
>> I also noticed the integer(16) and did not like it since in fortran 77
>> at
>> least integer*8 would correspond to 64 bits and integer*16 to 128 bits.
>> Arjen, do you know about this?
>>
>>> Can you test again with my fix and see what happens?
>>
>> The f95 example build errors are gone now. Also, the resulting C and
>> f95
>> results agree exactly now. So your change appears to be a good fix
>> for the 64-bit problem I found.
>>
>
> KIND numbers in Fortran 95 do not have to indicate the number of bytes
> (despite the fact that many compilers do use that number to indicate
> the KIND). I am not sure why you get a kind 16 - I will have to look
> into that, but I suspect that the way to generate the KIND number in
> CMakeLists.txt is not quite correct (or there is a problem in the
> compiler).
>
> I will look into this one.
>
I found the cause: z'xxx' returns an integer whose kind is not
related to the actual number but is some predefined
compiler-dependent value.
See this little program:
program longint
integer, parameter :: z7 = kind(z'70000000')
integer, parameter :: z8 = kind(z'80000000')
write(*,*) "z'0': ",z'0', kind(z'0')
write(*,*) "z'70000000': ",z'70000000', kind(z'70000000'), z7
write(*,*) "z'80000000': ",z'80000000', kind(z'80000000'), z8
end program
The result on a 32-bits PC with some version of gfortran (under Cygwin)
is:
z'0': 0 8
z'70000000': 1879048192 8 8
z'80000000': 2147483648 8 8
and with some version of g95 (under MinGW):
z'0': 0 4
z'70000000': 1879048192 4 4
z'80000000': -2147483648 4 4
So, depending on the compiler, z'xxxx' gives a default integer
(g95, this version) or an integer that is larger than that
(gfortran; quite possibly the largest integer kind that is supported).
If the compiler on a 64-bits platform behaves like gfortran in my
case, then the result is very likely to be a 16-bytes integer.
My suggestion is to use:
integer, parameter :: plunicode = selected_int_kind( 10 )
This will give a kind number for kinds just large enough
to fit a number like 2**32, actually 10**10 will fit too.
On most platforms (certainly the popular ones) this leads
to a 64-bits integer.
I have not changed the CMakeLists.txt file yet, because I first
want to make sure that this is an acceptable solution.
Regards,
Arjen
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
