| msg102371 - (view) |
Author: R. David Murray (r.david.murray) *  |
Date: 2010-04-05 12:18 |
| ====================================================================== FAIL: test_ulonglong (ctypes.test.test_callbacks.Callbacks) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home2/buildbot/slave/trunk.loewis-sun/build/Lib/ctypes/test/test_callbacks.py", line 68, in test_ulonglong self.check_type(c_ulonglong, 42) File "/home2/buildbot/slave/trunk.loewis-sun/build/Lib/ctypes/test/test_callbacks.py", line 31, in check_type self.assertEqual(result, arg) AssertionError: 0L != 42 |
|
|
| msg102372 - (view) |
Author: R. David Murray (r.david.murray) * |
Date: 2010-04-05 12:18 |
| The ubuntu and debian sparc buildbots show the same failure, none of the other buildbots do. |
|
|
| msg102373 - (view) |
Author: Florent Xicluna (flox) * |
Date: 2010-04-05 12:20 |
| This bug is already reported here: http://bugs.python.org/issue8142#msg101134 |
|
|
| msg102528 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2010-04-07 09:43 |
| It's surprising that test_ulonglong fails, while test_longlong passes: can the Linux Sparc ABI really be treating these two types differently? Maybe more information could be gained by supplying a more interesting test value than 42---some 8-byte value with all bytes different, for example. In any case, this seems likely to be a libffi bug somewhere; maybe we could bring it up on the libffi mailing list. If we can translate the failing Python code into failing C code first that would probably increase the chances of getting a good answer. Without access to Sparc hardware, I don't see much other way of making progress here. |
|
|
| msg102531 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2010-04-07 11:00 |
| I have just studied the issue in detail; v8.S is indeed missing support for unsigned long long. Here is a patch. |
|
|
| msg102532 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2010-04-07 11:03 |
| Committed as r79892. |
|
|
| msg102625 - (view) |
Author: Thomas Heller (theller) * |
Date: 2010-04-08 16:26 |
| Martin, you should probably post your patch to upstream libffi. |
|
|
| msg102984 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2010-04-12 22:21 |
| It should be ported to py3k, the sparc buildbots still fail there. |
|
|
| msg103315 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2010-04-16 12:12 |
| > Committed as r79892. Commited to py3k (r80106), but blocked in 3.1 (r80107) because Python 3.1 uses libffi 3.0.5. |
|
|
| msg103884 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2010-04-21 18:43 |
| 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. |
|
|
| msg133125 - (view) |
Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) *  |
Date: 2011-04-06 13:12 |
| There seems to be also a problem with src/sparc/v9.S. https://bugs.gentoo.org/show_bug.cgi?id=362065 FAIL: test_ulonglong (ctypes.test.test_callbacks.Callbacks) ---------------------------------------------------------------------- Traceback (most recent call last): File "/var/tmp/portage/dev-lang/python-2.7.2_pre20110403/work/python-2.7.2_pre20110403/Lib/ctypes/test/test_callbacks.py", line 72, in test_ulonglong self.check_type(c_ulonglong, 10955412242170339782) File "/var/tmp/portage/dev-lang/python-2.7.2_pre20110403/work/python-2.7.2_pre20110403/Lib/ctypes/test/test_callbacks.py", line 31, in check_type self.assertEqual(result, arg) AssertionError: 10955412241121898851L != 10955412242170339782L |
|
|
| msg221723 - (view) |
Author: Mark Lawrence (BreamoreBoy) * |
Date: 2014-06-27 20:41 |
| Can this be closed as "out of date"? |
|
|
| msg331683 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) * |
Date: 2018-12-12 09:07 |
| Starting from 3.7 Python always uses system libffi. 3.4 and 3.5 are in security bugfix only mode. So this issue is only for 2.7 and 3.6. |
|
|