Andrew Ross wrote:
> On Thu, Feb 12, 2009 at 04:14:57PM -0800, Alan Irwin wrote:
>> On 2009-02-12 15:01-0700 Orion Poplawski wrote:
>>
>>> Orion Poplawski wrote:
>>>> #2 0x0000000010001e84 in x23f ()
>>>> at /builddir/build/BUILD/plplot-5.9.2/fedora/examples/f77/x23f.f:326
>>>> 326 call plsfci(0)
>>>>
>>> This is clearly wrong. plsfci takes a 64-bit integer. The attached patch
>>> fixes. The x23f.f90 example uses "0_plunicode" to specify the type. I
>>> don't
>>> know if "PL_INT_0" is the best name, but it shows the general solution.
>> Hi Andrew,
>>
>> I mostly address this to you since you were the pl[gs]fci implementer for
>> most languages (as discussed in a thread started by you last July 31). At
>> the time, I found a similar error to Orion's for the f95 case, and you
>> almost immediately found a fix. At the time we were overly focussed on just
>> getting something to work, but in retrospect I have some questions about the
>> whole approach taken to deal with the f77 bindings (and probably other
>> bindings as well) for pl[sg]fci.
>>
>> I notice the following comment from you in bindings/f77/scstubs.c.
>>
>> "Note: Fortran does not have unsigned integers so we need to use a
>> 64 bit signed integer which corresponds to a fortran integer*8
>> in order to contain the number."
>>
>> Could you explain that comment? My question is why is it necessary to use
>> the 64-bit type PLINT64 at the C level of the f77 interface (and therefore
>> 64-bit types in all calling fortran routines) when only 32-bits are actually
>> required to store the unsigned bit pattern?
>
> The real problem is that PLUNICODE was defined as a unsigned 32-bit
> integer. Many languages, including fortran do not have unsigned types,
> and so we only have 31 bits available for the value. The fact that the
> top bit is always set in an fci character means that we can never
> represent these numbers using a 32-bit integer. Of course we can try
> various tricks casting unsigned integers to a signed integer - which is
> what you did, but obviously this doesn't work. It is also potentially
> confusing for the user who queries the value of an fci and doesn't get
> the value they expect. We chose to go for 64-bit integers for these
> languages to ensure the values fitted. With hindsight a safer choice
> would have been to make PLUNICODE an signed 32-bit int, but it's a bit
> late for that now.
>
>> According to "info gfortran" typeless BOZ constants (i.e., binary, octal, or
>> hexadecimal bit patterns) are allowed anywhere that ordinary integers can be
>> used, and there is a similar statement in the Intel fortran compiler
>> programmer's reference. For gfortran I tried the following simple test
>> code:
>>
>> integer*4 hello
>> hello = Z'80000001'
>> write(*,*) hello
>> end
>>
>> That would not compile by default. It complained about an overflow. I think
>> that is a gfortran implementation error since the size of the BOZ constant
>> on the right is not larger than the size of the integer*4 on the left, and
>> no such error would have occurred it I had said
>>
>> hello = -2147483647
>>
>> instead. However, when I specified the option -fno-range-check, the above
>> source code compiled, and the resulting executable gave the correct result,
>> -2^31 + 1 = -2147483647. I assume from the writeup in the Intel Fortran
>> programmer's reference manual, you would get the same result from Intel
>> Fortran (and perhaps other modern Fortran compilers as well?). In any case,
>> using a typeless BOZ constant to make sure the most significant bit is set
>> to mark the integer as an FCI is an unlikely case which normally would not
>> happen since if you don't specify that FCI marker, the C code for plsfci
>> applies it anyway. Also, when you look at plgfci, it should just fill the
>> 4 bytes of memory with the appropriate bit pattern, and I cannot see what
>> could go wrong if those 4 bytes of memory were integer*4.
>>
>> Anyhow, I am tentatively concluding we should be doing absolutely nothing
>> special at the f77 interface level to deal with pl[sg]fci. We simply want 4
>> bytes sent to the C library or returned from it, and integer*4 should have
>> sufficient storage for the task, if we don't interfere at the interface
>> level to translate to 8 bytes and that back to 4 bytes again.
>>
>> Andrew, do you see anything obviously wrong with the simple approach I just
>> outlined for transferring a 4-byte bit pattern from the f77 level to our C
>> library and back again?
>
> It sounds like your approach would work for at least gfortran and
> probably ifort. It is not particularly nice, but neither is the current
> solution. We need to make it clear that fci is only to be thought of as
> a 4 byte bit pattern. We may run into problems with other compilers at
> some stage. We will also need to bodge example 23 to print out the fci
> value correctly.
>
> I'm happy for you to give it a try.
>
> Andrew
>
Hi,
I think this is an f77 issue only. For f95 see below.
The reason for the error is a mismatch between the fortran and c code.
For a call such as in x023f
call plsfci(0)
an f77 compiler will generate an integer*4 temporary for the argument 0 and
pass that address to PLSFCI (see f77/scstubs.c) . However PLSFCI interprets it
as an integer*8 (PLINT64) pointer taking in the adjacent 4 bytes. It is only
luck that this code works with other compilers and architectures.
An f77 compiler will also generate the wrong code for any calls to plsfci with
an integer*4 variable.
When Orion added the integer*8 parameter the f77 compiler would have created an
integer*8 temporary and the program worked as expected.
f95 compilers should generate the correct integer*8 code from the module
declaration.
Kind Regards
Terrence
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
