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.

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