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: 782328 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3wz36k5nNFz9ryv for ; Fri, 30 Jun 2017 01:12:14 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.b="hqhbCNMe"; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; q=dns; s=default; b=bJaK roxfi3+7J7nhpSMd+xBGZ7KSo1zVGCC+bOyXnvIe9JRqDkf4S7NnVUxBvhHo/KIz 4NXRT3xplz3RXnBo9L6juSg4o3u+UJ9Tfv2RMvN1aDwIp5JTVX1v6eUpeRA5xDzH FCG8lK8Rc0U+7Z0SkpwhfQ24UmBFCWGnSEdwApU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; s=default; bh=KC2UJUdCXS FZmzKKr/caIE7zIpw=; b=hqhbCNMeckqa8ETbEbG+ayDhO2xdrX/iPByfvUQOUC wcwKbqSJLd2c8iOLHTXyo89nY88SdXMUEyIzYrTpPTnxUW2nT5czBCC54giUfN7W CUhYKjX9hOWNjGXPOmz2/8PdTM84ENOlxOuQrqxCfp94WEqPX7wkyhm2XjnjAxzC U= 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