public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "tnfchris at gcc dot gnu.org" <gcc-bugzilla@gcc.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 [thread overview] Message-ID: <bug-103404-4-cunrnUtD6l@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-103404-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103404 --- Comment #5 from Tamar Christina <tnfchris at gcc dot gnu.org> --- 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 reg 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 == 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 = 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 = 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.
next prev parent reply other threads:[~2021-11-25 3:07 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-11-24 9:47 [Bug rtl-optimization/103404] New: " zsojka at seznam dot cz 2021-11-24 10:14 ` [Bug rtl-optimization/103404] " rguenth at gcc dot gnu.org 2021-11-24 10:39 ` rguenth at gcc dot gnu.org 2021-11-24 10:52 ` marxin at gcc dot gnu.org 2021-11-24 11:27 ` tnfchris at gcc dot gnu.org 2021-11-25 3:07 ` tnfchris at gcc dot gnu.org [this message] 2021-12-06 10:16 ` cvs-commit at gcc dot gnu.org 2021-12-06 10:17 ` tnfchris at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-103404-4-cunrnUtD6l@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).