From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 15DC53858C83; Tue, 2 May 2023 20:37:34 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 15DC53858C83 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1683059854; bh=OUI5GKMmO3G0xEfOGHXnbPqXGlfI60SyuFN8JeqE6V8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=aj8kcO4/ObWCeowkpqvAysSTt2kZYSdVHYM0cx82Ggo2crY4k/2hNUMhIlSgw9nT5 31iDKHEkJNHWfo1G0zUbDhr9DzcZ0fPHm+4E1itYg46D6M4suRaaocMg/LxGePx3qG pf3v/jLHVrn+C/U2ycgpEkRfltOfreCeg3h9E+IM= From: "amacleod at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr Date: Tue, 02 May 2023 20:37:33 +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: 14.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: amacleod at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: aldyh at gcc dot gnu.org X-Bugzilla-Target-Milestone: 14.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D109695 --- Comment #7 from Andrew Macleod --- Created attachment 54973 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D54973&action=3Dedit Patch to fix the issue The problem was exposed by the newly increased size of int_range_max. (We = may want to address that elsewhere) It has grown an order of magnitude in size with wide-int To avoid massive stack growth, range_of_stmt uses prefill_stmt_dependencies= () to do the same thing as a set of nested recursive calls to range_of_stmt, j= ust managing it via a stack of ssa-names instead of actual calls. Once all the dependencies have been resolved, then we invoke fold_stmt and evaluate the stmt, and set the result. The problem is that while processing a series of PHIs, some ssa-names occur multiple times, and setting the result was unconditionally done. In this case, it was really simple: _1947 =3D 77; _1947 was used in multiple phi arguments, as well as other stmts which then= fed long series of PHIs. it always came up as [77, 77], but when the global va= lue was set again, it changes the temporal timestamp.=20=20 The next time it was seen, it was "newer" than the previously calculated va= lue, and we therefore thought we had to go and prefetch things again. It effectively un-did much of the pre-fetching, and we'd end up with very long call chains again.=20 With the increased size of int_range_max, it blew up the stack in this testcase. The fix is to simply check if the new value is different than the previous value, and not set it if so.=20 This would be appropriate to put into gcc13 as well. Patch is currently undergoing testing=