From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id A44883858C2C; Wed, 14 Sep 2022 11:39:54 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A44883858C2C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1663155594; bh=1aLcH2zWfppUGumMRt7lVQ8MJmc/1e/e0IlktU+u8jk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=JQoBIgio2GWvSxmjqmHGtXlwUBZbqdpv1v2ZNpUw/Zgs2o6ShIYL3zUiDoyLU2Opi a8PQ45bdciowcO+jjDv8Mo4SwbotTUTLLfCK6UAo98zGBV+5RhdVcV+9jPx9pc0Kwv eaVQKPuKd2FI1iKgBwOIvKJTwJsAx02DRhUtEq1E= From: "roger at nextmovesoftware dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/106933] [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) since r13-2049-g6f94923dea21bd92 Date: Wed, 14 Sep 2022 11:39:54 +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: roger at nextmovesoftware dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 13.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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=3D106933 Roger Sayle changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |roger at nextmovesoftware = dot com --- Comment #2 from Roger Sayle --- Something very odd is going on. foo.simdclone.2 contains a *cmpti_doublewo= rd instruction, that is defined using define_insn_and_split to be split pre-reload. For some reason, this isn't getting split during the split1 pass, but conti= nues through reload until things finally fail in cprop_hardreg. Interestingly t= he corresponding instruction is correctly split in simdclone.0 and simdclone.1. The .293e.split1 file contains (much redacted)... ;; Function foo.simdclone.0 Splitting with gen_split_2 (i386.md:1511) deleting insn with uid =3D 16. ;; Function foo.simdclone.1 Splitting with gen_split_2 (i386.md:1511) deleting insn with uid =3D 22. ;; Function foo.simdclone.2 i.e. no splits are performed on foo.simdclone.2, but they are on simdclone.0 and simdclone.1. Perhaps an off-by-one error? I'll investigate further, b= ut I doubt this is an issue in the i386.md machine description; the ((simd)) attribute is interacting strangely with the split pass.=