From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 6CB0B385803B; Mon, 29 Jan 2024 17:00:54 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6CB0B385803B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1706547654; bh=2l/uXHXSO7Fd0698gytRY1B+TOX03qimFwdJgTi5RoE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=tQkiu8axOE8M97HfO39BYAwYKheavowMSfTJDN8QZaYdWsxqed8jyZcgufaFoWPNS LtnMfIwkYAuO3IXpGLL5jwKwvoPD6XUkzLk2Mafo5n2FapGBD/BvbV11JPuh5BF7CU tNQ0PL7dIAA357eaht+lHS/Y2OyZwy7F4WEoYt5k= From: "rsandifo at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/111677] [12/13 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes Date: Mon, 29 Jan 2024 17:00:53 +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.2.0 X-Bugzilla-Keywords: ice-on-valid-code, needs-bisection X-Bugzilla-Severity: normal X-Bugzilla-Who: rsandifo 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.4 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=3D111677 --- Comment #21 from Richard Sandiford --- (In reply to Alex Coplan from comment #13) > The problem seems to be this code in aarch64_process_components: >=20 > while (regno !=3D last_regno) > { > bool frame_related_p =3D aarch64_emit_cfi_for_reg_p (regno); > machine_mode mode =3D aarch64_reg_save_mode (regno); >=20 > rtx reg =3D gen_rtx_REG (mode, regno); > poly_int64 offset =3D frame.reg_offset[regno]; > if (frame_pointer_needed) > offset -=3D frame.bytes_below_hard_fp; >=20 > rtx addr =3D plus_constant (Pmode, ptr_reg, offset); > rtx mem =3D gen_frame_mem (mode, addr); >=20 > which emits a TFmode mem with offset 512, which is out of range for TFmode > (so we later ICE with an unrecognisable insn). Presumably this just needs > tweaking to emit a new base anchor in the case of large offsets like this= .=20 > It looks like the code in aarch64_save_callee_saves already does this. We shouldn't emit new anchor registers here, since unlike in the prologue, we don't have any guarantee that certain registers are free. aarch64_get_separate_components is supposed to vet shrink-wrappable offsets, but in this case the offset looks valid, since: str q22, [sp, #512] is a valid instruction. Perhaps the constraints are too narrow?=