From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 1646A3857803; Tue, 25 Jan 2022 12:27:06 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1646A3857803
From: "rdapp at linux dot ibm.com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/104198] [12 regression] ifcvf change breaks
 64-bit SPARC bootstrap
Date: Tue, 25 Jan 2022 12:27:05 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 12.0
X-Bugzilla-Keywords: build, wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rdapp at linux dot ibm.com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 12.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-104198-4-9Cdh4SjxKy@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-104198-4@http.gcc.gnu.org/bugzilla/>
References: <bug-104198-4@http.gcc.gnu.org/bugzilla/>
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 <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jan 2022 12:27:06 -0000

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D104198

--- Comment #9 from rdapp at linux dot ibm.com ---
I believe I know what's happening and it's indeed something that could also
happen on other targets.

I did not anticipate backends re-creating the initial condition for the case
when we pass it a cc comparison.  The SPARC backend does this, using a (now)
already overwritten value for comparison.  Other targets could also do this=
 but
maybe do not currently but it would always lead to wrong code.

Not yet sure about a proper solution.  Since we go over the insns twice any=
way
we could check the created sequences for overlap with the condition again a=
nd
mark them.  In the second iteration we would make sure to not overwrite the
condition unless there is no insn later that uses it.  Hope to come up with
something testable by today.=