[Bug target/102772] [12 regression] g++.dg/torture/pr80334.C FAILs

["redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772

--- Comment #34 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Assuming that posix_memalign is slower than malloc (which seems likely), it
would be better to fix this in the compiler by defining
__STDCPP_DEFAULT_NEW_ALIGNMENT__=8 for i386 solaris, instead of setting it to
alignof(max_align_t). That matches what malloc actualy guarantees on the
target.

That would mean that new int[4] can still use malloc, because the compiler
knows the alignment here is 4 and it can just use _Znwj. But for new __float128
it would use _ZnwjSt11align_val_t to get 16-byte alignment that isn't
guaranteed by malloc.

Fixing it in _Znwj inside libsupc++ means that we have to use posix_memalign
for all allocations >= 16 bytes, as we can't tell whether operator new(16) was
called for something that actually needs 16-byte alignment, or for something
like  int[4] or short[8].