From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 4DBAC3858D37; Sat, 9 Mar 2024 21:04:55 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4DBAC3858D37 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1710018295; bh=D0SkiyelxYNU/gSYU+/xHPjGVuWaLjZNoin/2BxhIOQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=JKl//CIj9P5yDhC79GxY0A4/jl/F6LG0wRZieiU+k17UxeqlN5ruv2EG0xymiaWXu omPL+U1L6fSdC08Si5LJrtz7En5NtIDnusplEgHXJf7BCvyovyMLgaGopNchakGjEP zqh6PKll3vNf9yqA+8cLXepKK6H6vXQ2RxMRAvSc= From: "pinskia at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug ipa/114290] [11/12/13/14 regression] GCC output incorrect output with -O2 since r9-7460-g9f2cfe108f75de Date: Sat, 09 Mar 2024 21:04:54 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: ipa X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: pinskia at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: DUPLICATE X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 11.5 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status 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=3D114290 Andrew Pinski changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #4 from Andrew Pinski --- Yes this is a dup of bug 113907. What is happening is fnsplit happens and splits off from both f and g: return {A / B + (A % B !=3D 0)}; and return {C / D + (C % D !=3D 0)}; into a new 2 functions and the range information is still there for A/B (C/= D). Which is fine. And then ICF comes along and sees this 2 new functions are the same (which = they are) but since the range information is there still from one version of the function (which in this case the bad one), the wrong result happens. This is all described in PR 113907 too. *** This bug has been marked as a duplicate of bug 113907 ***=