From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id C889C3858CDA; Tue, 16 Aug 2022 21:03:43 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C889C3858CDA From: "sebastien.michelland@ens-lyon.fr" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/106609] [SH] miscompilation due to incorrect elimination of comparisons to 0 Date: Tue, 16 Aug 2022 21:03:43 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 12.1.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: sebastien.michelland@ens-lyon.fr X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: short_desc 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, 16 Aug 2022 21:03:43 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106609 S=C3=A9bastien Michelland changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|[SH] miscompilation of loop |[SH] miscompilation due to |involving noreturn call |incorrect elimination of | |comparisons to 0 --- Comment #4 from S=C3=A9bastien Michelland --- > Then this is a target specific issue until provided otherwise. mach stand= s for machine (target) specific pass. That makes a lot of sense, thanks. I found a much simpler example exhibiting the bug: int f(int i, int j) { if(i < 0) return 1; if(i + j) return 3; return i; } Latest HEAD with -O1 (same setup as before) compiles it to _f: cmp/pz r4 bf .L3 bf .L4 rts=20=20=20=20=20 mov r4,r0 .L3: rts=20=20=20=20=20 mov #1,r0 .L4: rts=20=20=20=20=20 mov #3,r0 incorrectly eliminating the test for (i + j) !=3D 0. The label .L4 returnin= g 3 is evidently unreachable. Comparing to 0 seems to be required. My previous example also compiles correctly if we check values[i] !=3D 1 instead, which invalidates the loop/= CFG theory. Few commits changed the SH subtree since GCC 11.1.0; I should be able to bi= sect it. In the meantime I've updated the title.=