On x86-64, clang -O3 compiles the following function:PyCArgObject *PyCArgObject_new(void){    PyCArgObject *p;    p = PyObject_New(PyCArgObject, &PyCArg_Type);    if (p == NULL)        return NULL;    p->pffi_type = NULL;    p->tag = '\0';    p->obj = NULL;    memset(&p->value, 0, sizeof(p->value));    return p;}like that:   0x00007fffe9c6acb0 <+0>:push   rax   0x00007fffe9c6acb1 <+1>:mov    rdi,QWORD PTR [rip+0xe308]        # 0x7fffe9c78fc0   0x00007fffe9c6acb8 <+8>:call   0x7fffe9c5e8a0 <_PyObject_New@plt>   0x00007fffe9c6acbd <+13>:test   rax,rax   0x00007fffe9c6acc0 <+16>:je     0x7fffe9c6acdf <PyCArgObject_new+47>   0x00007fffe9c6acc2 <+18>:mov    QWORD PTR [rax+0x20],0x0   0x00007fffe9c6acca <+26>:mov    BYTE PTR [rax+0x28],0x0   0x00007fffe9c6acce <+30>:xorps  xmm0,xmm0   0x00007fffe9c6acd1 <+33>:movaps XMMWORD PTR [rax+0x30],xmm0   0x00007fffe9c6acd5 <+37>:mov    QWORD PTR [rax+0x40],0x0   0x00007fffe9c6acdd <+45>:pop    rcx   0x00007fffe9c6acde <+46>:ret       0x00007fffe9c6acdf <+47>:xor    eax,eax   0x00007fffe9c6ace1 <+49>:pop    rcx   0x00007fffe9c6ace2 <+50>:ret    The problem is that movaps requires the memory address to be aligned on 16 bytes, whereas PyObject_New() uses pymalloc allocator (the requested size is 80 bytes, pymalloc supports allocations up to 512 bytes) and pymalloc only provides alignment on 8 bytes.If PyObject_New() returns an address not aligned on 16 bytes, PyCArgObject_new() crash immediately with a segmentation fault (SIGSEGV).CPython must be compiled using -fmax-type-align=8 to avoid such alignment crash. Using this compiler flag, clag emits expected machine code:   0x00007fffe9caacb0 <+0>:push   rax   0x00007fffe9caacb1 <+1>:mov    rdi,QWORD PTR [rip+0xe308]        # 0x7fffe9cb8fc0   0x00007fffe9caacb8 <+8>:call   0x7fffe9c9e8a0 <_PyObject_New@plt>   0x00007fffe9caacbd <+13>:test   rax,rax   0x00007fffe9caacc0 <+16>:je     0x7fffe9caacdf <PyCArgObject_new+47>   0x00007fffe9caacc2 <+18>:mov    QWORD PTR [rax+0x20],0x0   0x00007fffe9caacca <+26>:mov    BYTE PTR [rax+0x28],0x0   0x00007fffe9caacce <+30>:xorps  xmm0,xmm0   0x00007fffe9caacd1 <+33>:movups XMMWORD PTR [rax+0x30],xmm0   0x00007fffe9caacd5 <+37>:mov    QWORD PTR [rax+0x40],0x0   0x00007fffe9caacdd <+45>:pop    rcx   0x00007fffe9caacde <+46>:ret       0x00007fffe9caacdf <+47>:xor    eax,eax   0x00007fffe9caace1 <+49>:pop    rcx   0x00007fffe9caace2 <+50>:ret    "movaps" instruction becomes "movups" instruction: "a" stands for "aligned" in movaps, whereas "u" stands for "unaligned" in movups.

New changeset23a683adf803eef405d248cc9c2a7eb08a7300e2 by Victor Stinner in branch 'master':bpo-36618: Add -fmax-type-align=8 flag for clang (GH-12809)https://github.com/python/cpython/commit/23a683adf803eef405d248cc9c2a7eb08a7300e2

I merged a "workaround" in the master branch. Python 2.7 and 3.7 are also affected, but I prefer to wait to see if the change goes through buildbots.The real fix would be to modify pymalloc to use 16-byte alignement, but that's a more complex issue :-)

