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 8F1163858421; Tue,  8 Nov 2022 13:29:03 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8F1163858421
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1667914143;
	bh=Zk71NoaNI8SNk3mldIlWkgCuyJixcK7qos+JbrcOmOs=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=oq7S0zofH120SSBYA9H9rDkOjrFqivjxAsRatx9ixrh0Ks7L9UP3heYrK+HpH5aE+
	 sVoOpcHvGMTaYApnYCMEp295V5fUVBmXZwo2jbpgerxMUuSUzRFxiiqNWBfMtpS4rw
	 Sg3z3xaKg3SmqoEbxewT5KTkyYjCAE0ER2xH8Qls=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/107493] [13 Regression] Wrong code at -Os on
 x86_64-linux-gnu
Date: Tue, 08 Nov 2022 13:29:02 +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: 13.0
X-Bugzilla-Keywords: needs-bisection, wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 13.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-107493-4-yA7wb4t5Kk@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-107493-4@http.gcc.gnu.org/bugzilla/>
References: <bug-107493-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=3D107493

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
a_lsm.9_12 =3D PHI <-21(2), _4(3)>

(set_scalar_evolution
  instantiated_below =3D 2
  (scalar =3D a_lsm.9_12)
  (scalar_evolution =3D (int) {65515, +, 10}_1))

is definitely wrong since the initial value is off.  The evolution after
that looks OK though, so not sure why SCCP gets the wrong final value here,
we compute the number of iterations to zero (also wrong).

It goes wrong when we get to the truncation, we then do

        *evolution_of_loop =3D chrec_convert (type, *evolution_of_loop, at_=
stmt);

with {-21, + 2}_1 converting that to unsigned short.  This ends up in
convert_affine_scev but that assumes it converts the cycle and not that
the conversion is inside the cycle.

The old sanity checking of the initial value would have catched this but the
actual error is elsewhere.  The question is what's valid here.  I'm going to
try restricting this all further.=