[issue47179] pymalloc should align to max_align_t

2022-04-07 Thread Ronald Oussoren
Ronald Oussoren added the comment: > If we want to respect sizeof(max_align_t) alignment, we can compute > sizeof(max_align_t) in configure and uses the result in obmalloc.c. I expect > that it's either 16 or 32, so we can maybe just hardcode ALIGNMENT_SHIFT > using something like: "if ==

[issue47179] pymalloc should align to max_align_t

2022-03-31 Thread STINNER Victor
STINNER Victor added the comment: Oh, it seems like this issue is a duplicate of bpo-31912 created in 2017. -- ___ Python tracker ___

[issue47179] pymalloc should align to max_align_t

2022-03-31 Thread STINNER Victor
STINNER Victor added the comment: Objects/obmalloc.c currently relies on the SIZEOF_VOID_P macro: --- #if SIZEOF_VOID_P > 4 #define ALIGNMENT 16 /* must be 2^N */ #define ALIGNMENT_SHIFT 4 #else #define ALIGNMENT 8 /* must be 2^N

[issue47179] pymalloc should align to max_align_t

2022-03-31 Thread STINNER Victor
STINNER Victor added the comment: On my x86-64 Fedora 35, gcc says 32 bytes for sizeof(max_align_t). By the way, g++ also says 32 bytes for sizeof(std::max_align_t). GCC 11.2.1 defines max_align_t as: --- #if (defined (__STDC_VERSION__) && __STDC_VERSION__ >= 201112L) \ ||

[issue47179] pymalloc should align to max_align_t

2022-03-31 Thread Petr Viktorin
New submission from Petr Viktorin : malloc() returns memory that's "suitably aligned for any built-in type". All of Python's allocation functions should do the same. In bpo-27987 (PR-12850, PR-13336), the alignment was raised* to 16 bytes and `long double`. This is OK for current