Make max_align_t respect _Float128 [version 2]
Florian Weimer
fweimer@redhat.com
Tue Sep 6 15:06:00 GMT 2016
On 09/06/2016 01:25 PM, Joseph Myers wrote:
> On Tue, 6 Sep 2016, Florian Weimer wrote:
>
>> Why aren't there any users? The standard isn't very clear what the value of
>> _Alignof (max_align_t) actually means. Does the phrase “all contexts” include
>> pointers returned malloc? Even if the requested size is smaller than the
>> fundamental alignment? Did those who wrote the standard expect there to be
>> *any* relationship between malloc and max_align_t?
>
> See my cleanup of the wording in DR#445
> <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2059.htm#dr_445>, which
> is intended to reflect the intent and stay compatible with C99. malloc
> should be usable to allocate memory for any type from the standard library
> headers, including max_align_t.
And the old text for malloc says:
“
The pointer returned if the allocation succeeds is suitably aligned so
that it may be assigned to a pointer to any type of object with a
fundamental alignment requirement and then used to access such an object
or an array of such objects in the space allocated (until the space is
explicitly deallocated).
”
So that's what ties the two things together. I still don't like what's
implied in PR66661, that all object sizes have to be multiples of the
fundamental alignment.
>> The existing situation is that most mallocs to do not provide _Alignof
>> (max_align_t) alignment unconditionally. But they can provide arbitrarily
>> large alignment with aligned_alloc/memalign-style interfaces.
>
> Well, that's a conformance bug in the implementation as a whole. The
> nonconforming modes in question are still useful and it's useful for GCC
> to support such mallocs.
PR66661 shows that GCC does not want to support such mallocs (or even
glibc's malloc).
Florian
More information about the Gcc-patches
mailing list