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 1312D3858D35; Thu,  1 Dec 2022 16:52:39 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1312D3858D35
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1669913559;
	bh=meoKpijVILJZSmGBpHqeKS3cvuQY+qgBOQUaMlzEfRg=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=f68+O8d83xyGU1iHI9MlLysxRSpsrfA6v1OyxUMi2qFpBzt/zzVuDie5IyVrVgSuD
	 +zmt5Rz0IR5eWrCrfNhQBvgkPvuurohg5sWU2DoPiiASV5/GeNUl2LGy7eRT8mcIZp
	 U+O2PiGh9CNFqBPX0uQFjjDlhUv45mYgkp3dGUCM=
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/107833] [12/13 Regression] wrong code at -Os
 and above on x86_64-linux-gnu since r12-5138-ge82c382971664d6f
Date: Thu, 01 Dec 2022 16:52:38 +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: 12.2.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 12.3
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-107833-4-GmweDAKclP@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-107833-4@http.gcc.gnu.org/bugzilla/>
References: <bug-107833-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=3D107833

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think this is CCP's fault rather than VRP.
Everything I've looked at in the vrp2 dump looks right to me.
In the outer loop, h/i is
  # RANGE [irange] int [0, 3] NONZERO 0x3
  # h_41 =3D PHI <h_21(8), 0(2)>
  # i_44 =3D PHI <i_43(8), i_19(D)(2)>
and the second inner loop has
  _13 =3D (unsigned int) i_44; // This is before the second inner loop
...
  <bb 6> [local count: 304150043]:
  # i_42 =3D PHI <i_23(7), i_44(5)>
  _50 =3D (unsigned int) i_42;
  _17 =3D -_50;
  _34 =3D _13 - _50;
  # RANGE [irange] int [0, 2] NONZERO 0x3
  h_40 =3D (int) _34;
where
  i_23 =3D i_42 + -1;
and
  # h_21 =3D PHI <h_40(6), 3(7)>
Now, sure, i is uninitialized (the i_19(D) in PHI of the outer loop),
but as has been discussed in the first loop a < h isn't true and so we don't
use
i there, and in the second loop d isn't NULL and so we don't i-- there eith=
er,
but
due to the function call we must reread the d value after each iteration.
Which is the reason for the h_40 =3D (int) ((unsigned) i_44 - i_42) computa=
tion
to get h
when d is non-NULL in some iteration - if d is always NULL, it would be 3 in
the PHI.
But ccp4 goes wild on this,
Visiting PHI node: i_44 =3D PHI <i_43(8), i_19(D)(2)>
        Argument #0 (8 -> 3 not executable)
        Argument #1 (2 -> 3 executable)
        i_19(D) Value: UNDEFINED

    PHI node value: UNDEFINED

Lattice value changed to UNDEFINED.  Adding SSA edges to worklist.
...
Visiting statement:
_13 =3D (unsigned int) i_44;
which is likely UNDEFINED
Lattice value changed to UNDEFINED.  Adding SSA edges to worklist.
...
Visiting statement:
_50 =3D (unsigned int) i_42;
which is likely UNDEFINED
Lattice value changed to UNDEFINED.  Adding SSA edges to worklist.
...
Visiting statement:
# RANGE [irange] int [0, 2] NONZERO 0x3
h_40 =3D (int) _34;
which is likely UNDEFINED
Lattice value changed to UNDEFINED.  Adding SSA edges to worklist.
etc., everything based on i is UNDEFINED.  So, either our UNDEFINED handlin=
gin
CCP
is incorrect, or we need to avoid creating that h_40 =3D (int) ((unsigned) =
i_44 -
i_42)
stuff in IVOPTS if it is based on uninitialized (but then, can't we get an
uninitialized value propagated to it only after IVOPTS?).=