From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2067.outbound.protection.outlook.com [40.107.22.67]) by sourceware.org (Postfix) with ESMTPS id 47F573892D1D for ; Wed, 8 Jun 2022 12:25:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 47F573892D1D ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=HE+rVfgFbO6fNNB23umlvs7eofD1HoGylIHetfb8i0CADnJQcwjpaxwuVBrJaLxhsTdVHqAqCqj9/0mVs4cU2XzOxCk/0L6QBmedEqSS2HEzIzwUqEMjBg6FluXO1cXM00awS3xpIiflXffUniWKOg3tYmJIXhzcWqfbYnw4szk+aFAtbbIVSTxuRtuJZK7UwVZuVP1nDwC7wFQ42xrAHxpgwEf9Ppv6rJELyuoMVrH2hEy3CbNfS16Hlj7F2njmpFtLQ5yoBeEmfRcEUOGfjqaJVONGarBAvq0PW8db1EcoDGMwCYxhF+FPWoCxpIIg8O080hU5BWYrFHBErjMMWA== 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=8/ADErjgEDMU8UiufDULUE7AzzN7fhWc9pnWFqeE0hU=; b=f9m4IvjsnDWfDMMHuC47Sl0GpZdae9cIABKDZV1IC3C2tHJr3+r4LmIXs2bM1qMXZXjQbViBdFvpb/enPHHRUp9SoET6uTOdYCOp0rS+mRKohg9JrLyVvSQgOe5ggrOj+jbLOYFyvazwbgVsGXQFP38Q3BJaP6QzOC+bsvl2Ac1pn2U2uQXmsWy2bCMwmlM3mXqKdS1Sm05D/60vuRvVFVZ0dBKiNqlZkPjrVm3wN/3cUIdR9XQT92Kk2C76o0J445tEdMZnIxqX3uort/WISMLHx429mInDHlQC6PxvvoczPDMaKzicDxLlYy25uVzlfK6hUI0n0Nn0kmiYMDjTFA== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=gcc.gnu.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] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) Received: from AM6P195CA0060.EURP195.PROD.OUTLOOK.COM (2603:10a6:209:87::37) by VI1PR08MB3933.eurprd08.prod.outlook.com (2603:10a6:803:dd::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5314.18; Wed, 8 Jun 2022 12:25:08 +0000 Received: from VE1EUR03FT038.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:87:cafe::ca) by AM6P195CA0060.outlook.office365.com (2603:10a6:209:87::37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5314.13 via Frontend Transport; Wed, 8 Jun 2022 12:25:08 +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 VE1EUR03FT038.mail.protection.outlook.com (10.152.19.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5332.12 via Frontend Transport; Wed, 8 Jun 2022 12:25:07 +0000 Received: ("Tessian outbound 5b5a41c043d3:v120"); Wed, 08 Jun 2022 12:25:07 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 29e3ae5c97dec31f X-CR-MTA-TID: 64aa7808 Received: from fbd255336754.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 44914CB0-0949-4F06-B7F6-DF2C0AD4C4E5.1; Wed, 08 Jun 2022 12:25:00 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id fbd255336754.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 08 Jun 2022 12:25:00 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=asGSnSPjiQlEy+Orq/XiLDfzUzlPHzUWINgP1odT6dqGfhiRTO59lbZw03MELOxnXU73KERpZZQ6qDxDMcLWW5C3FzKxtYNjCo9PVVC8XQFZ3GVGVXleQEmoeErjAwNWDHH5Xh6Pm84WgnTdmZHnGHNcZm7pbc7olj16hzPZMdVftFNy4E9wNNRSWlBYRCrKHQ1JA1XquGYtROzabPCZAiQX5jR1dIa2SDWx/RRLzw4URTkL/Pg3H4J1djlRpZe4Ipss0bBrXqwx7H7Z5u2e95k5X7L3Mz0cQbaS4rMzyeFJG3Qx7Fs4THdMLsmCJaXyArS5fXGnxui2wvNh6rucXA== 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=8/ADErjgEDMU8UiufDULUE7AzzN7fhWc9pnWFqeE0hU=; b=mEcd7v6GBNOY7i1TqGcMpC6ksvPP3KjkPUJfdyFTI4foCl1jLFrWpLpTfRvQftet126v35O/rz+44aJCZ3iQReUCA3GcONlkl2noWntofwY0GsA0BMJH1TAwg01FXdli3094lPcq+L5DxYDrRVdcc0lYc6KGcQcrPJ5CatfPYWBA1LZtlvx8UVqR6lGeplFM0R9TLZrjHnLuB6oF6V0ogs10D4U0FIFjJ1TYPIlqqnAO2efWpNWCI6yBXAJtdxYwL5C6uLwrF/w/c0cz8rL2TNZ22EWbq5mEmTwzUJpAadfdVP6ezA++/FHIYYVVkWQM9cmHlEVTilw94BUnjKbGQw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; Received: from VI1PR08MB3390.eurprd08.prod.outlook.com (2603:10a6:803:7d::27) by PR2PR08MB4810.eurprd08.prod.outlook.com (2603:10a6:101:17::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5314.14; Wed, 8 Jun 2022 12:24:57 +0000 Received: from VI1PR08MB3390.eurprd08.prod.outlook.com ([fe80::4cab:84d0:9b6c:a39e]) by VI1PR08MB3390.eurprd08.prod.outlook.com ([fe80::4cab:84d0:9b6c:a39e%7]) with mapi id 15.20.5314.019; Wed, 8 Jun 2022 12:24:57 +0000 Message-ID: <08233c21-a521-171b-78d6-5c6fb8460f95@arm.com> Date: Wed, 8 Jun 2022 14:25:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: aarch64: Fix bitfield alignment in param passing [PR105549] Content-Language: en-US To: Christophe Lyon via Gcc-patches , richard.sandiford@arm.com References: <20220607162431.243236-1-christophe.lyon@arm.com> From: Christophe Lyon In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P265CA0028.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2ae::20) To VI1PR08MB3390.eurprd08.prod.outlook.com (2603:10a6:803:7d::27) MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 2e7c731b-3ac2-4fbf-e90e-08da4949ec99 X-MS-TrafficTypeDiagnostic: PR2PR08MB4810:EE_|VE1EUR03FT038:EE_|VI1PR08MB3933:EE_ X-Microsoft-Antispam-PRVS: 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: 3Y7mdXD+EDVDEx+FBLuko8+QGf/H6aHzTdap1ri2V6qrq/Q/q2S57RdH/daGukY8UTE90/YJ1tiiqF/3v33+rscjheq5g+8AOCqv1yvb/Q3SiTQoY5ytpnw1ErkAVST7e8uFMcL0w6AjNdo++thIVXe6H3oln5ryB4Qo+JqFFJHEofli7jOUPWtJ0lSK07gpqpE/sRGsaGH26a+vhi7CAe8oFIUxx5zsk+T5wiHGVUR1Si49uAoZPO/bzWCBoJVdO7YPhB3iwIMIljM7BE6WyU0zSgEC8Tri3PG6Y6k6tAPEL0C7bExi/MckycDVwFWzBBuLe3gwVofWOmnWFLaDueRXSWThdNbRaV+l7RyYbDTXGXVkR1BTUgHVndt6kq1hZUzG8p7irFfdVYSW9oW6rGWkqbgNGy3y30bIdfNIFhTYfYWeZNvS7FRQuaCl5qGMFaYpe0NZMhQkfh47ZF9fe+L+hMv5UzE9hjd2RwUCZN6o+9MOocCABUukkbk4jaamFaqIkALQug1JQWT+jg5mxvk0EDECrCeT5fKAZPF0D78ZPvOUr10muESfBonxekFQFVnjD4H91nlCEGu7F0hQa04Q4UC0PkuAXDeD5EoF1ToWdh++wfAuhVShVdnUATQ4r5Rql3AjYE3Wo+tuclpgBBFFCfETC2xzLX+zHMDN3ITl8klLSdMaNje3aI26Kq+Ju+MxcZInMVZ6gHAnnH6HChRq4XZvdTCSN1OEDwptYkqJfQUz+poo93RQ6ddM2/GwIrKZziFvC5hJLk/uW45a1sfvsLYZjU2qgtBQUeF43iImQlgx5f+OUoXBdulNnwq1IH6SwI+OCGIjUjjQhJSPE6nupzRPYW0Qcu+oCo8Btj8= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR08MB3390.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(186003)(6486002)(86362001)(6636002)(83380400001)(36756003)(31686004)(53546011)(8676002)(30864003)(66556008)(66946007)(84970400001)(6512007)(8936002)(44832011)(31696002)(508600001)(5660300002)(2616005)(2906002)(26005)(66476007)(6666004)(316002)(38100700002)(6506007)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR2PR08MB4810 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT038.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 0df21771-a8b7-43c2-214b-08da4949e63c X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: P3vVeT4hRbcuVCJPCM4FmfBdZ7gOzUVbwx5Rxtb6kqaVyzb7e6tAD8uyhpQccPhwpW9Dqc+KwG5Wv7ggZPVBhpqqXaqSjBJ0Tz/6KguSuEV0OFgGCXQR+muBVDXOmiontskB5m/1a8jBgaLo4NKCSr/R6CToel+1KYXd3p15mJvG1LPRr6ad02j5s521LKIjsPKnSukdeG8uqI210C0nqh2zZHJunfxpuaDOgusAa6IIY0vZ+0bBEB3DmV4qLY/3Ma9g95wgho3gbfEx8PgrHA/weejIiRQOugxfqBKb4eN8ycWYqlccfACKHXzHVa9KyqaKG2vfxZZBGuQbW/14SkS0hnUSZx8/SAWMpy7tiZggQEJhUsz01QcQCFFm/q2TWs/ErhYjeki3b47P4bLpWH8ub92PR7GhFnHfC96TfKkd8ahtJS7sDKZ9GOFSurgLEZQevi+k66lwDEKNgVFZw36rxPANRumGQUdfeSO1Q+phKJZfHkrQCOYgSKZBfBJcH4H9aUDAfg58p6OlcrjPKzV/tmFwLWdoR3KdBrlHyXSx4vsuTJFZo+Urwsm1eHjnbTsP4xij7L9QZdDdMEjQn/XitOh534APsnDGwzHAjV6sPp30Uur3kFaLN+hdx0NRdZfjBlgqyEF5GAe4xwRWscLhJBLgDAWrDQONq+vZAkrX1Bvtt1eok2LOUHo3Sdomzyl7BfKSWZ/b6uivWQwTQPAfbK1gkQReNKlHYJ0f35YV6eEgeuW7PVvDAwxjw69690CDbqFze0BL3YU6wfF+ZuQl6MN74/vOrL7KqlhU/PiVVr/BxgWJyw34Kj/qIUVKV8Ph0s6zTOBHgPzwTfjk5Q== 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:(13230001)(4636009)(40470700004)(46966006)(36840700001)(356005)(30864003)(47076005)(2616005)(336012)(6512007)(26005)(316002)(6636002)(186003)(31686004)(82310400005)(36756003)(40460700003)(83380400001)(6506007)(81166007)(31696002)(84970400001)(36860700001)(86362001)(8676002)(70206006)(70586007)(44832011)(508600001)(6666004)(2906002)(8936002)(6486002)(53546011)(5660300002)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jun 2022 12:25:07.5733 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2e7c731b-3ac2-4fbf-e90e-08da4949ec99 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: VE1EUR03FT038.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB3933 X-Spam-Status: No, score=-13.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, FORGED_SPF_HELO, GIT_PATCH_0, KAM_ASCII_DIVIDERS, KAM_DMARC_NONE, KAM_LOTSOFHASH, KAM_SHORT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE, 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2022 12:25:16 -0000 On 6/7/22 19:44, Richard Sandiford wrote: > Christophe Lyon via Gcc-patches writes: >> While working on enabling DFP for AArch64, I noticed new failures in >> gcc.dg/compat/struct-layout-1.exp (t028) which were not actually >> caused by DFP types handling. These tests are generated during 'make >> check' and enabling DFP made generation different (not sure if new >> non-DFP tests are generated, or if existing ones are generated >> differently, the tests in question are huge and difficult to compare). >> >> Anyway, I reduced the problem to what I attach at the end of the new >> gcc.target/aarch64/aapcs64/va_arg-17.c test and rewrote it in the same >> scheme as other va_arg* AArch64 tests. Richard Sandiford further >> reduced this to a non-vararg function, added as a second testcase. >> >> This is a tough case mixing bitfields and alignment, where >> aarch64_function_arg_alignment did not follow what its descriptive >> comment says: we want to use the natural alignment of the bitfield >> type only if the user didn't override the alignment for the bitfield >> itself. >> >> The fix is thus very small, and this patch adds two new tests >> (va_arg-17.c and pr105549.c). va_arg-17.c contains the reduced >> offending testcase from struct-layout-1.exp for reference. >> >> We also take the opportunity to fix the comment above >> aarch64_function_arg_alignment since the value of the abi_break >> parameter was changed in a previous commit, no longer match the >> description. >> >> 2022-06-02 Christophe Lyon >> >> gcc/ >> PR target/105549 >> * config/aarch64/aarch64.cc (aarch64_function_arg_alignment): >> Check DECL_USER_ALIGN for bitfield. >> >> gcc/testsuite/ >> PR target/105549 >> * gcc.target/aarch64/aapcs64/va_arg-17.c: New. >> * gcc.target/aarch64/pr105549.c: New. >> >> >> ############### Attachment also inlined for ease of reply ############### >> >> >> diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc >> index 40fc5e633992036a2c06867857a681792178ef00..2c6ccce7cb5dc32097d24514ee525729efb6b7ff 100644 >> --- a/gcc/config/aarch64/aarch64.cc >> +++ b/gcc/config/aarch64/aarch64.cc >> @@ -7262,9 +7262,9 @@ aarch64_vfp_is_call_candidate (cumulative_args_t pcum_v, machine_mode mode, >> /* Given MODE and TYPE of a function argument, return the alignment in >> bits. The idea is to suppress any stronger alignment requested by >> the user and opt for the natural alignment (specified in AAPCS64 \S >> - 4.1). ABI_BREAK is set to true if the alignment was incorrectly >> - calculated in versions of GCC prior to GCC-9. This is a helper >> - function for local use only. */ >> + 4.1). ABI_BREAK is set to the old alignment if the alignment was >> + incorrectly calculated in versions of GCC prior to GCC-9. This is >> + a helper function for local use only. */ >> >> static unsigned int >> aarch64_function_arg_alignment (machine_mode mode, const_tree type, >> @@ -7304,7 +7304,10 @@ aarch64_function_arg_alignment (machine_mode mode, const_tree type, >> "s" contains only one Fundamental Data Type (the int field) >> but gains 8-byte alignment and size thanks to "e". */ >> alignment = std::max (alignment, DECL_ALIGN (field)); >> - if (DECL_BIT_FIELD_TYPE (field)) >> + >> + /* Take bit-field type's alignment into account only if the >> + user didn't override this field's alignment. */ >> + if (DECL_BIT_FIELD_TYPE (field) && !DECL_USER_ALIGN (field)) > > I think we need to check DECL_PACKED instead. On its own, an alignment > attribute on the field can only increase alignment, not decrease it. > In constrast, the packed attribute effectively forces the alignment to > 1 byte, so has an effect even without an alignment attribute. Adding an > explicit alignment on top can then increase the alignment from 1 to any > value (bigger or smaller than the original underlying type). Right, but the comment before aarch64_function_arg_alignment says: "The idea is to suppress any stronger alignment requested by the user and opt for the natural alignment (specified in AAPCS64 \S 4.1)" When using DECL_PACKED, wouldn't we check the opposite of this (ie. that the user requested a smaller alignment)? I mean we'd not "suppress stronger alignment" since such cases do not have DECL_PACKED? However I'm not sure which part of the ABI is mentioned in the comment, in my copy 4.1 is "Design Goals" and does not elaborate on bitfields and parameters. > > E.g. for: > > --------------------------------------------------------------------- > typedef unsigned long long ull __attribute__((aligned(ALIGN))); > > #ifndef EXTRA > #define EXTRA unsigned long long x; > #endif > > struct S1 { __attribute__((aligned(1))) ull i : 1; EXTRA }; > struct S2 { __attribute__((aligned(2))) ull i : 1; EXTRA }; > struct S4 { __attribute__((aligned(4))) ull i : 1; EXTRA }; > struct S8 { __attribute__((aligned(8))) ull i : 1; EXTRA }; > struct S16 { __attribute__((aligned(16))) ull i : 1; EXTRA }; > > struct Sp { ull i : 1; EXTRA }__attribute__((packed)); > struct S1p { __attribute__((packed, aligned(1))) ull i : 1; EXTRA }; > struct S2p { __attribute__((packed, aligned(2))) ull i : 1; EXTRA }; > struct S4p { __attribute__((packed, aligned(4))) ull i : 1; EXTRA }; > struct S8p { __attribute__((packed, aligned(8))) ull i : 1; EXTRA }; > struct S16p { __attribute__((packed, aligned(16))) ull i : 1; EXTRA }; > > int f1(int a, struct S1 s) { return s.i; } > int f2(int a, struct S2 s) { return s.i; } > int f4(int a, struct S4 s) { return s.i; } > int f8(int a, struct S8 s) { return s.i; } > int f16(int a, struct S16 s) { return s.i; } > > int fp(int a, struct Sp s) { return s.i; } > int f1p(int a, struct S1p s) { return s.i; } > int f2p(int a, struct S2p s) { return s.i; } > int f4p(int a, struct S4p s) { return s.i; } > int f8p(int a, struct S8p s) { return s.i; } > int f16p(int a, struct S16p s) { return s.i; } > --------------------------------------------------------------------- > > there are at least 4 interesting cases: > > {-DALIGN=8,-DALIGN=16} x {-DEXTRA=,} > > From my reading of the ABI, clang gets all of them right. Which sections of the ABI? I've re-read AAPCS64 (5.9.4 bit-fields subdivision, 8.1.8 bit-fields), and these specific cases are not clear to me :-( > The case GCC currently gets wrong is: > > fp f1p f2p f4p f8p for -DALIGN=16 [A] > > f1 to f16 are equivalent for -DALIGN=16: all the structures have 16-byte > alignment, despite the user alignments on the fields. We currently > handle those correctly. > > Unfortunately, fixing [A] means that this is an ABI break from GCC 12, > so we'll need (yet another) -Wpsabi warning. In this case I guess we're > actually restoring the pre-GCC 9.1 behaviour. gasp! I hoped we'd be safe as this is a bug fix ;-) Do you mean that commit r9-5650-gc590597c45948c was in fact a mistake? I've been looking at it and at r11-8226-g49813aad3292f7, it's a bit convoluted :-) > > An interesting oddity with these rules is that for: > > --------------------------------------------------------------------- > struct S1 { unsigned long long a, b; } __attribute__((aligned(16))); > struct S2 { struct S1 s; }; > > int f1(int a, struct S1 s1) { return s1.a; } > int f2(int a, struct S2 s2) { return s2.s.a; } > --------------------------------------------------------------------- > > S1 is not treated as 16-byte aligned, but S2 is (because the analysis > isn't recursive). Clang and GCC seem to be consistent about that though. > > Thanks, > Richard > >> bitfield_alignment >> = std::max (bitfield_alignment, >> TYPE_ALIGN (DECL_BIT_FIELD_TYPE (field))); >> diff --git a/gcc/testsuite/gcc.target/aarch64/aapcs64/va_arg-17.c b/gcc/testsuite/gcc.target/aarch64/aapcs64/va_arg-17.c >> new file mode 100644 >> index 0000000000000000000000000000000000000000..24895c3ab48309b601f6f22c176f1e52350c2257 >> --- /dev/null >> +++ b/gcc/testsuite/gcc.target/aarch64/aapcs64/va_arg-17.c >> @@ -0,0 +1,105 @@ >> +/* Test AAPCS64 layout and __builtin_va_arg. >> + >> + This test covers a corner case where a composite type parameter fits in one >> + register: we do not need a double-word alignment when accessing it in the >> + va_arg stack area. */ >> + >> +/* { dg-do run { target aarch64*-*-* } } */ >> + >> +#ifndef IN_FRAMEWORK >> +#define AAPCS64_TEST_STDARG >> +#define TESTFILE "va_arg-17.c" >> +#include "type-def.h" >> + >> +enum E6 { e6_0, e6_1, e6_2, e6_3, e6_65533 = 65533, e6_65534, e6_65535 }; >> +typedef enum E6 Tal16E6 __attribute__((aligned (16))); >> +typedef unsigned int Tuint; >> + >> +int fails; >> + >> +union S2844 { >> + Tuint a:((((10) - 1) & 31) + 1); >> + Tal16E6 __attribute__((aligned (2), packed)) b:31; >> + struct{}c[0]; >> +} ; >> +union S2844 s2844; >> +union S2844 a2844[5]; >> + >> +#define HAS_DATA_INIT_FUNC >> +void init_data () >> +{ >> + memset (&s2844, '\0', sizeof (s2844)); >> + memset (a2844, '\0', sizeof (a2844)); >> + s2844.a = 799U; >> + a2844[2].a = 586U; >> +} >> + >> +#include "abitest.h" >> +#else >> + ARG (int , 1 , W0 , LAST_NAMED_ARG_ID) >> + DOTS >> + ANON_PROMOTED (float , 1.0f, double, 1.0, D0, 1) >> + ANON (union S2844 , s2844 , X1 , 2) >> + ANON (long long , 2LL , X2 , 3) >> + ANON (union S2844 , a2844[2] , X3 , 4) >> + LAST_ANON (union S2844 , a2844[2] , X4 , 5) >> +#endif >> + >> +#if 0 >> + /* This test is derived from a case generated by struct-layout-1.exp: */ >> + >> +enum E6 { e6_0, e6_1, e6_2, e6_3, e6_65533 = 65533, e6_65534, e6_65535 }; >> +typedef enum E6 Tal16E6 __attribute__((aligned (16))); >> +typedef unsigned int Tuint; >> + >> +int fails; >> + >> +union S2844 { >> + Tuint a:((((10) - 1) & 31) + 1); >> + Tal16E6 __attribute__((aligned (2), packed)) b:31; >> + struct{}c[0]; >> +} ; >> +union S2844 s2844; >> +union S2844 a2844[5]; >> + >> +typedef __builtin_va_list __gnuc_va_list; >> +typedef __gnuc_va_list va_list; >> + >> +void check2844va (int z, ...) { >> + union S2844 arg, *p; >> + va_list ap; >> + >> + __builtin_va_start(ap,z); >> + if (__builtin_va_arg(ap,double) != 1.0) >> + printf ("fail %d.%d\n", 2844, 0), ++fails; >> + >> + p = &s2844; >> + arg = __builtin_va_arg(ap,union S2844); /* This would fail. */ >> + if (p->a != arg.a) >> + printf ("fail %d.%d\n", 2844, 1), ++fails; >> + >> + if (__builtin_va_arg(ap,long long) != 3LL) >> + printf ("fail %d.%d\n", 2844, 2), ++fails; >> + >> + p = &a2844[2]; >> + arg = __builtin_va_arg(ap,union S2844); /* This would fail. */ >> + if (p->a != arg.a) >> + printf ("fail %d.%d\n", 2844, 3), ++fails; >> + >> + arg = __builtin_va_arg(ap,union S2844); /* This would fail. */ >> + if (p->a != arg.a) >> + printf ("fail %d.%d\n", 2844, 4), ++fails; >> + >> + __builtin_va_end(ap); >> +} >> + >> +int main (void) { >> + int i, j; >> + memset (&s2844, '\0', sizeof (s2844)); >> + memset (a2844, '\0', sizeof (a2844)); >> + s2844.a = 799U; >> + a2844[2].a = 586U; >> + check2844va (1, 1.0, s2844, 2LL, a2844[2], a2844[2]); >> + exit (fails != 0); >> +} >> +#endif /* 0 */ >> diff --git a/gcc/testsuite/gcc.target/aarch64/pr105549.c b/gcc/testsuite/gcc.target/aarch64/pr105549.c >> new file mode 100644 >> index 0000000000000000000000000000000000000000..55a91ed6bc48b56eed61d668971e890dbd3250ef >> --- /dev/null >> +++ b/gcc/testsuite/gcc.target/aarch64/pr105549.c >> @@ -0,0 +1,12 @@ >> +/* { dg-do compile } */ >> +/* { dg-options "-save-temps" } */ >> + >> +enum e { E1 }; >> +typedef enum e e __attribute__((aligned(16))); >> +union u { >> + __attribute__((aligned(2), packed)) e a : 1; >> + int x[4]; >> +}; >> +union u g(int a, union u u2) { return u2; } >> + >> +/* { dg-final { scan-assembler "stp\tx1, x2, \\\[sp, 8\\\]" } } */