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 8BBA03854816; Thu, 25 Feb 2021 13:31:33 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8BBA03854816
From: "matz at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/99101] optimization bug with -ffinite-loops
Date: Thu, 25 Feb 2021 13:31:33 +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: 11.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: matz 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: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-99101-4-fgh0piCXNh@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-99101-4@http.gcc.gnu.org/bugzilla/>
References: <bug-99101-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: Thu, 25 Feb 2021 13:31:33 -0000

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

--- Comment #17 from Michael Matz <matz at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #16)
> Of course since -ffinite-loops and the C++ standard require forward progr=
ess
> here and all testcases expect the loop to not terminate we're in the realm
> of undefined behavior.  But I'm not yet convinced the control-dependence /
> CD-DCE issue only shows up in such cases.  That said, it's fully expected
> that
>=20
> int xx;
> int main()
> {
>   int jobs_ =3D 1;
>   int at_eof_ =3D 0;
>   while (1)
>     {
>       for (int i =3D 0; i < jobs_; i++)
>         {
>           if (at_eof_)
>             continue;
>           at_eof_ =3D 1;
>           if (xx)
>             return 1;
>         }
>       jobs_ =3D 0;
>     }
>   return 0;
> }
>=20
> is eventually optimized to just return 1 with -ffinite-loops and we should
> try to preserve that behavior.

Just commenting on this last statement: I think that's wrong.  It's provable
that 'xx' doesn't change in the loop, and that it starts out as 0 (this is =
main
here).  So in fact we have produced an endless loop without a return, and h=
ence
can do anything (when endless loops are undefined).=