On Thu, Apr 2, 2015 at 4:17 AM, Florian Weimer <fwei...@redhat.com> wrote:
> On 04/02/2015 01:13 PM, H.J. Lu wrote:
>> On Thu, Apr 2, 2015 at 4:08 AM, Florian Weimer <fwei...@redhat.com> wrote:
>>> On 04/02/2015 01:06 PM, H.J. Lu wrote:
>>>> On Thu, Apr 2, 2015 at 1:46 AM, Florian Weimer <fwei...@redhat.com> wrote:
>>>>> On 04/02/2015 10:40 AM, Andrew Haley wrote:
>>>>>
>>>>>> So, max_align_t is an object type, and therefore malloc returns a
>>>>>> pointer suitable for max_align_t.
>>>>>
>>>>> Then the GCC definition of max_align_t is incorrect, it should be 8 on
>>>>> x86_64 GNU/Linux, because traditionally, that's what mallocs implement
>>>>> for this architecture. (dlmalloc in glibc is an exception.)
>>>>>
>>>>
>>>> x86-64 psABI specifies that a memory >= 16 bytes is 16-byte aligned.
>>>> If malloc doesn't do it, it is a broken.
>>>
>>> My concern is different. I think _Alignof (max_align_t) == 16 (as it is
>>> in GCC now) implies that malloc return values for sizes less than 16
>>> bytes are 16-byte-aligned, too, which is not required by the x86-64 psABI.
>>>
>>
>> If you take this way, malloc of 1 byte can return 1-byte aligned memory.
>
> If this is the case, is this code valid?
>
> struct S {
> char a __attribute__ ((aligned (__alignof__ (max_align_t))));
> };
>
> struct S *p = malloc (sizeof (struct S));
>
2 bugs related to MALLOC_ABI_ALIGNMENT:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56726
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36159
--
H.J.
