Re: [PATCH] Implement new hook for max_align_t_align

[Bernd Edlinger <bernd.edlinger@hotmail.de>]

On 10/08/16 19:36, John David Anglin wrote:
> On 2016-10-08, at 1:01 PM, Bernd Edlinger wrote:
>
>> I think your callback should also directly control the
>> alignment of max_align_t in stddef.h:
>>
>>
>>    long long __max_align_ll __attribute__((__aligned__(__alignof__(long
>> long))));
>>    long double __max_align_ld
>> __attribute__((__aligned__(__alignof__(long double))));
>>    /* _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
>> } max_align_t;
>>
>>
>> otherwise these will not match.
>
> Yes, i missed a hunk in the submission.  On hpux, the alignment is determined by the long
> double field.  With glibc, we need 16 byte alignment for max_align_t.
>

This looks still brittle to me.

I mean also the defines __hppa__ and __hpux__ come from
builtin_define calls in the backend, why not define
something with builtin_define_with_int_value,
which can be used as is in max_align_t.

For instance have:

typedef struct {
   char __max_align[0] __attribute__((__aligned__(__MAX_ALIGN_T_ALIGN__)));
} max_align_t;

Provided we do:

builtin_define_with_value ("__MAX_ALIGN_T_ALIGN__",
targetm.max_align_t_align () / BITS_PER_UNIT);

Would'nt that guarantee, that __max_align_t and
max_align_t_align () will always be the same?


Bernd.