This is the mail archive of the
mailing list for the glibc project.
Re: 2.26 freeze in a little over a week
On Thu, Jun 29, 2017 at 8:08 AM, Florian Weimer <email@example.com> wrote:
> On 06/29/2017 04:35 PM, Joseph Myers wrote:
>> On Thu, 29 Jun 2017, H.J. Lu wrote:
>>> On Thu, Jun 22, 2017 at 9:49 AM, Siddhesh Poyarekar <firstname.lastname@example.org> wrote:
>>>> PSA: The development freeze for 2.26 is due in a little over a week. 1
>>>> July is a Saturday, so we have until next week to finish major changes.
>>>> I have a memcpy implementation for the Qualcomm falkor chip that I hope
>>>> to post by tomorrow. Are there any major changes that need attention
>>>> but are not getting it?
>>> Should we change i386 malloc alignment to 16 bytes:
>> In my view, yes.
> I agree.
>> As I understand it, since we fixed bug 6527 such an
>> increase should be easy. Is a malloc state version increase still needed
>> or not since we made malloc_get_state / malloc_set_state into compat
> No, we don't have to change the implementation. We just need to
> resurrect <malloc-machine.h> and use that to override the definition for
> x86 (and later hppa, which has a similar issue with the pthread types).
Or we can do something like this.
diff --git a/sysdeps/i386/Makefile b/sysdeps/i386/Makefile
index e30e133..321da38 100644
@@ -101,3 +101,7 @@ $(objpfx)tst-ld-sse-use.out:
CFLAGS-.os += $(if $(filter rtld-%.os,$(@F)), $(rtld-CFLAGS))
+CFLAGS-malloc.c += -DMALLOC_ALIGNMENT=16