[issue8314] test_ctypes fails in test_ulonglong on sparc buildbots

[Mark Dickinson]

Mark Dickinson <dickinsm at 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 <report at bugs.python.org>
<http://bugs.python.org/issue8314>
_______________________________________