From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id DF40A385840B; Tue, 31 Aug 2021 17:18:15 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DF40A385840B From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/102140] [12 Regression] ICE: in extract_constrain_insn, at recog.c:2670 (insn does not satisfy its constraints) with -Og -fipa-cp -fno-tree-ccp -fno-tree-ter Date: Tue, 31 Aug 2021 17:18:15 +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: 12.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub 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.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc bug_status everconfirmed priority 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2021 17:18:16 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102140 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dje at gcc dot gnu.org, | |jakub at gcc dot gnu.org, | |segher at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Priority|P3 |P1 --- Comment #3 from Jakub Jelinek --- Slightly adjusted testcase, so that there is no warning about too large constant: typedef int __attribute__((__vector_size__ (64))) U; typedef __int128 __attribute__((__vector_size__ (64))) V; int a, b; static void bar (char c, V v) { v *=3D c; U u =3D a + (U) v; (union { U b; }) { u }; b =3D 0; } void foo (void) { bar (1, (V){((__int128) 9223372036854775808ULL) << 64}); } Started with r12-139-g7d6bb80931b429631f63e0fd27bee95f32eb57a9 which was a middle-end change, so I bet it just triggered a latent backend or LRA bug. If I do: typedef int V __attribute__((vector_size (16))); typedef __int128 W __attribute__((vector_size (16))); V foo (void) { return (V) (W) { (unsigned __int128) 1 << 127 }; } V bar (void) { return (V) { 0, 0, 0, -__INT_MAX__ - 1 }; } then the insns like: (insn 9 5 10 2 (set (reg/i:V4SI 66 2) (const_vector:V4SI [ (const_int 0 [0]) repeated x3 (const_int -2147483648 [0xffffffff80000000]) ])) "pr102140-3.c":8:1 1127 {vsx_movv4si_64bit} (expr_list:REG_EQUAL (const_vector:V4SI [ (const_int 0 [0]) repeated x3 (const_int -2147483648 [0xffffffff80000000]) ]) (nil))) is split during split1. But on the above testcase we have (insn 10 7 12 2 (set (reg:TI 118 [ _12 ]) (const_wide_int 0x80000000000000000000000000000000)) "pr102140.c":9= :5 1134 {vsx_movti_64bit} (nil)) ... (insn 17 15 18 2 (set (reg:V4SI 120 [ _14 ]) (subreg:V4SI (reg:TI 118 [ _12 ]) 0)) 1127 {vsx_movv4si_64bit} (expr_list:REG_DEAD (reg:TI 118 [ _12 ]) (expr_list:REG_EQUAL (const_vector:V4SI [ (const_int 0 [0]) repeated x3 (const_int -2147483648 [0xffffffff80000000]) ]) (nil)))) during split1 and only IRA forward propagates the constant into the insn. So perhaps the operand predicate shouldn't allow such constants after split= 1? split1 pass sets PROP_rtl_split_insns property which e.g. the i386 backend = is using to make sure not to match stuff after split1 if it was only supposed = to be valid before split1 (see ix86_pre_reload_split predicate).=