Frank Schaefer <kelle...@gmail.com> added the comment:
Well, after perusing the ctypes callproc.c code, I found the hacks referenced
by martin.panter and tried activating them with some SPARC64 #ifdefs:
--- python3.6-3.6.6.orig/Modules/_ctypes/callproc.c
+++ python3.6-3.6.6/Modules/_ctypes/callproc.c
@@ -1041,6 +1041,7 @@ GetComError(HRESULT errcode, GUID *riid,
#endif
#if (defined(__x86_64__) && (defined(__MINGW64__) || defined(__CYGWIN__))) || \
+ (defined(__sparc_v9__) || (defined(__sparc__) && defined(__arch64__))) || \
defined(__aarch64__)
#define CTYPES_PASS_BY_REF_HACK
#define POW2(x) (((x & ~(x - 1)) == x) ? x : 0)
This is based on #ifdef checks in libffi, but somewhat more generalized. The
good news is, this appears to resolve all test_ctypes failures. So I'm
guessing this is necessary on Linux/SPARC64, though I can't tell if it's
necessary for Solaris/SPARC64. I don't even know what built-in compiler
defines get turned on for Solaris, though someone else might.
It might also be advisable to backport this to Python 2.7, but obviously we
should also backport the additional ctypes tests if we do that.
My biggest concern is, do these hacks have a purely performance-centric impact,
or do they potentially degrade functionality as well?
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue34771>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
