Message ID | eb41483d0f3c054eb8420d0134d6c1a3c4af8c54.1666877952.git.szabolcs.nagy@arm.com |
---|---|
State | Dropped |
Headers |
Return-Path: <libc-alpha-bounces+patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 904CD38A8150 for <patchwork@sourceware.org>; Thu, 27 Oct 2022 15:34:23 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 904CD38A8150 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1666884863; bh=GGCrRtwfAT44h3cloQacdbbiGlxmKdXnrBtFKEituP4=; h=To:Subject:Date:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=x/qU6XDoFCv67pvXRSZ87FtimPbjfYfPqfXyaXJjeNF5CP7lONNGNwwsP8P90NE+p S4ukjTGZafixOuE1c+B7Ja+5F0/ieifJS0FDFoIePAXRIrYX8kbhgkrqsFux/Yrxzi HqO1MC2fh0zQMLUmL3Za0MAFaruXou3WroKWHxZM= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60067.outbound.protection.outlook.com [40.107.6.67]) by sourceware.org (Postfix) with ESMTPS id C13EB386EC25 for <libc-alpha@sourceware.org>; Thu, 27 Oct 2022 15:33:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C13EB386EC25 ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=TAS5Odi6qI/GxKXS7WXYNHK5pJiDIufTKTtCcf9V0vjJdF6kHT69jpysrdGuv7WadKe7nRIH2B5+L30itxZ2Wou1Q6MR7K56Kgn84QYK1UfC8IYnvbd1h4qW3x5SAdvs4hQCzlcpZPG9BOJY/X0IJxBzxkBj2ZYhar0OKnMhb/+NhZp69xiqFYaHwbLPQSMYHnHk6Kj+cAWBIa7qpaBubyUC3TzLTt0zksFSTJaVfjjFyqKibvWVZzTINJl1I/S6yIZazeQjVsgA+Gwhuvj/iUxiOI4LjufD1sOgdoBEFQNo8/K6GBv6wdTT6ZbHgnQMIu7TLkx7SLFv/sFjj+GWtQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GGCrRtwfAT44h3cloQacdbbiGlxmKdXnrBtFKEituP4=; b=JdkHA+xKGeJiygO2aBeTjNZJjHJkRja5vPEbVzqnCSdiaqZZ8/J2wqYpgx4jIv0eYlf2HMEIZtecC4nEu7BCNWDj0c88+uGP+0aobY7f85zsatDZe6Yy3VYx3wST/527CyYvc3iIoreI9l4vAOSbOd+zwptwwvITr7LnQdwLgSpA/dti19qi8qoZj1ty+kFN1YlFEgYhPXH/4Z0286pEGsWtDZfKif5OGTseJs+eZJfgRsndPqjaxX8nf3T2J01BptGIrXaMCY8twyazypaIvhoe+s6qUmqpdXDB4Kc+FOP8PDFBRdijTQz593rYGfWeghuyx7lIZJgBLB4520gvvQ== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=sourceware.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0 oda=1 ltdi=1 spf=[1, 1, smtp.mailfrom=arm.com] dmarc=[1, 1, header.from=arm.com]) Received: from AS9PR04CA0098.eurprd04.prod.outlook.com (2603:10a6:20b:50e::29) by VI1PR08MB5376.eurprd08.prod.outlook.com (2603:10a6:803:13e::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5746.28; Thu, 27 Oct 2022 15:33:11 +0000 Received: from AM7EUR03FT023.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:50e:cafe::77) by AS9PR04CA0098.outlook.office365.com (2603:10a6:20b:50e::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5746.21 via Frontend Transport; Thu, 27 Oct 2022 15:33:11 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; pr=C Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM7EUR03FT023.mail.protection.outlook.com (100.127.140.73) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5723.32 via Frontend Transport; Thu, 27 Oct 2022 15:33:11 +0000 Received: ("Tessian outbound b4aebcc5bc64:v130"); Thu, 27 Oct 2022 15:33:11 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 22d4232bf413bb03 X-CR-MTA-TID: 64aa7808 Received: from e3189bfec001.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id D0380B03-069F-41A0-99C6-E6CF31A1C431.1; Thu, 27 Oct 2022 15:33:03 +0000 Received: from EUR04-DB3-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id e3189bfec001.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 27 Oct 2022 15:33:03 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AzbaXuDXRcwmIdjIwGu6dNgrDfS+ePppMZLPInvMViwigHophkoF6WEUD25Z8jGk4zPABc6VSsT0WGKYw4878Qo/z2AnZkArlbvoXfBtLvOWcOhhRGassT/iSOl09gs8Q1xqE/5aIq6mtpvruILZ/FaXt7gOUsIcfUzfjJMJ7m7N7NV15WPfhmgMo1MY7yHmNbFh5VwfS3rdff4guPcWG0TpMLQuGG+8VwPig/JNinN8yLnbjipbTeMmOn6sn0636Ap6oBfweyIT77AzRRHUtqFaP206Yp2Ay7CcSHeQiNqs5yDTn51BHhkH6JdDgn0NGfWTC4T53BYyS9borRHlQw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GGCrRtwfAT44h3cloQacdbbiGlxmKdXnrBtFKEituP4=; b=Rt6SVkz4AHMRknQMncnwU3ERekj7KTYlyyZOQt1FgF9Qe5VrSt4UdrpC07QFbP2bEVXfxtHcEFanUAIGckAJE8RRmg3QqxZ+LLzTKLycMzXRjU6b+35++HoCrbVjRC5vhbUIdIwgM4Y54iKxHaQ1va6KVqZSFarfPQ0CkZCr4/envDtsF8f3f2KoibVriEscc759FnSGlR/JrGv6F2LyWqBIypiK8oaj2QTHc31gIOQrVyZvupkbKnV/xfPsIln9twHV9v+LFmveSHY4aMfBA6oWwb0onQQsvFiglghKUtWb9E4ZyYNFc1Z6EbAvmdQTuS+y9MYoZGvSTfwqP/V/0w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 40.67.248.234) smtp.rcpttodomain=sourceware.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=none (message not signed); arc=none Received: from DB9PR01CA0019.eurprd01.prod.exchangelabs.com (2603:10a6:10:1d8::24) by PA4PR08MB6318.eurprd08.prod.outlook.com (2603:10a6:102:e2::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5746.28; Thu, 27 Oct 2022 15:33:01 +0000 Received: from DBAEUR03FT030.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:1d8:cafe::19) by DB9PR01CA0019.outlook.office365.com (2603:10a6:10:1d8::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5746.28 via Frontend Transport; Thu, 27 Oct 2022 15:33:01 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 40.67.248.234) smtp.mailfrom=arm.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 40.67.248.234 as permitted sender) receiver=protection.outlook.com; client-ip=40.67.248.234; helo=nebula.arm.com; pr=C Received: from nebula.arm.com (40.67.248.234) by DBAEUR03FT030.mail.protection.outlook.com (100.127.142.197) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.5746.19 via Frontend Transport; Thu, 27 Oct 2022 15:33:01 +0000 Received: from AZ-NEU-EX03.Arm.com (10.251.24.31) by AZ-NEU-EX03.Arm.com (10.251.24.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.12; Thu, 27 Oct 2022 15:33:01 +0000 Received: from armchair.cambridge.arm.com (10.2.80.71) by mail.arm.com (10.251.24.31) with Microsoft SMTP Server id 15.1.2507.12 via Frontend Transport; Thu, 27 Oct 2022 15:33:00 +0000 To: <libc-alpha@sourceware.org> Subject: [PATCH 10/20] malloc: Fix alignment logic in obstack Date: Thu, 27 Oct 2022 16:33:00 +0100 Message-ID: <eb41483d0f3c054eb8420d0134d6c1a3c4af8c54.1666877952.git.szabolcs.nagy@arm.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <cover.1666877952.git.szabolcs.nagy@arm.com> References: <cover.1666877952.git.szabolcs.nagy@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EOPAttributedMessage: 1 X-MS-TrafficTypeDiagnostic: DBAEUR03FT030:EE_|PA4PR08MB6318:EE_|AM7EUR03FT023:EE_|VI1PR08MB5376:EE_ X-MS-Office365-Filtering-Correlation-Id: 3f8b3be0-30a6-492d-6cd9-08dab8308e3e x-checkrecipientrouted: true NoDisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: 34Vh47tONXlbySV0+S+AX8Hqu/9AcoaEw+mQG2Sx5q0ddi2eRTYOvUKebj2bRjatD5lJy0dCmLvGJteM7GS5rV2FLZDy/des8DrMQhm/44PWVUvW/MsuQzXzjKSTbkyp92h5v7UDceSupU9d0S0VwmwMw34ew/CXYfRs5mStedvVqZ4VJX8idQW/Ay8uNW15Nehxb8hwCOkOk/lXoh3uD/2MYM6p4eiOSlwLF9eRf3xxSXRcI/2VAs0tbRuKxAu23xjeY4q3bCKB4YXnVtNRQkdlp1THNnoNviPVkEIklpvKT+vKp3jP+ja5SAVFxm/pfGYztc9sr9VzXPxHLr0rJ3oyvvL5xz3/slA4RR7DX5XK0dQyAfZ4nQRKDlB4ZBsnrtcKmE4raL9eykHMUieBz7+tm8hxEddOcKV62FjW0KTq0FLj6WIwTfHa2v48YXnQ+o6ki8LTVI4AbnBYPq6rjfZul7tZHVCPf7OpUg/wOfLVJ+VJ3T4ngpFk4KpdegDlH7mlMTzsmH0mzidWwnwRMcVj8IuMqnY+wYQX4SgmEBl761maSXW/Fi5/A8vq/lR3uDPLBs1VE7FTSqTD4E85rhNYHCjVQWHEPkTxguYr1CoFDfcUtufICLP0RJlNySOGudzyiO2eFgnQxSzL+/AE4W8j9fZFTwFdCQbjKF77pZ/p4rY1QRxOiAu7YAvx27LP0LeFhztAOHMthPxw0V1IsyQlqOVYmWbHF5bVNEzI8wWxzTGzT15m2O+BMLwFb0+LqkcZfAF/DOmJpkvPYmKikVi6/5xIS2veFlimIIxFmcyZXGsLABjDVPeptoCj2UGT X-Forefront-Antispam-Report-Untrusted: CIP:40.67.248.234; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:nebula.arm.com; PTR:InfoDomainNonexistent; CAT:NONE; SFS:(13230022)(4636009)(39860400002)(396003)(346002)(376002)(136003)(451199015)(46966006)(36840700001)(40470700004)(36756003)(82740400003)(356005)(81166007)(5660300002)(44832011)(336012)(70206006)(70586007)(8676002)(8936002)(47076005)(426003)(83380400001)(36860700001)(86362001)(6916009)(2616005)(186003)(316002)(478600001)(40480700001)(7696005)(40460700003)(82310400005)(41300700001)(2906002)(26005)(36900700001); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR08MB6318 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM7EUR03FT023.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: cd637bbe-dcf8-41b8-7448-08dab8308867 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 6wo0nab8uvnBzcou+77K2m6YeJvkfDyXKMIPpdTPITtVQ7PKJ/yTSlJHi4qiDnlu7mH9ZCm/xAFEcQSHiIq4/Q6r+y8gZWPZmhMDD0KQ+5cHfAJOqcKzf2x99n1stjXD63JLcisUX6bqF3PqMF5Fy7M6YWLseaxMhYEpTKFiQq+ip9IrVFL/097n8eMAa+8LKTCOWE+j5uW422IghQgs0J6L0WJ/aNT0BFLqI6PJBX0im1LbkQ+SIq9FcejlM9oo4oEPpsu3/xPpMeHRjY72/OFbw0DnVOSWU4tCSV0OtsfvQNL+3Wk8tmLGfYya/oEp3angkFFFGI65xERRRIoqCUgLnHb6a1m+zyz/TnTO9SJx3e+bzYM0+5UZjuwgOb+vz6bm4VlYOwxXHFicgGlPJcxQsHB2p5WKbooAHQJdsD6h1T0HL5WuRhvGK4DP9bwkA2k1n+CP2NbX1ON1ZY7Tp+UCIYtsNwwmV2BpU0v65t2dnlLcZpugDP98N/xQ5T4k7nLOeptRRkM7hDYY6YZLS+gVE21XjG3vm6Ksyax2N9bvx9tdz9/TLBtxPkrBkWm0n6O/sZJ4ZBgjqw1HGkQFt4QhfPuZCrmVy2r8Ss0mpv712mAAd7GegVsFr/AVy1NUBH8IWeHVl0r4rQFTUfX/LzeHI1d1lc+apz6w6lBbSTUrVyjGDVecFpZMZmcrkMmq/dfYCHxOHsLxbPgSLN5fLRUpZknaQA0hdtPYVps9z1jimONjgYO4yN6rLXKPepFNGG/PkmnZS/hIi6UQgY4HKw== X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(13230022)(4636009)(136003)(396003)(39860400002)(376002)(346002)(451199015)(36840700001)(46966006)(40470700004)(336012)(83380400001)(36860700001)(86362001)(316002)(6916009)(2616005)(40480700001)(186003)(5660300002)(26005)(8936002)(40460700003)(70206006)(41300700001)(2906002)(8676002)(70586007)(44832011)(47076005)(7696005)(36756003)(82310400005)(426003)(82740400003)(81166007)(478600001); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2022 15:33:11.0274 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3f8b3be0-30a6-492d-6cd9-08dab8308e3e X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: AM7EUR03FT023.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB5376 X-Spam-Status: No, score=-11.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, FORGED_SPF_HELO, GIT_PATCH_0, KAM_DMARC_NONE, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_NONE, TXREP, UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list <libc-alpha.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=subscribe> From: Szabolcs Nagy via Libc-alpha <libc-alpha@sourceware.org> Reply-To: Szabolcs Nagy <szabolcs.nagy@arm.com> Errors-To: libc-alpha-bounces+patchwork=sourceware.org@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces+patchwork=sourceware.org@sourceware.org> |
Series |
patches from the morello port
|
|
Checks
Context | Check | Description |
---|---|---|
dj/TryBot-apply_patch | success | Patch applied to master at the time it was sent |
Commit Message
Szabolcs Nagy
Oct. 27, 2022, 3:33 p.m. UTC
If sizeof(ptrdiff_t) < sizeof(void*) the alignment logic was wrong: incorrectly assumed that base was already sufficiently aligned. Use more robust alignment logic: this one should work on any target. Note: this is an installed header so it must be namespace clean and portable hence it uses unsigned long for the alignment offset. --- malloc/obstack.h | 19 +++---------------- 1 file changed, 3 insertions(+), 16 deletions(-)
Comments
On 27/10/22 12:33, Szabolcs Nagy via Libc-alpha wrote: > If sizeof(ptrdiff_t) < sizeof(void*) the alignment logic was wrong: > incorrectly assumed that base was already sufficiently aligned. > > Use more robust alignment logic: this one should work on any target. > Note: this is an installed header so it must be namespace clean and > portable hence it uses unsigned long for the alignment offset. > --- > malloc/obstack.h | 19 +++---------------- > 1 file changed, 3 insertions(+), 16 deletions(-) > > diff --git a/malloc/obstack.h b/malloc/obstack.h > index 4b01cdfe4d..1cf18e5464 100644 > --- a/malloc/obstack.h > +++ b/malloc/obstack.h > @@ -116,22 +116,9 @@ > # define PTR_INT_TYPE ptrdiff_t > #endif > > -/* If B is the base of an object addressed by P, return the result of > - aligning P to the next multiple of A + 1. B and P must be of type > - char *. A + 1 must be a power of 2. */ > - > -#define __BPTR_ALIGN(B, P, A) ((B) + (((P) - (B) + (A)) & ~(A))) > - > -/* Similar to _BPTR_ALIGN (B, P, A), except optimize the common case > - where pointers can be converted to integers, aligned as integers, > - and converted back again. If PTR_INT_TYPE is narrower than a > - pointer (e.g., the AS/400), play it safe and compute the alignment > - relative to B. Otherwise, use the faster strategy of computing the > - alignment relative to 0. */ > - > -#define __PTR_ALIGN(B, P, A) \ > - __BPTR_ALIGN (sizeof (PTR_INT_TYPE) < sizeof (void *) ? (B) : (char *) 0, \ > - P, A) > +/* Align P to the next multiple of A + 1, where A + 1 is a power of 2, > + A fits into unsigned long and P has type char *. */ > +#define __PTR_ALIGN(B, P, A) ((P) + (-(unsigned long)(P) & (A))) Shouldn't you use uintptr_t here to be consistent with your other changes that exactly change using long to cast from pointers? It would be good to check with gnulib as well, since this header is also shared with it. > > #include <string.h> >
The 10/31/2022 13:14, Adhemerval Zanella Netto wrote: > On 27/10/22 12:33, Szabolcs Nagy via Libc-alpha wrote: > > If sizeof(ptrdiff_t) < sizeof(void*) the alignment logic was wrong: > > incorrectly assumed that base was already sufficiently aligned. > > > > Use more robust alignment logic: this one should work on any target. > > Note: this is an installed header so it must be namespace clean and > > portable hence it uses unsigned long for the alignment offset. > > --- > > malloc/obstack.h | 19 +++---------------- > > 1 file changed, 3 insertions(+), 16 deletions(-) > > > > diff --git a/malloc/obstack.h b/malloc/obstack.h > > index 4b01cdfe4d..1cf18e5464 100644 > > --- a/malloc/obstack.h > > +++ b/malloc/obstack.h > > @@ -116,22 +116,9 @@ > > # define PTR_INT_TYPE ptrdiff_t > > #endif > > > > -/* If B is the base of an object addressed by P, return the result of > > - aligning P to the next multiple of A + 1. B and P must be of type > > - char *. A + 1 must be a power of 2. */ > > - > > -#define __BPTR_ALIGN(B, P, A) ((B) + (((P) - (B) + (A)) & ~(A))) > > - > > -/* Similar to _BPTR_ALIGN (B, P, A), except optimize the common case > > - where pointers can be converted to integers, aligned as integers, > > - and converted back again. If PTR_INT_TYPE is narrower than a > > - pointer (e.g., the AS/400), play it safe and compute the alignment > > - relative to B. Otherwise, use the faster strategy of computing the > > - alignment relative to 0. */ > > - > > -#define __PTR_ALIGN(B, P, A) \ > > - __BPTR_ALIGN (sizeof (PTR_INT_TYPE) < sizeof (void *) ? (B) : (char *) 0, \ > > - P, A) > > +/* Align P to the next multiple of A + 1, where A + 1 is a power of 2, > > + A fits into unsigned long and P has type char *. */ > > +#define __PTR_ALIGN(B, P, A) ((P) + (-(unsigned long)(P) & (A))) > > Shouldn't you use uintptr_t here to be consistent with your other changes > that exactly change using long to cast from pointers? here the offset part is unsigned long, but the pointer is kept char *. in other patches the problem was that the pointer was turned into long. here unsigned int would be enough, since obstack->alignment_mask is int, larger alignments are not supported. the new formula may not be the fastest to compute, but if the goal is portability then i think it's better than the current code. > > It would be good to check with gnulib as well, since this header is also > shared with it. i see. i haven't looked at gnulib. > > > > > #include <string.h> > >
On 01/11/22 06:43, Szabolcs Nagy wrote: > The 10/31/2022 13:14, Adhemerval Zanella Netto wrote: >> On 27/10/22 12:33, Szabolcs Nagy via Libc-alpha wrote: >>> If sizeof(ptrdiff_t) < sizeof(void*) the alignment logic was wrong: >>> incorrectly assumed that base was already sufficiently aligned. >>> >>> Use more robust alignment logic: this one should work on any target. >>> Note: this is an installed header so it must be namespace clean and >>> portable hence it uses unsigned long for the alignment offset. >>> --- >>> malloc/obstack.h | 19 +++---------------- >>> 1 file changed, 3 insertions(+), 16 deletions(-) >>> >>> diff --git a/malloc/obstack.h b/malloc/obstack.h >>> index 4b01cdfe4d..1cf18e5464 100644 >>> --- a/malloc/obstack.h >>> +++ b/malloc/obstack.h >>> @@ -116,22 +116,9 @@ >>> # define PTR_INT_TYPE ptrdiff_t >>> #endif >>> >>> -/* If B is the base of an object addressed by P, return the result of >>> - aligning P to the next multiple of A + 1. B and P must be of type >>> - char *. A + 1 must be a power of 2. */ >>> - >>> -#define __BPTR_ALIGN(B, P, A) ((B) + (((P) - (B) + (A)) & ~(A))) >>> - >>> -/* Similar to _BPTR_ALIGN (B, P, A), except optimize the common case >>> - where pointers can be converted to integers, aligned as integers, >>> - and converted back again. If PTR_INT_TYPE is narrower than a >>> - pointer (e.g., the AS/400), play it safe and compute the alignment >>> - relative to B. Otherwise, use the faster strategy of computing the >>> - alignment relative to 0. */ >>> - >>> -#define __PTR_ALIGN(B, P, A) \ >>> - __BPTR_ALIGN (sizeof (PTR_INT_TYPE) < sizeof (void *) ? (B) : (char *) 0, \ >>> - P, A) >>> +/* Align P to the next multiple of A + 1, where A + 1 is a power of 2, >>> + A fits into unsigned long and P has type char *. */ >>> +#define __PTR_ALIGN(B, P, A) ((P) + (-(unsigned long)(P) & (A))) >> >> Shouldn't you use uintptr_t here to be consistent with your other changes >> that exactly change using long to cast from pointers? > > here the offset part is unsigned long, but the pointer is kept > char *. in other patches the problem was that the pointer > was turned into long. > > here unsigned int would be enough, since obstack->alignment_mask > is int, larger alignments are not supported. > > the new formula may not be the fastest to compute, but if the > goal is portability then i think it's better than the current > code. Alright, although I still why not use uintptr_t here for consistency (as we do for all other pointer conversions). And the code already include stddef.h. > >> >> It would be good to check with gnulib as well, since this header is also >> shared with it. > > i see. i haven't looked at gnulib
diff --git a/malloc/obstack.h b/malloc/obstack.h index 4b01cdfe4d..1cf18e5464 100644 --- a/malloc/obstack.h +++ b/malloc/obstack.h @@ -116,22 +116,9 @@ # define PTR_INT_TYPE ptrdiff_t #endif -/* If B is the base of an object addressed by P, return the result of - aligning P to the next multiple of A + 1. B and P must be of type - char *. A + 1 must be a power of 2. */ - -#define __BPTR_ALIGN(B, P, A) ((B) + (((P) - (B) + (A)) & ~(A))) - -/* Similar to _BPTR_ALIGN (B, P, A), except optimize the common case - where pointers can be converted to integers, aligned as integers, - and converted back again. If PTR_INT_TYPE is narrower than a - pointer (e.g., the AS/400), play it safe and compute the alignment - relative to B. Otherwise, use the faster strategy of computing the - alignment relative to 0. */ - -#define __PTR_ALIGN(B, P, A) \ - __BPTR_ALIGN (sizeof (PTR_INT_TYPE) < sizeof (void *) ? (B) : (char *) 0, \ - P, A) +/* Align P to the next multiple of A + 1, where A + 1 is a power of 2, + A fits into unsigned long and P has type char *. */ +#define __PTR_ALIGN(B, P, A) ((P) + (-(unsigned long)(P) & (A))) #include <string.h>