This one is officially weird.

I can reliably reproduce the segfault in test_ascii_formatd on OSX with ICC 15 or 16, using the included libffi in Modules/_ctypes/libffi_osx.  There are also segfaults in test_ctypes, test_multiprocessing, and test_threading (all stemming from an issue in ctypes).

Using libffi from Homebrew and --with-system-ffi, all the segfaults go away, and in fact all tests pass (with --with-icc from #25827, which adds '-fp-model strict' to CFLAGS).  The bundled 'nearly vanilla' libffi doesn't work with OSX; it doesn't make it through configure.

Somehow, argcount in _ctypes_callproc is being corrupted, but applying this patch somehow makes test_ascii_formatd pass:

diff -r 937774aa1853 Modules/_ctypes/callproc.c
--- a/Modules/_ctypes/callproc.c	Mon Dec 14 03:41:59 2015 +0000
+++ b/Modules/_ctypes/callproc.c	Fri Dec 18 02:10:04 2015 -0600
@@ -1168,6 +1168,7 @@
         PyErr_NoMemory();
         goto cleanup;
     }
+    printf("line 1171, argcount %zd", argcount);
     for (i = 0; i < argcount; ++i) {
         atypes[i] = args[i].ffi_type;
         if (atypes[i]->type == FFI_TYPE_STRUCT)


I have absolutely no idea why that should work.  Adding that line before the previous statement still results in segfault, and adding it anywhere after line 1178 also still results in segfault.  Even with the magic patch, test_ctypes still segfaults elsewhere.  I'm out of my depth as to what could be causing this or how to further diagnose it.

As a workaround, would it be kosher to mandate --with-system-ffi on Darwin when CC=icc?  As I recall, the custom libffi is necessary for regular OSX builds to accommodate fat binaries; how concerned are we about supporting fat binaries with ICC?