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 C21BF3851ABA; Wed, 12 Oct 2022 08:11:41 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C21BF3851ABA
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1665562301;
	bh=uAEYFc9r1lOugno5i/GTQ88C66OZFBBdTsfeHuA9P/k=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=cSa683jlSP4SOUJJxJ/nDNqqQf6GEBFoiaHavPwO9EILKbbIphcdheXDOTbK9n/2H
	 hU3JRUMfWm+XxKn0E6GYe6nsltPNGZEDvfV79vvzlXoixqMaIopmouAzv9GHz0qbew
	 vfZ7nGXgNdAx/dgzszwnI2uOqR9x09h08Y2pClZE=
From: "segher at gcc dot gnu.org" <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 08:11:40 +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: segher at gcc dot gnu.org
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-WGvMFZgBZj@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 #21 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(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 man=
y other
> > > > operations also legitimately set and/or use MODE_CC, often in a par=
allel
> > > > with the primary operation.
> > >=20
> > > *Any* MODE_CC setter sets the flags as-if from a compare.  This is wh=
at
> > > MODE_CC *is*.
> > >=20
> > > Setting something as ne:CC and then using it as somethingelse:CC has =
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.

Yes.

>  (ne:CCC (reg:SI 87 [ a_lsm.8 ])
>                     (const_int 0 [0])))
>=20
>  (define_expand "x86_mov<mode>cc_0_m1_neg"
>    [(parallel
>      [(set (match_operand:SWI48 0 "register_operand")
> -         (neg:SWI48 (ltu:SWI48 (reg:CCC FLAGS_REG) (const_int 0))))
> +         (neg:SWI48 (ne:SWI48 (reg:CCC FLAGS_REG) (const_int 0))))
>       (clobber (reg:CC FLAGS_REG))])])
>=20
> It can pass the PR, but failed pr101617.c, the f1 case.
>=20
> generate:
>         testl   %edi, %edi
>         movl    $1, %edx
>         movl    $-1, %eax
>         cmove   %edx, %eax
>=20
> origin:
>         negl    %edi
>         sbbl    %eax, %eax
>         orl     $1, %eax

And this is why using a relation (e.g. ltu, an RTX_COMPARE) instead of a
compare (an RTX_BIN_ARITH) as setter cannot work.  The setter and the getter
are modified independently by very many parts of the compiler, and then
everything falls apart.

The only valid things on the RHS of a MODE_CC set are a reg, a compare, or
an unspec.  Everything else is undefined and problematical as well.=