public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/56264] [4.8 Regression] ICE in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:557 Date: Mon, 11 Feb 2013 10:00:00 -0000 [thread overview] Message-ID: <bug-56264-4-delEatjdZS@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-56264-4@http.gcc.gnu.org/bugzilla/> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56264 --- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> 2013-02-11 10:00:18 UTC --- unswitching makes the formerly irreducible inner loop reducible on one path (cfgcleanup makes this loop appear). As we are in the loop optimizer block we are supposed to be in loop-closed SSA. Now we only mark a single block as changed (bb 7, the loop header of the newly recognized inner loop). rewrite_into_loop_closed_ssa functions in the way that it only scans changed_bbs for out-of-def-loop _uses_. I don't see how that can catch all changes detected by (even former) fix_loop_structure which marks blocks as changed whose loop depth changes (that is, if a definition block changes its loop depth but the use block does not, like in this case, we fail to fixup loop-closed SSA form). Not sure if "no new loops are discovered" excluded this possibility in the old scheme. Now, the block with the use that needs a loop-closed PHI node at the exit of the newly discovered loop isn't changed in any way (nor is the exit block). That said - I still fail to see the logic of the old computation of "changed-blocks" in fix_loop_structure. I'd said we need to re-scan all loop blocks of loops we exit to from loops that have 'changed blocks'. And maybe all loop blocks we may exit from to a loop that has 'changed blocks'. Hmmmm.
next prev parent reply other threads:[~2013-02-11 10:00 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-02-09 12:09 [Bug tree-optimization/56264] New: " antoine.balestrat at gmail dot com 2013-02-09 12:15 ` [Bug tree-optimization/56264] " mpolacek at gcc dot gnu.org 2013-02-09 13:37 ` [Bug tree-optimization/56264] [4.8 Regression] " mpolacek at gcc dot gnu.org 2013-02-10 12:21 ` rguenth at gcc dot gnu.org 2013-02-11 10:00 ` rguenth at gcc dot gnu.org [this message] 2013-02-11 10:28 ` rguenth at gcc dot gnu.org 2013-02-11 15:08 ` rguenth at gcc dot gnu.org 2013-02-11 15:10 ` rguenth 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-56264-4-delEatjdZS@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).