From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 379ED3857011; Wed, 3 May 2023 16:44:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 379ED3857011 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1683132261; bh=qSVv7LaCa2S1WIbu51hHnufwhsYIf9QZGc8g277FnEM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Q4P9iEr6MVmHDLWYy6Xeki3yJftLYdapvd/iWWk5Zw/KnJzfb/ytfUb1DTTj+pGc4 l0k4BsmDVj5R12CIPLOASo6pEUbZ7YJP6QljkuyGNYU1lpaJuHk/R6tUAFC02qKajq bb1QZnXWJlJeuGjws9wFOa+H9zBTSpFMPF4WhF+E= From: "cvs-commit at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/109661] [13/14 Regression] ICE in aarch64_function_arg_alignment when building erlang Date: Wed, 03 May 2023 16:44:20 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: rsandifo at gcc dot gnu.org X-Bugzilla-Target-Milestone: 13.2 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D109661 --- Comment #8 from CVS Commits --- The trunk branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:1c26adba4b95f9a79f3aa57637d34cff7982d832 commit r14-456-g1c26adba4b95f9a79f3aa57637d34cff7982d832 Author: Richard Sandiford Date: Wed May 3 17:43:48 2023 +0100 aarch64: Fix ABI handling of aligned enums [PR109661] aarch64_function_arg_alignment has traditionally taken the alignment of a scalar type T from TYPE_ALIGN (TYPE_MAIN_VARIANT (T)). This is supposed to discard any user alignment and give the alignment of the underlying fundamental type. PR109661 shows that this did the wrong thing for enums with a defined underlying type, because: (1) The enum itself could be aligned, using attributes. (2) The enum would pick up any user alignment on the underlying type. We get the right behaviour if we look at the TYPE_MAIN_VARIANT of the underlying type instead. As always, this affects register and stack arguments differently, because: (a) The code that handles register arguments only considers the alignment of types that occupy two registers, whereas the stack alignment is applied regardless of size. (b) The code that handles register arguments tests the alignment for equality with 16 bytes, so that (unexpected) greater alignments are ignored. The code that handles stack arguments instead caps the alignment to 16 bytes. There is now (since GCC 13) an assert to trap the difference between (a) and (b), which is how the new incompatiblity showed up. Clang alredy handled the testcases correctly, so this patch aligns the GCC behaviour with the Clang behaviour. I'm planning to remove the asserts on the branches, since we don't want to change the ABI there. gcc/ PR target/109661 * config/aarch64/aarch64.cc (aarch64_function_arg_alignment): A= dd a new ABI break parameter for GCC 14. Set it to the alignment of enums that have an underlying type. Take the true alignment of such enums from the TYPE_ALIGN of the underlying type's TYPE_MAIN_VARIANT. (aarch64_function_arg_boundary): Update accordingly. (aarch64_layout_arg, aarch64_gimplify_va_arg_expr): Likewise. Warn about ABI differences. gcc/testsuite/ * g++.target/aarch64/pr109661-1.C: New test. * g++.target/aarch64/pr109661-2.C: Likewise. * g++.target/aarch64/pr109661-3.C: Likewise. * g++.target/aarch64/pr109661-4.C: Likewise. * gcc.target/aarch64/pr109661-1.c: Likewise.=