From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id EE245386EC3E; Wed, 16 Mar 2022 12:34:24 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EE245386EC3E From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/104931] wrong-code with number_of_iterations_lt_to_ne Date: Wed, 16 Mar 2022 12:34:24 +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.2.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- 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: Wed, 16 Mar 2022 12:34:25 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D104931 --- Comment #3 from Richard Biener --- The bug was made latent by g:51d464b608b38b9e2007948d10b1e0f1dcec142c which ensured that /* If the loop exits immediately, there is nothing to do. */ tree tem =3D fold_binary (code, boolean_type_node, iv0->base, iv1->base); if (tem && integer_zerop (tem)) { if (!every_iteration) return false; niter->niter =3D build_int_cst (unsigned_type_for (type), 0); niter->max =3D 0; return true; } triggered, folding (_2 + 4294967272) + 12 < _2 + 4294967272 to false. That= 's the following part of the revision, and it probably triggers when doing expand_simple_operations. diff --git a/gcc/match.pd b/gcc/match.pd index 84c9b918041..f5dcbf32bc7 100644 --- a/gcc/match.pd +++ b/gcc/match.pd @@ -2143,6 +2143,11 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) (simplify (pointer_plus (pointer_plus:s @0 @1) @3) (pointer_plus @0 (plus @1 @3))) +#if GENERIC +(simplify + (pointer_plus (convert:s (pointer_plus:s @0 @1)) @3) + (convert:type (pointer_plus @0 (plus @1 @3)))) +#endif /* Pattern match It does seem to me that niter analysis relies on statically detecting not rolling loops, at least for the cases we assume no overflow happens and we use number_of_iterations_lt_to_ne. I can't convince myself that only INTEGER_CST appearant negative delta are problematic for pointer types (which we always assume to have no overflow), but that would be the most simplistic solution here. Still "negative" delta values should be problematic for all cases, and since we only restrict us to constant modulo, delta can also be non-constant.=