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.

  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: link
Be 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).