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/100494] [11/12 Regression] Unterminated recursion in gimple-range.cc (x86_64-w64-mingw32) Date: Tue, 15 Jun 2021 13:36:12 +0000 [thread overview] Message-ID: <bug-100494-4-AlDfguKonk@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-100494-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100494 --- Comment #6 from Andrew Macleod <amacleod at redhat dot com> --- WE collided making comments :-) --- or maybe not.. that traceback doesn't look like it would be affected :-(. The traceback also doesn't look like its in an infinite loop?.. there can be long chains of calls to resolve things on back edges. Looking at the listing for that file, I see at its maximal depth, the call chain is 492 "traceable" statements deep. This does not include range_of_range_op or calc_stmt method calls, so Id expect the peak call depth to be about 30-40% higher than that, so somewhere in the 640-690 deep range from the first hybrid_folder::value_on_edge call. Your call chain is at 619, so that is not completely unexpected. Does the compilation not finish? or just take ma very long time? On the other targets it finishes very quickly, spending very little time in EVRP. Its unclear to me why this target would be so different, unless a deep call stack is a problem. Does the issue go away with --param=evrp-mode=legacy ? If it does seem to go into an infinite loop, can you try it with -fdump-tree-evrp-details --param=evrp-mode=trace That will generate a sha1*.evrp file, and if you are truly in an infinite loop it will become quite long. On x86-64 mine is 48940 lines long when it finishes. If you have to stop it, and its growing excessively, I shouldn't need more than the first 50,000 lines to see what going on.
next prev parent reply other threads:[~2021-06-15 13:36 UTC|newest] Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-09 19:56 [Bug tree-optimization/100494] New: " john at thesnappy dot net 2021-05-09 20:18 ` [Bug tree-optimization/100494] " john at thesnappy dot net 2021-05-10 8:15 ` [Bug tree-optimization/100494] [11/12 Regression] " rguenth at gcc dot gnu.org 2021-05-14 20:51 ` aldyh at gcc dot gnu.org 2021-06-13 14:54 ` john at thesnappy dot net 2021-06-14 21:07 ` amacleod at redhat dot com 2021-06-15 13:35 ` john at thesnappy dot net 2021-06-15 13:36 ` amacleod at redhat dot com [this message] 2021-06-15 14:02 ` john at thesnappy dot net 2021-06-15 14:15 ` amacleod at redhat dot com 2021-06-15 14:23 ` john at thesnappy dot net 2021-06-15 14:34 ` amacleod at redhat dot com 2021-06-16 13:13 ` john at thesnappy dot net 2021-06-16 13:50 ` amacleod at redhat dot com 2021-07-28 7:06 ` rguenth at gcc dot gnu.org 2021-07-30 14:39 ` amacleod at redhat dot com 2021-12-01 14:28 ` amacleod at redhat dot com
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-100494-4-AlDfguKonk@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).