From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 4AE1F3858D33; Wed, 1 Mar 2023 09:00:18 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4AE1F3858D33 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1677661218; bh=LmMZYNjH1lqQ4a3JFI1dzcxHBwB4Ad1hFqDUoNwUPRM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=dJzydJpOdFZ0quVb7mCOe1mQISBheJ2UnGLkmWLfq2yjU7MLgHy02bT0srw3YAMB4 IJOcq2tG7IxK+9KgbE//MCHwiRezSTo6cPZAH5rtiGlbCoJyfXusdxwWUX4Y0r526e yJtSiyk0T3yWv6NW2EcJfe/Sb3a9FpbYf0v5QciU= From: "cvs-commit at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/108910] [12/13 Regression] Further ICE in aarch64_layout_arg Date: Wed, 01 Mar 2023 09:00:01 +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: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 12.3 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=3D108910 --- Comment #7 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:9b4f7004a77b10bc403875f56c94f73ef86562d8 commit r13-6385-g9b4f7004a77b10bc403875f56c94f73ef86562d8 Author: Jakub Jelinek 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 maintain= ed 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 fix= ed, 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 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.=