Message ID | 20221122090114.38090-1-christophe.lyon@arm.com |
---|---|
State | Committed |
Commit | 4eb3a48698b2ca43967a4e7e7cfc0408192e85b2 |
Headers |
Return-Path: <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.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 C80E6385841A for <patchwork@sourceware.org>; Tue, 22 Nov 2022 09:02:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C80E6385841A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1669107728; bh=JNklkPOHpsZkQd0S9PZ681d1ETqIELXOzaiOGHpQFbc=; h=To:CC:Subject:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=jd3ZoGumuq9o/kS2Z/PWGAjcG1K0ysF26hfQxrndzg/zh4UrcoYH1soBqBir+p9j5 t/B0oPpoz3+wQZTc66TVWfTaYYrCSgAdzLX0cSJ7M33AvncmIUYgronQZ5FfJs8QDM 8UXZAHrZ0VpaGsZ8qgeYHFyEASVRgiwkr1IV7G70= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140042.outbound.protection.outlook.com [40.107.14.42]) by sourceware.org (Postfix) with ESMTPS id EF7813858C50 for <gcc-patches@gcc.gnu.org>; Tue, 22 Nov 2022 09:01:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EF7813858C50 Received: from DB6PR0202CA0019.eurprd02.prod.outlook.com (2603:10a6:4:29::29) by GV1PR08MB7684.eurprd08.prod.outlook.com (2603:10a6:150:63::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5857.17; Tue, 22 Nov 2022 09:01:31 +0000 Received: from DBAEUR03FT059.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:29:cafe::9a) by DB6PR0202CA0019.outlook.office365.com (2603:10a6:4:29::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5834.11 via Frontend Transport; Tue, 22 Nov 2022 09:01:31 +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 DBAEUR03FT059.mail.protection.outlook.com (100.127.142.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5834.8 via Frontend Transport; Tue, 22 Nov 2022 09:01:31 +0000 Received: ("Tessian outbound 6c699027a257:v130"); Tue, 22 Nov 2022 09:01:31 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 4477de0b563170e8 X-CR-MTA-TID: 64aa7808 Received: from d7348c29fc52.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 3FC45E37-13C1-4A29-9DB0-8D32D85CC053.1; Tue, 22 Nov 2022 09:01:24 +0000 Received: from EUR04-DB3-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id d7348c29fc52.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 22 Nov 2022 09:01:24 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Oa4WrD6M6qYbDQZAVUjKOcO0ej/4URWio0cRU9dtMWSeP6aLejwYlAYCKXgZZiHxy57T0fVAQ7VYS8X6HmCXJgUK+bwJs4s4r26ZxhKwA4oDpWWGU+PTP6sYUcgF+oRWpDMUuDZ11cfcB5lbuLWdmYDJvsZInj+WSXZFq72NJ1SQqnd4jrl5gF2aq4WjY/M4QI+L7jvmkKoKPpdUAFkDGlNpdDAk9FBBnA1P4z8S7/BCjzBtGRxlQ3mocdssB5P0fvtlpHXULo2CHlWpEFCem7+s34T/Ng92FtYZuSL/k5XvnatOIagyc+RpWVFM5uUbzo4RdBeEi76XSYv1NyA7hg== 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=JNklkPOHpsZkQd0S9PZ681d1ETqIELXOzaiOGHpQFbc=; b=hSTCqD9qep65QfiJo4xx2tj2Sf9CZ5uk5KhZTT6CW2xVWiGRYbLhVzSYUX5L2BJcveWisl35O68D6TFTDSmAcuq60U3N5PtFW1ngiTithOBtivxns8n42/w/qmHWvk9Asn9iq7W1UDsQSVqrcmUV1Mqq0tLb1jiHe4EWcRVSRFvYyo5w/NHE5O8k8ZH0uugerx2VN+EtrY0kNAwKnZF2KD8Lg9MiBDFdlK9AKTBErclxQ2HETvPwDEs2uNrEW9iKU1KJz7FDSZki0dqTh851q46UGP+68erKOYwtoJcdh9cftbcfwpIB9aXJPX9oPJBiKB2Nc/qCHGOqwJ88ijYj6A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 40.67.248.234) smtp.rcpttodomain=gcc.gnu.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 FR0P281CA0012.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:15::17) by DU0PR08MB8812.eurprd08.prod.outlook.com (2603:10a6:10:47b::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5857.17; Tue, 22 Nov 2022 09:01:21 +0000 Received: from VI1EUR03FT011.eop-EUR03.prod.protection.outlook.com (2603:10a6:d10:15:cafe::36) by FR0P281CA0012.outlook.office365.com (2603:10a6:d10:15::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5857.17 via Frontend Transport; Tue, 22 Nov 2022 09:01:21 +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 VI1EUR03FT011.mail.protection.outlook.com (100.127.144.181) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.5834.8 via Frontend Transport; Tue, 22 Nov 2022 09:01:20 +0000 Received: from AZ-NEU-EX04.Arm.com (10.251.24.32) by AZ-NEU-EX04.Arm.com (10.251.24.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.16; Tue, 22 Nov 2022 09:01:20 +0000 Received: from e129018.arm.com (10.57.71.96) by mail.arm.com (10.251.24.32) with Microsoft SMTP Server id 15.1.2507.16 via Frontend Transport; Tue, 22 Nov 2022 09:01:19 +0000 To: <gcc-patches@gcc.gnu.org> CC: Christophe Lyon <christophe.lyon@arm.com> Subject: [PATCH] aarch64: Fix test_dfp_17.c for big-endian [PR 107604] Date: Tue, 22 Nov 2022 10:01:14 +0100 Message-ID: <20221122090114.38090-1-christophe.lyon@arm.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EOPAttributedMessage: 1 X-MS-TrafficTypeDiagnostic: VI1EUR03FT011:EE_|DU0PR08MB8812:EE_|DBAEUR03FT059:EE_|GV1PR08MB7684:EE_ X-MS-Office365-Filtering-Correlation-Id: c270b384-994c-498b-78ad-08dacc68262d 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: ym2bB0dMlD+1SnEUIfgwf2Rg9mSBeLEppB82WHK+mJfbTU2jcMWgw+kWFjfonK+cizanZjfREJVJE/ujiFTDvnAn2Eajnv6YT9OR2Mai4NzbONInTsJdN4NxnNr+K5q6v6X1LKn0TOUEzTKht/cT4TkYF75qB1U2FMJt79nX73Xm8rVbrg7dQaoIv1N0rrpgbnRW0AB+382mbcrrzQ9Cumm01sp+Jbcwn4ouoKXvTk6tkisTJzK14O63Laxnd3YsxlUN8Pd630EcLnt/8xIeegYx7rr2BrG1/XtolDzlRmroQjVouCiuVYT0nu9fZza2zPfub4oRv96k7HSX4TSC8F8fxRJNAk7pWg3zf1t5H925v/msWWtbIgy7dh+G4NSwyQfmNmGGTzqLftNdAQ1qOd7HbBrBDNdc2D7vw5AfizuWMThaYnDotYkkxlGuW/pO7F/SBaAoAYu4vE+5Vos39ltiAeivAxJ04iOPAmvATG897jhxpgPKbZd0XkkMiXF2o+QU6PTy0LZNsAPsxcr4e2EHB//VmvM39d9stkRFPSD52Zcg1hDvGrRJb7KqU8sKwhhIpfoUDNxSjCmBDPmxLotkENrnUrvPQsKW5P934uR/OlmcipYQq3TMJXTusSzx+hFdgZFJTKqMDwaPUKry8T3Y+la6WohEBI0fdHZKQvAwcqigoTFYAeR10h0OFsAHHnbk3PyfD6yv4YngDF+aekFAmLWOhE/pKZMlRHD1DvDnYYoOfE7KHQCd4a8zr6nLeiQWNJren6HT4kbzDpKD+x3hjXCBf+WO1QFCmF51l6A= 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)(346002)(39860400002)(376002)(136003)(396003)(451199015)(40470700004)(36840700001)(46966006)(36860700001)(6916009)(81166007)(2906002)(8676002)(82740400003)(86362001)(356005)(4326008)(8936002)(41300700001)(70206006)(40480700001)(40460700003)(82310400005)(44832011)(6666004)(7696005)(5660300002)(26005)(186003)(1076003)(47076005)(316002)(70586007)(426003)(478600001)(336012)(2616005)(84970400001)(36756003)(36900700001); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB8812 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DBAEUR03FT059.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 48262a37-3907-4d6b-c3c2-08dacc681fdd X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: yw9KqGdd4Pq4A819Hzgrofct4/fepG4H23/rV0kyQups9YpTJBSe2tK0x5qnQsxwWOMj1mWFs0+rQdcQNZ6p8PPGihKKQ4K4sVseqELzYrBxBsjtv+m2VEnTHM/7IZENuupAJCEEozPkRAyy/GmnRs8l9tp9IB6KRgYdeHcRFeYJLKqFs7ysjT6L97n7PVj2FsW76h13HP17PstTlK48OE/8YglMHZP4Pod9wDXvTqYx1iepbNCmF5BwtCgAoMSyOQ+Bql1uHo0uthcsMuqUPlducvGHG/UnB2mr2TS5Re7Krf89IGKYj/CRzYrqEsjyUo6vmS40q06YJIH8tgMWt+WWRNcy0ALHoBqapPMeV30fEidNZ5B0RlhLtQpov9/kfTiCqlGR9JA4mdghROiCJ6JD9xuPPjz9jgzRUy7lf7jXQIsRNndWWwU6F5jUvRuyciEjAhv2GOfaBCknoy0WLaXlWlR6dQ2c9kdD8xwiyGOENpZ5sxppn9tfaDTDySYm+oLUruOWbKIoBt3folfT/ZnTqsz8013bvgoprVcKNVe/VIxBP1+rqKyXpcG46s4aG8I8lkiXRQKz7ZaTqQsSVdkOFCBA1YTH2pywqtN4UASRx1nBKKgkzwFOodYAM/PwqLPy6qBMHjhbGBGkkleKzM9I/seH9DkIeCVEsdUsOTi+of9V6RpOKSaGKekInagH2NUjeD5WHsVQad7CQwU6+zr3Hy5iXs7dXxyY7a0KABU9XiJ3qWa0bQ8Vwh1lY9ljMThsgcEP08Pcwh06jeR1dA== 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)(376002)(346002)(396003)(39860400002)(136003)(451199015)(46966006)(36840700001)(40470700004)(6916009)(84970400001)(26005)(6666004)(7696005)(2906002)(316002)(426003)(47076005)(2616005)(336012)(86362001)(186003)(40480700001)(4326008)(36860700001)(36756003)(8676002)(70206006)(81166007)(70586007)(82310400005)(8936002)(82740400003)(1076003)(44832011)(478600001)(5660300002)(41300700001)(40460700003); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Nov 2022 09:01:31.5525 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c270b384-994c-498b-78ad-08dacc68262d 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: DBAEUR03FT059.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR08MB7684 X-Spam-Status: No, score=-12.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, FORGED_SPF_HELO, GIT_PATCH_0, KAM_DMARC_NONE, KAM_SHORT, 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: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: Christophe Lyon via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Christophe Lyon <christophe.lyon@arm.com> Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> |
Series |
aarch64: Fix test_dfp_17.c for big-endian [PR 107604]
|
|
Commit Message
Christophe Lyon
Nov. 22, 2022, 9:01 a.m. UTC
gcc.target/aarch64/aapcs64/test_dfp_17.c has been failing on big-endian, because the _Decimal32 on-stack argument is not padded in the same direction depending on endianness. This patch fixes the testcase so that it expects the argument in the right stack location, similarly to what other tests do in the same directory. gcc/testsuite/ChangeLog: PR target/107604 * gcc.target/aarch64/aapcs64/test_dfp_17.c: Fix for big-endian. --- gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c | 4 ++++ 1 file changed, 4 insertions(+)
Comments
Christophe Lyon via Gcc-patches <gcc-patches@gcc.gnu.org> writes: > gcc.target/aarch64/aapcs64/test_dfp_17.c has been failing on > big-endian, because the _Decimal32 on-stack argument is not padded in > the same direction depending on endianness. > > This patch fixes the testcase so that it expects the argument in the > right stack location, similarly to what other tests do in the same > directory. > > gcc/testsuite/ChangeLog: > > PR target/107604 > * gcc.target/aarch64/aapcs64/test_dfp_17.c: Fix for big-endian. OK, thanks. Richard > --- > gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c b/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c > index 22dc462bf7c..3c45f715cf7 100644 > --- a/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c > +++ b/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c > @@ -32,6 +32,10 @@ struct z b = { 9.0dd, 10.0dd, 11.0dd, 12.0dd }; > ANON(struct z, a, D1) > ANON(struct z, b, STACK) > ANON(int , 5, W0) > +#ifndef __AAPCS64_BIG_ENDIAN__ > ANON(_Decimal32, f1, STACK+32) /* Note: no promotion to _Decimal64. */ > +#else > + ANON(_Decimal32, f1, STACK+36) /* Note: no promotion to _Decimal64. */ > +#endif > LAST_ANON(_Decimal64, 0.5dd, STACK+40) > #endif
On 22/11/2022 09:01, Christophe Lyon via Gcc-patches wrote: > gcc.target/aarch64/aapcs64/test_dfp_17.c has been failing on > big-endian, because the _Decimal32 on-stack argument is not padded in > the same direction depending on endianness. > > This patch fixes the testcase so that it expects the argument in the > right stack location, similarly to what other tests do in the same > directory. > > gcc/testsuite/ChangeLog: > > PR target/107604 > * gcc.target/aarch64/aapcs64/test_dfp_17.c: Fix for big-endian. > --- > gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c b/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c > index 22dc462bf7c..3c45f715cf7 100644 > --- a/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c > +++ b/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c > @@ -32,6 +32,10 @@ struct z b = { 9.0dd, 10.0dd, 11.0dd, 12.0dd }; > ANON(struct z, a, D1) > ANON(struct z, b, STACK) > ANON(int , 5, W0) > +#ifndef __AAPCS64_BIG_ENDIAN__ > ANON(_Decimal32, f1, STACK+32) /* Note: no promotion to _Decimal64. */ > +#else > + ANON(_Decimal32, f1, STACK+36) /* Note: no promotion to _Decimal64. */ > +#endif > LAST_ANON(_Decimal64, 0.5dd, STACK+40) > #endif Why would a Decimal32 change stack placement based on the endianness? Isn't it a 4-byte object?
Richard Earnshaw via Gcc-patches <gcc-patches@gcc.gnu.org> writes: > On 22/11/2022 09:01, Christophe Lyon via Gcc-patches wrote: >> gcc.target/aarch64/aapcs64/test_dfp_17.c has been failing on >> big-endian, because the _Decimal32 on-stack argument is not padded in >> the same direction depending on endianness. >> >> This patch fixes the testcase so that it expects the argument in the >> right stack location, similarly to what other tests do in the same >> directory. >> >> gcc/testsuite/ChangeLog: >> >> PR target/107604 >> * gcc.target/aarch64/aapcs64/test_dfp_17.c: Fix for big-endian. >> --- >> gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c | 4 ++++ >> 1 file changed, 4 insertions(+) >> >> diff --git a/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c b/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c >> index 22dc462bf7c..3c45f715cf7 100644 >> --- a/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c >> +++ b/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c >> @@ -32,6 +32,10 @@ struct z b = { 9.0dd, 10.0dd, 11.0dd, 12.0dd }; >> ANON(struct z, a, D1) >> ANON(struct z, b, STACK) >> ANON(int , 5, W0) >> +#ifndef __AAPCS64_BIG_ENDIAN__ >> ANON(_Decimal32, f1, STACK+32) /* Note: no promotion to _Decimal64. */ >> +#else >> + ANON(_Decimal32, f1, STACK+36) /* Note: no promotion to _Decimal64. */ >> +#endif >> LAST_ANON(_Decimal64, 0.5dd, STACK+40) >> #endif > > Why would a Decimal32 change stack placement based on the endianness? > Isn't it a 4-byte object? Yes, but PARM_BOUNDARY (64) sets a minimum alignment for all stack arguments. Richard
On 22/11/2022 11:21, Richard Sandiford wrote: > Richard Earnshaw via Gcc-patches <gcc-patches@gcc.gnu.org> writes: >> On 22/11/2022 09:01, Christophe Lyon via Gcc-patches wrote: >>> gcc.target/aarch64/aapcs64/test_dfp_17.c has been failing on >>> big-endian, because the _Decimal32 on-stack argument is not padded in >>> the same direction depending on endianness. >>> >>> This patch fixes the testcase so that it expects the argument in the >>> right stack location, similarly to what other tests do in the same >>> directory. >>> >>> gcc/testsuite/ChangeLog: >>> >>> PR target/107604 >>> * gcc.target/aarch64/aapcs64/test_dfp_17.c: Fix for big-endian. >>> --- >>> gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c | 4 ++++ >>> 1 file changed, 4 insertions(+) >>> >>> diff --git a/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c b/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c >>> index 22dc462bf7c..3c45f715cf7 100644 >>> --- a/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c >>> +++ b/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c >>> @@ -32,6 +32,10 @@ struct z b = { 9.0dd, 10.0dd, 11.0dd, 12.0dd }; >>> ANON(struct z, a, D1) >>> ANON(struct z, b, STACK) >>> ANON(int , 5, W0) >>> +#ifndef __AAPCS64_BIG_ENDIAN__ >>> ANON(_Decimal32, f1, STACK+32) /* Note: no promotion to _Decimal64. */ >>> +#else >>> + ANON(_Decimal32, f1, STACK+36) /* Note: no promotion to _Decimal64. */ >>> +#endif >>> LAST_ANON(_Decimal64, 0.5dd, STACK+40) >>> #endif >> >> Why would a Decimal32 change stack placement based on the endianness? >> Isn't it a 4-byte object? > > Yes, but PARM_BOUNDARY (64) sets a minimum alignment for all stack arguments. > > Richard Ah, OK. I wonder if we should have a new macro in the tests, something like ANON_PADDED to describe this case and that works things out more automagically for big-endian. I notice the new ANON definition is not correctly indented. R.
On 11/22/22 12:33, Richard Earnshaw wrote: > > > On 22/11/2022 11:21, Richard Sandiford wrote: >> Richard Earnshaw via Gcc-patches <gcc-patches@gcc.gnu.org> writes: >>> On 22/11/2022 09:01, Christophe Lyon via Gcc-patches wrote: >>>> gcc.target/aarch64/aapcs64/test_dfp_17.c has been failing on >>>> big-endian, because the _Decimal32 on-stack argument is not padded in >>>> the same direction depending on endianness. >>>> >>>> This patch fixes the testcase so that it expects the argument in the >>>> right stack location, similarly to what other tests do in the same >>>> directory. >>>> >>>> gcc/testsuite/ChangeLog: >>>> >>>> PR target/107604 >>>> * gcc.target/aarch64/aapcs64/test_dfp_17.c: Fix for big-endian. >>>> --- >>>> gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c | 4 ++++ >>>> 1 file changed, 4 insertions(+) >>>> >>>> diff --git a/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c >>>> b/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c >>>> index 22dc462bf7c..3c45f715cf7 100644 >>>> --- a/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c >>>> +++ b/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c >>>> @@ -32,6 +32,10 @@ struct z b = { 9.0dd, 10.0dd, 11.0dd, 12.0dd }; >>>> ANON(struct z, a, D1) >>>> ANON(struct z, b, STACK) >>>> ANON(int , 5, W0) >>>> +#ifndef __AAPCS64_BIG_ENDIAN__ >>>> ANON(_Decimal32, f1, STACK+32) /* Note: no promotion to >>>> _Decimal64. */ >>>> +#else >>>> + ANON(_Decimal32, f1, STACK+36) /* Note: no promotion to >>>> _Decimal64. */ >>>> +#endif >>>> LAST_ANON(_Decimal64, 0.5dd, STACK+40) >>>> #endif >>> >>> Why would a Decimal32 change stack placement based on the endianness? >>> Isn't it a 4-byte object? >> >> Yes, but PARM_BOUNDARY (64) sets a minimum alignment for all stack >> arguments. >> >> Richard > > Ah, OK. Indeed, it was not immediately obvious to me either when looking at aarch64_layout_arg. aarch64_function_arg_padding comes into play, too. > > I wonder if we should have a new macro in the tests, something like > ANON_PADDED to describe this case and that works things out more > automagically for big-endian. Maybe, there are quite a few tests under aapcs64 which have a similar #ifndef __AAPCS64_BIG_ENDIAN__ > I notice the new ANON definition is not correctly indented. > > R.
On 11/22/22 12:33, Richard Earnshaw wrote: > > > On 22/11/2022 11:21, Richard Sandiford wrote: >> Richard Earnshaw via Gcc-patches <gcc-patches@gcc.gnu.org> writes: >>> On 22/11/2022 09:01, Christophe Lyon via Gcc-patches wrote: >>>> gcc.target/aarch64/aapcs64/test_dfp_17.c has been failing on >>>> big-endian, because the _Decimal32 on-stack argument is not >>>> padded in the same direction depending on endianness. >>>> >>>> This patch fixes the testcase so that it expects the argument >>>> in the right stack location, similarly to what other tests do >>>> in the same directory. >>>> >>>> gcc/testsuite/ChangeLog: >>>> >>>> PR target/107604 * gcc.target/aarch64/aapcs64/test_dfp_17.c: >>>> Fix for big-endian. --- >>>> gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c | 4 >>>> ++++ 1 file changed, 4 insertions(+) >>>> >>>> diff --git >>>> a/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c >>>> b/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c index >>>> 22dc462bf7c..3c45f715cf7 100644 --- >>>> a/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c +++ >>>> b/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c @@ >>>> -32,6 +32,10 @@ struct z b = { 9.0dd, 10.0dd, 11.0dd, 12.0dd >>>> }; ANON(struct z, a, D1) ANON(struct z, b, STACK) ANON(int , 5, >>>> W0) +#ifndef __AAPCS64_BIG_ENDIAN__ ANON(_Decimal32, f1, >>>> STACK+32) /* Note: no promotion to _Decimal64. */ +#else + >>>> ANON(_Decimal32, f1, STACK+36) /* Note: no promotion to >>>> _Decimal64. */ +#endif LAST_ANON(_Decimal64, 0.5dd, STACK+40) >>>> #endif >>> >>> Why would a Decimal32 change stack placement based on the >>> endianness? Isn't it a 4-byte object? >> >> Yes, but PARM_BOUNDARY (64) sets a minimum alignment for all stack >> arguments. >> >> Richard > > Ah, OK. Indeed, it was not immediately obvious to me either, when looking at aarch64_layout_arg. aarch64_function_arg_padding comes into play, too. > > I wonder if we should have a new macro in the tests, something like > ANON_PADDED to describe this case and that works things out more > automagically for big-endian. Maybe. There are many other tests under aapcs64/ which have a similar #ifndef __AAPCS64_BIG_ENDIAN__ > I notice the new ANON definition is not correctly indented. It looks OK on my side (2 spaces). Thanks, Christophe > > R.
On 22/11/2022 13:09, Christophe Lyon wrote: > > > On 11/22/22 12:33, Richard Earnshaw wrote: >> >> >> On 22/11/2022 11:21, Richard Sandiford wrote: >>> Richard Earnshaw via Gcc-patches <gcc-patches@gcc.gnu.org> writes: >>>> On 22/11/2022 09:01, Christophe Lyon via Gcc-patches wrote: >>>>> gcc.target/aarch64/aapcs64/test_dfp_17.c has been failing on >>>>> big-endian, because the _Decimal32 on-stack argument is not >>>>> padded in the same direction depending on endianness. >>>>> >>>>> This patch fixes the testcase so that it expects the argument >>>>> in the right stack location, similarly to what other tests do >>>>> in the same directory. >>>>> >>>>> gcc/testsuite/ChangeLog: >>>>> >>>>> PR target/107604 * gcc.target/aarch64/aapcs64/test_dfp_17.c: >>>>> Fix for big-endian. --- >>>>> gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c | 4 >>>>> ++++ 1 file changed, 4 insertions(+) >>>>> >>>>> diff --git >>>>> a/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c >>>>> b/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c index >>>>> 22dc462bf7c..3c45f715cf7 100644 --- >>>>> a/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c +++ >>>>> b/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c @@ >>>>> -32,6 +32,10 @@ struct z b = { 9.0dd, 10.0dd, 11.0dd, 12.0dd >>>>> }; ANON(struct z, a, D1) ANON(struct z, b, STACK) ANON(int , 5, >>>>> W0) +#ifndef __AAPCS64_BIG_ENDIAN__ ANON(_Decimal32, f1, >>>>> STACK+32) /* Note: no promotion to _Decimal64. */ +#else + >>>>> ANON(_Decimal32, f1, STACK+36) /* Note: no promotion to >>>>> _Decimal64. */ +#endif LAST_ANON(_Decimal64, 0.5dd, STACK+40) #endif >>>> >>>> Why would a Decimal32 change stack placement based on the >>>> endianness? Isn't it a 4-byte object? >>> >>> Yes, but PARM_BOUNDARY (64) sets a minimum alignment for all stack >>> arguments. >>> >>> Richard >> >> Ah, OK. > Indeed, it was not immediately obvious to me either, when looking at > aarch64_layout_arg. aarch64_function_arg_padding comes into play, too. > >> >> I wonder if we should have a new macro in the tests, something like >> ANON_PADDED to describe this case and that works things out more >> automagically for big-endian. > Maybe. There are many other tests under aapcs64/ which have a similar > #ifndef __AAPCS64_BIG_ENDIAN__ > Yes, it could be used to clean all those up as well. > >> I notice the new ANON definition is not correctly indented. > It looks OK on my side (2 spaces). Never mind then, it must be a quirk of how the diff is displayed. > > Thanks, > > Christophe > >> >> R.
diff --git a/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c b/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c index 22dc462bf7c..3c45f715cf7 100644 --- a/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c +++ b/gcc/testsuite/gcc.target/aarch64/aapcs64/test_dfp_17.c @@ -32,6 +32,10 @@ struct z b = { 9.0dd, 10.0dd, 11.0dd, 12.0dd }; ANON(struct z, a, D1) ANON(struct z, b, STACK) ANON(int , 5, W0) +#ifndef __AAPCS64_BIG_ENDIAN__ ANON(_Decimal32, f1, STACK+32) /* Note: no promotion to _Decimal64. */ +#else + ANON(_Decimal32, f1, STACK+36) /* Note: no promotion to _Decimal64. */ +#endif LAST_ANON(_Decimal64, 0.5dd, STACK+40) #endif