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