public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "amacleod at redhat dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/103093] [12 Regression] ICE in get_imports, at gimple-range-gori.cc:221 since r12-4788-gcb596fd43667f92c Date: Fri, 05 Nov 2021 15:14:06 +0000 [thread overview] Message-ID: <bug-103093-4-6GMKhW610t@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-103093-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103093 Andrew Macleod <amacleod at redhat dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #3 from Andrew Macleod <amacleod at redhat dot com> --- This is a case of a series of statements being simplified, and the IL rewritten to be quite different: it starts with _3 = uc_7.9_28 != 0; _4 = (int) _3; _25 = BIT_FIELD_REF <_2, 16, 0>; _6 = (int) _25; _7 = _4 | _6; Since range-ops doesn't understand the BIT_FIELD_REF operator, _25 is considered an import to the defchain for _7. Folding statement: _7 = _4 | _6; and ends up changing this to: _3 = uc_7.9_28 != 0; _4 = (int) _3; _25 = (short int) _2; _6 = (int) _25; _22 = _25 | 1; _7 = (int) _22 and then later we are looking to calculate a range from an outgoing edge in this block, and when GORI steps back to this statement, it steps back from _7 into _22, sees it does not have a dependency chain, so calculates one for it. It finds that _2 is the import, which means the imports no longer match up for _7, so it triggers an assert that something is amok with the dependency chain imports. Internally ranger doesn't use these imports for anything significant, so the fact that they are out of date is not particularly important in the presence of IL that is being updating. GORI will also continue to calculate based on what is in the stmt, all that may change is if the dependencies are different enough, it will be unable to calculate thru the chain properly since it wont be able to find a name in the def chain that it is expecting, and will simply return false. It won't affect any already computed values, and will never result in a wrong-code situation. Updating existing def chains would be problematic as uses further down the def chain would not be updated, so any of them could later trigger an inconsistency assert. As such, I will simply remove the assert. It was primarily of use when we were first introducing the import concept to make sure that there was consistency when they were being built. In the presence of changing IL, the assert no longer has much meaning.
next prev parent reply other threads:[~2021-11-05 15:14 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-11-05 9:12 [Bug c/103093] New: ice in get_imports, at gimple-range-gori.cc:221 dcb314 at hotmail dot com 2021-11-05 11:14 ` [Bug tree-optimization/103093] [12 Regression] " rguenth at gcc dot gnu.org 2021-11-05 11:30 ` [Bug tree-optimization/103093] [12 Regression] ICE in get_imports, at gimple-range-gori.cc:221 since r12-4788-gcb596fd43667f92c marxin at gcc dot gnu.org 2021-11-05 15:14 ` amacleod at redhat dot com [this message] 2021-11-05 17:16 ` cvs-commit at gcc dot gnu.org 2021-11-05 17:18 ` amacleod at redhat dot com 2021-11-08 8:21 ` marxin 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-103093-4-6GMKhW610t@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).