Re: Problem with ulonglong on SPARC

[Mark Dickinson <dickinsm at gmail dot com>]

Victor Stinner <victor.stinner@...> writes:

> Python had an issuse about unsigned long long on SPARC:
> 
>   http://bugs.python.org/issue8314

To elaborate, Python's tests for handling of unsigned long long on SPARC (using
both Linux and Solaris) were failing;  Martin von LÃwis tracked the problem down
to an apparent bug in libffi:  it looks as though the code that should handle
unsigned long long in src/sparc/v8.S is missing.  At around line 68 of that file
there's the following code:

 cmp %i3, FFI_TYPE_INT
be,a done
st %o0, [%i4] ! (delay)

cmp %i3, FFI_TYPE_FLOAT
be,a done
st %f0, [%i4+0] ! (delay)

cmp %i3, FFI_TYPE_DOUBLE
be,a double
st %f0, [%i4+0] ! (delay)

cmp %i3, FFI_TYPE_SINT8
be,a sint8
sll %o0, 24, %o0 ! (delay)

cmp %i3, FFI_TYPE_UINT8
be,a uint8
sll %o0, 24, %o0 ! (delay)

cmp %i3, FFI_TYPE_SINT16
be,a sint16
sll %o0, 16, %o0 ! (delay)

cmp %i3, FFI_TYPE_UINT16
be,a uint16
sll %o0, 16, %o0 ! (delay)

cmp %i3, FFI_TYPE_SINT64
be,a longlong
st %o0, [%i4+0] ! (delay)
done:
ret
restore


Should there be an entry for FFI_TYPE_UINT64 somewhere here?  My knowledge of
Sparc ABI and Sparc assembly is non-existent, so I've no idea what should go
here, but the patch that Martin came up can be seen here:

http://bugs.python.org/file16798/sparc.diff

This seems to fix the problem for us, but it would be great to have the libffi
folks confirm that this is a sensible fix, or to point out better fixes if they
exist.

Thanks,

Mark Dickinson