public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.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 [thread overview] Message-ID: <bug-109661-4-Tjm7N0aIVM@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-109661-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109661 --- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The trunk branch has been updated by Richard Sandiford <rsandifo@gcc.gnu.org>: https://gcc.gnu.org/g:1c26adba4b95f9a79f3aa57637d34cff7982d832 commit r14-456-g1c26adba4b95f9a79f3aa57637d34cff7982d832 Author: Richard Sandiford <richard.sandiford@arm.com> 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): Add 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.
next prev parent reply other threads:[~2023-05-03 16:44 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-04-28 8:18 [Bug target/109661] New: " jakub at gcc dot gnu.org 2023-04-28 8:18 ` [Bug target/109661] " jakub at gcc dot gnu.org 2023-04-28 8:19 ` jakub at gcc dot gnu.org 2023-04-28 8:28 ` jakub at gcc dot gnu.org 2023-04-28 8:44 ` jakub at gcc dot gnu.org 2023-04-28 8:56 ` rsandifo at gcc dot gnu.org 2023-04-28 8:56 ` rsandifo at gcc dot gnu.org 2023-05-02 11:29 ` jakub at gcc dot gnu.org 2023-05-02 11:50 ` rsandifo at gcc dot gnu.org 2023-05-03 16:44 ` cvs-commit at gcc dot gnu.org 2023-05-03 16:44 ` cvs-commit at gcc dot gnu.org [this message] 2023-05-03 16:49 ` [Bug target/109661] [13 " rsandifo at gcc dot gnu.org 2023-05-09 12:18 ` sjames at gcc dot gnu.org 2023-05-11 11:36 ` cvs-commit at gcc dot gnu.org 2023-07-19 11:24 ` rguenth at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-109661-4-Tjm7N0aIVM@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).