From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id DF02A3858439; Thu, 25 Nov 2021 03:07:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DF02A3858439 From: "tnfchris at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/103404] ICE: SIGSEGV in insert_with_costs (cse.c:1569) with custom flags Date: Thu, 25 Nov 2021 03:07:42 +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: 12.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: tnfchris at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: tnfchris at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- 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, 25 Nov 2021 03:07:43 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103404 --- Comment #5 from Tamar Christina --- This is a somewhat latent bug in CSE where merge_equiv_classes assumes that= all entries into the equivalence table are unique but CSE makes no attempt to enforce this constraint. So inserting the same equivalence into the table twice results in the same entry being added twice but pointed to the same expression. Normally this doesn't happen during normal value CSEing because a virtual r= eg is assigned only once so you ever only get one SET statement with the given DEST. What changed with my patch is that the vectors of const_int also get equivalences to constants inside a vector, i.e. you can extract an element = from the vector should you need it. e.g. this instruction (insn 18 17 24 2 (set (subreg:V1SI (reg:SI 97 [ _10 ]) 0) (const_vector:V1SI [ (const_int 0 [0]) ])) "cse.c":11:9 1363 {*movv1si_internal} (expr_list:REG_UNUSED (reg:SI 97 [ _10 ]) (nil))) ends up generating two equivalences. the first one is that reg:SI 97 is 0. The second one is that 0 can be extracted from the V1SI, so subreg (subreg:= V1SI (reg:SI 97) 0) 0 =3D=3D 0. This nested subreg gets folded away to just reg:SI 97 and we re-insert the = same equivalence and end up with: (rr) p dump_class (class1) Equivalence chain for (reg:SI 105 [ iD.2893 ]): (reg:SI 105 [ iD.2893 ]) $3 =3D void (rr) p dump_class (class2) Equivalence chain for (const_int 0 [0]): (const_int 0 [0]) (reg:SI 97 [ _10 ]) (reg:SI 97 [ _10 ]) $4 =3D void merge_equiv_classes then crashes because after it merges the first (reg:SI = 97 [ _10 ]) the reference to it in class2 is invalid. So I believe the fix should be that the hash table insertion code should not insert a value if it already exists in the table. Testing a patch.=