From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id BF06C3854809; Tue, 15 Jun 2021 13:36:12 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BF06C3854809 From: "amacleod at redhat dot com" 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 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 11.1.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: amacleod at redhat dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 11.2 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2021 13:36:12 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D100494 --- Comment #6 from Andrew Macleod --- WE collided making comments :-)=20=20=20 --- 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.=20 Does the compilation not finish? or just take ma very long time? On the o= ther 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 sta= ck is a problem.=20 Does the issue go away with --param=3Devrp-mode=3Dlegacy ? If it does seem to go into an infinite loop, can you try it with -fdump-tree-evrp-details --param=3Devrp-mode=3Dtrace That will generate a sha1*.evrp file, and if you are truly in an infinite l= oop 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.=