Mark Dickinson <dicki...@gmail.com> added the comment:
I was going to say that I think that this issue can be closed now...
... but the src/sparc/v8.S file still looks wrong to me: Martin fixed one
missing FFI_TYPE_UINT64 case, but it looks to me as though there's another one,
in ffi_call_v8. The code starting at line 68 in that file looks like:
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
Shouldn't there should be another block here for FFI_TYPE_UINT64, essentially
identical to the FFI_TYPE_SINT64 block? Or am I missing something?
I don't know why this omission doesn't cause buildbot failures; perhaps it's
because the compiled test function (e.g., tf_Q in _ctypes_test.c) just happens
to already have placed the correct values in the right locations ([%i4 + 0] and
[%i4 + 4]) already, before transferring them to o0 and o1.
I've asked about this on the libffi-discuss mailing list, as a follow-up to
Victor's report there.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue8314>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