Note to myself: "Sadly, the flag must be expected to CFLAGS and not just CFLAGS_NODIST, ..."It should be "Sadly, the flag must be *set* to CFLAGS and not just CFLAGS_NODIST, ..." :-( I should fix the NEWS entry.

Oh, it seems like the change broke the FreeBSD 10 buildbot :-(https://buildbot.python.org/all/#/builders/167/builds/769...checking for makedev... nochecking for le64toh... nochecking for mode_t... nochecking for off_t... nochecking for pid_t... nochecking for size_t... nochecking for uid_t in sys/types.h... yeschecking for ssize_t... nochecking for __uint128_t... nochecking size of int... 0checking size of long... 0checking size of long long... 0checking size of void *... 0checking size of short... 0checking size of float... 0checking size of double... 0checking size of fpos_t... 0checking size of size_t... 0checking size of pid_t... 0checking size of uintptr_t... 0checking for long double... yesconfigure: error: in `/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build':configure: error: cannot compute sizeof (long double)See `config.log' for more details--On the previous build, the output looked fine:https://buildbot.python.org/all/#/builders/167/builds/768...checking size of int... 4checking size of long... 8checking size of long long... 8checking size of void *... 8checking size of short... 2checking size of float... 4checking size of double... 8checking size of fpos_t... 8checking size of size_t... 8checking size of pid_t... 4checking size of uintptr_t... 8checking for long double... yeschecking size of long double... 16pythoninfo:CC.version: FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512os.uname: posix.uname_result(sysname='FreeBSD', nodename='10-STABLE-amd64.elysium', release='10.4-STABLE', version='FreeBSD 10.4-STABLE #1r337021: Wed Aug  1 15:12:48 AEST 2018root@10-STABLE-amd64.elysium:/usr/obj/usr/src/sys/GENERIC', machine='amd64')platform.platform: FreeBSD-10.4-STABLE-amd64-64bit-ELF

See also:*bpo-27987: obmalloc's 8-byte alignment causes undefined behavior*bpo-18835: Add PyMem_AlignedAlloc()*bpo-31912: PyMem_Malloc() should guarantee alignof(max_align_t)

Even if you check for -fmax-type-align compiler support at configure time, there is a potential problem:Nothing guarantees that extension modules are built by the same compiler that CPython is.  If CPython used an old clang without support for that flag and the extension module compiled by that CPython via pip and setup.py, etc. uses a more recent version of clang - it wouldn't specify that flag and the extension module code could be broken.I suppose this issue of conditional compiler flags is nothing new.  It should not block us from going forward with a workaround like your PRs for now.

I believe -fno-max-type-align is also an option.

New changeseta304b136adda3575898d8b5debedcd48d5072272 by Victor Stinner in branch 'master':bpo-36618: Don't add -fmax-type-align flag to old clang (GH-12811)https://github.com/python/cpython/commit/a304b136adda3575898d8b5debedcd48d5072272

> It should not block us from going forward with a workaround like your PRs for now.I pushed a fix quickly to unblock myPR 12796, but also because I was very scared by what I saw :-DI see my change as a "quick fix", but we really have to sit down to think about the "correct fix". Especially since we will have to do something for Python 2.7 and 3.7, and adding -fmax-type-align=8 to exported CFLAGS can cause *new* issues, as you explained.That's why I mentionedbpo-27987 and other issues, to try to see what has already been said, and try to find to identify and fix the root issue, rather than working around the issue with compiler flags.

The issue is related to the definition of PyCArgObject:typedef struct tagPyCArgObject PyCArgObject;struct tagPyCArgObject {    PyObject_HEAD    ffi_type *pffi_type;    char tag;    union {        char c;        char b;        short h;        int i;        long l;        long long q;        long double D;        double d;        float f;        void *p;    } value;    PyObject *obj;    Py_ssize_t size; /* for the 'V' tag */};This object must be allocated with suitable alignment (which is 16 on many platforms), and the default Python allocator apparently provides 8-byte alignment only on 64-bit platforms.  In short, using PyObject_New with PyCArgObject results in undefined behavior.This issue potentially affects all compilers, not just Clang.

C++ has a __alignof__ function/macro/operator (not sure what is its kind) to get the alignment of a type.C11 has <stdalign.h> header which provides an alignof() function.GCC has __alignof__().I also found "_Alignof()" name.... no sure which one is the most portable ...

I also found this macro:#define ALIGNOF(type) offsetof (struct { char c; type member; }, member)

More info on alignof():http://www.wambold.com/Martin/writings/alignof.html

@vstinner: once you have a portable version of alignof, you can deciding to *not* use the pool allocator if the required alignment is greater than 8B, or you could modify the pool allocator to take alignment information as an extra parameter?

New changesetd97adfb409290a1e4ad549e4af58cacea86d3358 by Victor Stinner in branch 'master':bpo-36618: Don't add -fmax-type-align=8 flag for clang (GH-13320)https://github.com/python/cpython/commit/d97adfb409290a1e4ad549e4af58cacea86d3358

Python 3.8 now respects the x86-64 ABI:https://bugs.python.org/issue27987I reverted my workaround.