From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id AA795383E83B; Wed, 5 Aug 2020 15:45:11 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AA795383E83B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1596642311; bh=pnJmG6BwyjF9FPT79WI8i/QeCbjwWO4ZMmbg0lh8cLg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Gt5pnLqlGKNQPCe4zIJbTiPlz3W8WYGWOVYWxgfO5WzdA6RFR9SHaTkR9FG+NEuDu bTvWRxsV2Od4sifBPGqAbmgFrMzGoWMyadmyghp5gZq0KY7ebQrfgNNnD7hXZMHR5H LYlcIs/pDX0YeYljS6otYycAnvzf1Y1ivIhELT6c= From: "msebor at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/96468] Warn when an empty while loop could have been a do-while Date: Wed, 05 Aug 2020 15:45:11 +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: 10.2.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: enhancement X-Bugzilla-Who: msebor 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: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: component Message-ID: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 15:45:11 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D96468 Martin Sebor changed: What |Removed |Added ---------------------------------------------------------------------------- Component|c |tree-optimization --- Comment #4 from Martin Sebor --- I see. In that case, I don't think such a warning can be implemented in the front end (as suggested by the choice of the Component) because if signaled were neither atomic nor volatile (and not a function call as in your new example) the only way to determine whether the loop might terminate is by analyzing the potential accesses in the body of the prior block for those to it. Such analysis is beyond what the C front end can handle. For example,= in int signaled; void f (double *a) { { for (int i =3D 0; i !=3D 7; ++i) a[i] =3D 0; } while (!signaled); including the block in the loop wouldn't make it finite but the front end c= an't easily determine that. My point is that issuing a warning suggesting the while loop might have been intended to be a do-while would be misleading, as would be suggesting to rewrite the loop as "while (!signaled) { }" This is not a concern if the condition accesses an atomic/volatile object or is a call to a non-const/non-pure function which is readily available in the front end. F= or others, the warning would need to do quite a bit more work. With that, I'll change the component to tree-optimization where I believe implementing this might be more feasible. So just to be clear, I'm not objecting to the request, just clarifying what= it asks for and how difficult it might be implement.=