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 45979385734F; Wed, 12 Oct 2022 17:50:23 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 45979385734F
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1665597023;
	bh=xCWP23OzhYhxR+AtBlqhGDRBQ2i4zqFnZLsyHdSvPwI=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=OrpG0c+lrK2s+lP9zy/ojW8LY/5KdjqNzBWK07iyT3czvhbma56y20/1pi23vRJ6S
	 hwStno/7BKifDppIHjUbfHzwGsO+eCpxmrRDiGAjb1Vb3+8w35xQG7izYCnbsS0RcG
	 nrHLYu2n6y5Iowr7oyOdWSg0zs5VWlQa25RKBnkA=
From: "hjl.tools at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/107172] [13 Regression] wrong code with "-O1 -ftree-vrp"
 on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e
Date: Wed, 12 Oct 2022 17:50:22 +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: 13.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hjl.tools at gmail dot 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: 13.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-107172-4-ZwI7tLwBy5@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-107172-4@http.gcc.gnu.org/bugzilla/>
References: <bug-107172-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
List-Id: <gcc-bugs.sourceware.org>

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

--- Comment #22 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Segher Boessenkool from comment #21)
> (In reply to Hongtao.liu from comment #19)
> > (In reply to H.J. Lu from comment #18)
> > > (In reply to Segher Boessenkool from comment #16)
> > > > Hi Roger,
> > > >=20
> > > > (In reply to Roger Sayle from comment #15)
> > > > > Yes, a COMPARE rtx can be used to set various flags on x86, but m=
any other
> > > > > operations also legitimately set and/or use MODE_CC, often in a p=
arallel
> > > > > with the primary operation.
> > > >=20
> > > > *Any* MODE_CC setter sets the flags as-if from a compare.  This is =
what
> > > > MODE_CC *is*.
> > > >=20
> > > > Setting something as ne:CC and then using it as somethingelse:CC ha=
s no
> > > > defined meaning.
> > >=20
> > > This
> > >=20
> > > (parallel [
> > >             (set (reg:SI 97)=20
> > >                 (neg:SI (ltu:SI (reg:CCC 17 flags)
> > >                         (const_int 0 [0]))))
> > >             (clobber (reg:CC 17 flags))
> > >         ])
> > >=20
> > > still won't work correctly if reg:CCC 17 flags is set by a compare of
> > > 2 known values.
> >=20
> > I guess Segher means it should be NE instead of LTU in the
> > x86_mov<mode>cc_0_m1_neg, since the setters is NE to const 0.
>=20
> Yes.

So the issue is with the consumer:

(insn 50 49 51 2 (parallel [
            (set (reg:SI 93)
                (neg:SI (ltu:SI (reg:CCC 17 flags)
                        (const_int 0 [0]))))
            (clobber (reg:CC 17 flags))
        ]) "107172.c":4:10 1258 {*x86_movsicc_0_m1_neg}
     (expr_list:REG_DEAD (reg:CCC 17 flags)
        (expr_list:REG_UNUSED (reg:CC 17 flags)
            (nil))))

There are many similar patterns in different backends.  They work as long as
the flags register isn't a known constant since simplify-rtx.cc leaves them
alone.  They become a problem only when the flags register is a known const=
ant.=