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.
