Created attachment 49210 [details] The failing code The attached code fails when compiled with -m32: ------------------------ $ g++-10.2.0 gcc_alignment_issue_in_m32_mode.cpp -o test -std=c++17 -m32 && ./test test: gcc_alignment_issue_in_m32_mode.cpp:23: int main(): Assertion `UIntPtr(p2.get()) % alignof(Type) == 0' failed. Aborted ------------------------ And if I remove the Type's default constructor, it just crashes: ------------------------ $ g++-10.2.0 gcc_alignment_issue_in_m32_mode.cpp -o test -std=c++17 -m32 -DNO_CTOR && ./test Segmentation fault ------------------------ This happens with any version of GCC that I have in my system starting from 7.x, while 6.x works fine. As I can see, alignof(std::max_align_t) equals 8 in 6.x and 16 in 7.x and later versions, so this seems to be the root of the problem. The system and compiler info: ------------------------ $ cat /etc/issue Linux Mint 17.3 Rosa \n \l $ g++-10.2.0 -v Using built-in specs. COLLECT_GCC=g++-10.2.0 COLLECT_LTO_WRAPPER=/home/brd/soft/gcc-10.2.0/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ./configure --prefix=/home/brd/soft/gcc-10.2.0 Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.2.0 (GCC) ------------------------
malloc is not controlled by gcc.
(In reply to Andrew Pinski from comment #1) > malloc is not controlled by gcc. Yeah, I shouldn't have mentioned malloc because there seems to be no requirement for it to align the returned addresses by alignof(max_align_t). But new-expression should still return properly aligned objects, shouldn't it? So it looks like this issue is C++-specific after all.
operator new just gets its memory from malloc. GCC changed the alignment of max_align_t on x86 targets, but if you don't have a newer malloc then it won't know about that change and so disagrees with GCC's max_align_t definition.
The change to max_align_t was done in r240248 in 2016, glibc's malloc was changed some time after.
I see. So this is not considered a bug then? P.S. it seems that -faligned-new=8 can be used as a workaround in this case, even in pre-c++17 modes, so the issue doesn't look that bad in the end.
This is also an issue on (at least) Solaris, Vxworks 7 and mingw. See https://sourceforge.net/p/mingw-w64/bugs/778/ and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973495 and Bug 77691 for problems caused by GCC's incorrect definition of max_align_t.