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].
