From patchwork Thu Jun 29 15:11:58 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "H.J. Lu" X-Patchwork-Id: 21331 Received: (qmail 2536 invoked by alias); 29 Jun 2017 15:12:08 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 2513 invoked by uid 89); 29 Jun 2017 15:12:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.9 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM, SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-oi0-f46.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cfnZMGdVx40qbv0ntZauscTwe1ZVZd+T+8ToZKLWkZ4=; b=Vveea8pxe/Qa08sbW+EIjfm3BTBph/wTi46sdkkhhyiyGQIZ7MBdubt8jEUT/MlvQ3 7dqM//tYgrQNUZdLJHbaynCeNIiTiatjdHhWrwJMkPUmfxP904wC1Upay8Z+ydWMr7hq 18lSVxuz3CavM63oF3CsUeqxd3LcWOJ85W5EFRdfFOXPIHMOI3TvE0HSSH/F6V8QYIck E814fmEMu60tqzyUvLz9dsK9XnWkRxvePAWT7GFTIglKIXtj2BLO04Evu/A6X5DiK+c/ g4di4pvzU+Yu7ljyZZSCSQA1LbTUkejIa6mRbUW5i9ASI05aZxfALZ3HfGae+qj3ttHk soJg== X-Gm-Message-State: AKS2vOyfLPygpnjYkbKjOyA8VLtzKCi20NPvggM6dlzE62aY29UOpxwk 08D+miFGTxvUNt/tG1SiWhKHsA5K8vY6 X-Received: by 10.202.237.133 with SMTP id l127mr8855531oih.128.1498749119405; Thu, 29 Jun 2017 08:11:59 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <768f285a-2ab9-a5be-0ea5-4358d9ea3fba@redhat.com> References: <66d478fd-2d8f-bd06-d6b1-016a37166829@gotplt.org> <768f285a-2ab9-a5be-0ea5-4358d9ea3fba@redhat.com> From: "H.J. Lu" Date: Thu, 29 Jun 2017 08:11:58 -0700 Message-ID: Subject: Re: 2.26 freeze in a little over a week To: Florian Weimer Cc: Joseph Myers , Siddhesh Poyarekar , "libc-alpha@sourceware.org" , "Carlos O'Donell" On Thu, Jun 29, 2017 at 8:08 AM, Florian Weimer 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 wrote: >>>> Hi, >>>> >>>> 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: >>> >>> https://sourceware.org/bugzilla/show_bug.cgi?id=21120 >> >> 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 >> symbols? > > No, we don't have to change the implementation. We just need to > resurrect 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 --- a/sysdeps/i386/Makefile +++ b/sysdeps/i386/Makefile @@ -101,3 +101,7 @@ $(objpfx)tst-ld-sse-use.out: ../sysdeps/i386/tst-ld-sse-use.sh $(objpfx)ld.so else CFLAGS-.os += $(if $(filter rtld-%.os,$(@F)), $(rtld-CFLAGS)) endif + +ifeq ($(subdir),malloc) +CFLAGS-malloc.c += -DMALLOC_ALIGNMENT=16