From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 701E93858437; Thu, 21 Oct 2021 17:47:33 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 701E93858437 From: "vmakarov at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/102842] [10 Regression] ICE in cselib_record_set at -O2 or greater Date: Thu, 21 Oct 2021 17:47:33 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Version: 10.3.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: vmakarov at gcc dot gnu.org X-Bugzilla-Status: CLOSED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.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 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: Thu, 21 Oct 2021 17:47:33 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102842 --- Comment #12 from Vladimir Makarov --- The patch just hid the bug. I believe the bug is still present on the trunk too. The insn in question is (insn 26 64 109 3 (parallel [ (set (reg:SI 134 [ _12 ]) (plus:SI (mult:SI (reg:SI 117 [ _8 ]) (reg:SI 128)) (reg:SI 138))) (set (reg:SI 135 [ _12+4 ]) (plus:SI (truncate:SI (lshiftrt:DI (plus:DI (mult:DI (zero_extend:DI (reg:SI 117 [ _8 ])) (zero_extend:DI (reg:SI 128))) (zero_extend:DI (reg:SI 138))) (const_int 32 [0x20]))) (reg:SI 138))) ]) "a.cpp":15:32 70 {umlal} (expr_list:REG_DEAD (reg:SI 138) (expr_list:REG_DEAD (reg:SI 128) (nil)))) And its definition is=20 (define_insn "mlal" [(set (match_operand:SI 0 "s_register_operand" "=3Dr,&r") (plus:SI (mult:SI (match_operand:SI 4 "s_register_operand" "%r,r") (match_operand:SI 5 "s_register_operand" "r,r")) (match_operand:SI 1 "s_register_operand" "0,0"))) (set (match_operand:SI 2 "s_register_operand" "=3Dr,&r") (plus:SI (truncate:SI (lshiftrt:DI (plus:DI (mult:DI (SE:DI (match_dup 4)) (SE:DI (match_dup 5))) (zero_extend:DI (match_dup 1))) (const_int 32))) (match_operand:SI 3 "s_register_operand" "2,2")))] "TARGET_32BIT" "mlal%?\\t%0, %2, %4, %5" [(set_attr "type" "umlal") (set_attr "predicable" "yes") (set_attr "arch" "v6,nov6")] After couple of LRA constraints and assignment sub-passes, the two output operands get the same hard reg. And this results in cse abort in post-relo= ad pass. The issue is that reload pseudos for pseudos 134 and 135 get the same value= as they both are matched with different occurrences of pseudo 138 in the insn. The bug is in a very sensitive LRA code area and fixing it will take some t= ime. But I hope I'll have a fix at the end of next week.=