public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "aldyh at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/102542] [12 Regression] ICE Segmentation fault since r12-3876-g4a960d548b7d7d94 Date: Fri, 01 Oct 2021 11:18:29 +0000 [thread overview] Message-ID: <bug-102542-4-1aKKSfTcQ9@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-102542-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102542 Aldy Hernandez <aldyh at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jeffreyalaw at gmail dot com --- Comment #5 from Aldy Hernandez <aldyh at gcc dot gnu.org> --- (In reply to rguenther@suse.de from comment #4) > On Thu, 30 Sep 2021, aldyh at gcc dot gnu.org wrote: Thanks for the loop explanation. It's quite helpful. > So the threading at hand rotates the loop (which is only so-so OK), > that might be problematic in case it creates a non-do-while loop > after loop header copying. > > In this process it might also lose track of the loop, causing it to > be re-discovered as separate entity which has problems of its own. > > IMHO we should avoid threadings through a loop header if the path > ends in the loop itself, even if it doesn't introduce a new entry but > just re-directs the existing one. It looks like Jeff and you have stumbled on various corner cases we must address in cancel_invalid_paths(). Could I inconvenience you to tweak this function with your insight? It's a tiny function, and it seems you're much more qualified to add the restriction code. If not, I'm sure I can stumble around it and send it for review. Orthogonal to this, it does look like the extra thread is causing an ICE in slp which must be addressed?? Thanks.
next prev parent reply other threads:[~2021-10-01 11:18 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-09-30 10:12 [Bug tree-optimization/102542] New: " marxin at gcc dot gnu.org 2021-09-30 10:13 ` [Bug tree-optimization/102542] " marxin at gcc dot gnu.org 2021-09-30 10:16 ` pinskia at gcc dot gnu.org 2021-09-30 16:04 ` aldyh at gcc dot gnu.org 2021-09-30 22:31 ` pinskia at gcc dot gnu.org 2021-10-01 6:18 ` rguenther at suse dot de 2021-10-01 11:18 ` aldyh at gcc dot gnu.org [this message] 2021-10-01 11:46 ` rguenth at gcc dot gnu.org 2021-10-01 15:07 ` aldyh at redhat dot com 2022-01-17 13:16 ` 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-102542-4-1aKKSfTcQ9@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).