https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot
Uni-Bielefeld.DE> ---
> --- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> ---
> (In reply to Jonathan Wakely from comment #9)
>> So GCC's definition of max_align_t is not consistent with malloc in Solaris
>
> Oh, I'm assuming here that the definition of max_align_t is coming from GCC's
> <stddef.h>.
Thanks for that reminder: I'd completely forgotten about
gcc/ginclude/stddef.h and only looked at the system header. That header
includes
/* _Float128 is defined as a basic type, so max_align_t must be
sufficiently aligned for it. This code must work in C++, so we
use __float128 here; that is only available on some
architectures, but only on i386 is extra alignment needed for
__float128. */
#ifdef __i386__
__float128 __max_align_f128
__attribute__((__aligned__(__alignof(__float128))));
#endif
(which <stddef.h> of course doesn't have), introduced in
https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00652.html
> Wherever that max_align_t definitions comes from, it should match what malloc
> does.
I don't think that's necessarily true:
* According to the i386 psABI, p.8, Table 2.1, support for __float128 is
optional.
* Studio 12.6 cc doesn't support it:
https://docs.oracle.com/cd/E77782_01/html/E77792/gqexw.html#OSGCCgqexp
* Thus neither does the system malloc. Even if this could be changed
for (say) Solaris 11.5 (I'll check about this once discussion of this
bug is finished), that leaves us with older Solaris versions.
As an experiment, I've disabled the __float128/i386 part of the
max_align_t definition in gcc/ginclude/stdlib.h. Not unexpectedly, the
current test PASSes now:
-FAIL: experimental/memory_resource/resource_adaptor.cc execution test
while another FAILs:
+FAIL: gcc.dg/float128-align.c (test for excess errors)
Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/floatn-align.h:17:1: error:
static assertion failed: "max_align_t must be at least as aligned as _Float*
types"
I'm uncertain how to deal with this: of course we could xfail the
current test and be done with it, but perhaps there are other options?
Joseph, any suggestions? You mentioned that older versions of glibc
didn't provide 16-byte alignment in i386 malloc; maybe there are other
systems with the same issue that could equally benefit from some fix?
Rainer
