From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 261013858439; Mon, 24 Oct 2022 13:31:10 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 261013858439 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1666618270; bh=GlN2rEAlb5jYZ5TDnBfOrUACAjkuL7lOXMZf6MZWhlc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=bZ5Ob//Zw4ks0ywVAEVtXLI4FzxIWaDnMepv/j28+oT0uzvnu3n0N9aBFPhnP/xJW Dbxe1hcHKaP7fxRSkxOBO/iIP7LqIqz+36+4UH+bJynwIZHDdZYqyR3h8Mhdeys2Ok I59eKAV2X+KMGLRbiLgdsFgDNjjsqWdIIx8yV00E= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/107176] [10/11/12/13 Regression] Wrong code at -Os on x86_64-pc-linux-gnu since r7-2012-g43aabfcfd4139e4c Date: Mon, 24 Oct 2022 13:31:09 +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: 13.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: P2 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.5 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: see_also 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=3D107176 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=3D42512 --- Comment #8 from Richard Biener --- PR42512 is also related and its "fix" is even worse... it's worse in that it hides wrong cases but also throws away correct ones. But it also shows that we still mishandle that testcase with or without the fix(es). It seems that the intent of the SCC analysis in interpret_loop_phi is to look at the linear operation (or the chain of linear operations) associated in a way that it matches (T2)(init + ev) from which then (T2) { init, +, ev } follows. So when PHI' =3D (int)(signed char)PHI + 11 we directly match (int)(signed char){ init, +, 11 } and for PHI' =3D (long)((unsigned)PHI + -90u) + 91 we'd have to associate the outer + 91 which we can't do (but effectively do due to the present bug).=