This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] i386: Increase MALLOC_ALIGNMENT to 16 [BZ #21120]
- From: Carlos O'Donell <carlos at redhat dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 29 Jun 2017 14:11:41 -0400
- Subject: Re: [PATCH] i386: Increase MALLOC_ALIGNMENT to 16 [BZ #21120]
- Authentication-results: sourceware.org; auth=none
- References: <20170629173030.GA25414@intel.com> <email@example.com> <CAMe9rOpBAZ+FtOfXJBujqyp-q=8TguGZp47A6GQzaEqsieKqKQ@mail.gmail.com>
On 06/29/2017 02:06 PM, H.J. Lu wrote:
> On Thu, Jun 29, 2017 at 10:55 AM, Carlos O'Donell <firstname.lastname@example.org> wrote:
>> On 06/29/2017 01:30 PM, H.J. Lu wrote:
>>> GCC 7 changed the definition of max_align_t on i386:
>>> As a result, glibc malloc no longer returns memory blocks which are as
>>> aligned as max_align_t requires.
>>> This causes malloc/tst-malloc-thread-fail to fail with an error like this
>>> error: allocation function 0, size 144 not aligned to 16
>>> This patch increases the malloc alignment to 16 for i386.
>>> Tested on i386 with GCC 7 and on x86-64. OK for master?
>>> [BZ #21120]
>>> * sysdeps/generic/malloc-alignment.h: New file.
>>> * sysdeps/i386/malloc-alignment.h: Likewise.
>>> * sysdeps/generic/malloc-machine.h: Include <malloc-alignment.h>.
>> Please use malloc-machine.h which was the previous header that provided
>> machine-dependent malloc definitions. That way we remain consistent across
>> releases and make it easier to backport such changes without adding a new
> It won't work too well for Hurd since we have
> What will Hurd/i386 get? malloc-alignment.h handles it automatically.
If your patch made Hurd/i386 use MALLOC_ALIGNMENT of 16 then a new patch
using malloc-machine.h would set MALLOC_ALIGNMENT to 16 in