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/108910] [12/13 Regression] Further ICE in aarch64_layout_arg
Date: Sun, 19 Mar 2023 05:29:57 +0000	[thread overview]
Message-ID: <bug-108910-4-H7ItdaGnvi@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-108910-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108910

--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:467a789b0c5e50676bb7e65f861b9d79e0c9fe4c

commit r12-9278-g467a789b0c5e50676bb7e65f861b9d79e0c9fe4c
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Mar 1 09:54:52 2023 +0100

    lto: Fix up lto_fixup_prevailing_type [PR108910]

    Without LTO, TYPE_POINTER_TO/TYPE_REFERENCE_TO chains are only maintained
    inside of build_{pointer,reference}_type_for_mode and those routines
    ensure that the pointer/reference type added to the chain is really
    without any user attributes (unless something would modify the types
    in place, but that would be wrong).

    Now, LTO adds stuff to these chains in lto_fixup_prevailing_type but
    doesn't guarantee that.  The testcase in the PR (which I'm not including
    for testsuite because when (I hope) the aarch64 backend bug will be fixed,
    the testcase would work either way) shows a case where user has
    TYPE_USER_ALIGN type with very high alignment, as there aren't enough
    pointers to float in the code left that one becomes the prevailing one
    (because types with attributes are created with build_distinct_type_copy
    and thus their own TYPE_MAIN_VARIANTs), lto_fixup_prevailing_type puts
    it into the TYPE_POINTER_TO chain of float and later on during expansion
    of __builtin_cexpif expander uses build_pointer_type (float_type_node)
    to emit a sincosf call and instead of getting a normal pointer type gets
    this non-standard one.

    The following patch fixes that by not adding into those chains
    types with TYPE_ATTRIBUTES, and for REFERENCE_TYPEs not even with
    TYPE_REF_IS_RVALUE - while the C++ FE adds those into those chains,
    it always ensures such a type goes immediately after the corresponding
    non-TYPE_REF_IS_RVALUE REFERENCE_TYPE with the same
    mode/TYPE_REF_CAN_ALIAS_ALL, so LTO would need to ensure that too, but
    TYPE_REF_IS_RVALUE types are looked that way only in the C++ FE.

    2023-03-01  Jakub Jelinek  <jakub@redhat.com>

            PR target/108910
            * lto-common.cc (lto_fixup_prevailing_type): Don't add t to
            TYPE_POINTER_TO or TYPE_REFERENCE_TO chain if it has
            TYPE_ATTRIBUTES or is TYPE_REF_IS_RVALUE.

    (cherry picked from commit 9b4f7004a77b10bc403875f56c94f73ef86562d8)

  parent reply	other threads:[~2023-03-19  5:29 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-23 20:56 [Bug target/108910] New: [13 " jakub at gcc dot gnu.org
2023-02-23 20:56 ` [Bug target/108910] " jakub at gcc dot gnu.org
2023-02-23 21:01 ` pinskia at gcc dot gnu.org
2023-02-23 21:03 ` [Bug target/108910] [12/13 " pinskia at gcc dot gnu.org
2023-02-23 21:09 ` jakub at gcc dot gnu.org
2023-02-23 21:55 ` jakub at gcc dot gnu.org
2023-02-27 13:05 ` jakub at gcc dot gnu.org
2023-02-28 16:47 ` clyon at gcc dot gnu.org
2023-03-01  9:00 ` cvs-commit at gcc dot gnu.org
2023-03-01  9:04 ` jakub at gcc dot gnu.org
2023-03-10 15:10 ` clyon at gcc dot gnu.org
2023-03-10 15:14 ` jakub at gcc dot gnu.org
2023-03-10 16:09 ` jakub at gcc dot gnu.org
2023-03-19  5:29 ` cvs-commit at gcc dot gnu.org [this message]
2023-04-03 14:06 ` jakub at gcc dot gnu.org
2023-04-13 15:58 ` cvs-commit at gcc dot gnu.org
2023-04-13 15:58 ` [Bug target/108910] [12 " rsandifo at gcc dot gnu.org
2023-04-14  7:12 ` schwab@linux-m68k.org
2023-04-14  8:24 ` rguenth at gcc dot gnu.org
2023-04-14 18:19 ` ebotcazou at gcc dot gnu.org
2023-04-14 20:51 ` jason at gcc dot gnu.org
2023-04-17 13:41 ` cvs-commit at gcc dot gnu.org
2023-04-17 13:43 ` rsandifo 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-108910-4-H7ItdaGnvi@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).