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.

  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: link
Be 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).