This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: x86_64: Should the -mavx* options affected __alignof__ (max_align_t)?


On Thu, Apr 2, 2015 at 4:17 AM, Florian Weimer <fweimer@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 <fweimer@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 <fweimer@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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]