On Sun, Aug 10, 2008 at 01:24:29PM +0200, Arjen Markus wrote: > >> 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.
Arjen, Further testing with ifort and old versions of gfortran has also lead to problems with my original implementation of plunicode using kind. I've followed your recommendation and it seems to work more reliably on the compilers available to me. Thanks Andrew ------------------------------------------------------------------------- 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
