https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jason at gcc dot gnu.org,
| |redi at gcc dot gnu.org
--- Comment #31 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Oops, the above commit is an error, there is no placement new and it is about
the alignment returned by operator new.
movdqu (%eax), %xmm7
movaps %xmm7, (%edx)
where %edx is the value returned by _Znwj.
Now, in C++14 the testcase might be invalid if it operator new doesn't
guarantee 16-byte alignment.
But shouldn't C++17 and later call _ZnwjSt11align_val_t instead of _Znwj if the
latter doesn't guarantee 16-byte alignment?
The threshold above which _ZnwjSt11align_val_t is used is computed by
malloc_alignment:
return MAX (max_align_t_align(), MALLOC_ABI_ALIGNMENT);
and max_align_t_align() is
8643 unsigned int max_align = MAX (TYPE_ALIGN
(long_long_integer_type_node),
8644 TYPE_ALIGN (long_double_type_node));
8645 if (float128_type_node != NULL_TREE)
8646 max_align = MAX (max_align, TYPE_ALIGN (float128_type_node));
8647 return max_align;
TYPE_ALIGN of the 3 types are 64-bit, 32-bit and 128-bit for 32-bit Solaris.
So, if 32-bit Solaris doesn't guarantee 128-bit alignment from malloc, I'm
afraid it needs to somehow override this so that max_align_t_align() is only
64-bit.
Or perhaps avoid supporting float128_type_node.
Or in libsupc++ ensure 16-byte alignment from operator new by using
posix_memalign etc.
