public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "msebor at gcc dot gnu.org" <gcc-bugzilla@gcc.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 [thread overview] Message-ID: <bug-96468-4-4G51H5uvLC@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-96468-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96468 Martin Sebor <msebor at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|c |tree-optimization --- Comment #4 from Martin Sebor <msebor at gcc dot gnu.org> --- 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 = 0; i != 7; ++i) a[i] = 0; } while (!signaled); including the block in the loop wouldn't make it finite but the front end can'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. For 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.
next prev parent reply other threads:[~2020-08-05 15:45 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-08-04 17:32 [Bug c/96468] New: " josephcsible at gmail dot com 2020-08-05 7:30 ` [Bug c/96468] " rguenth at gcc dot gnu.org 2020-08-05 14:48 ` msebor at gcc dot gnu.org 2020-08-05 15:03 ` josephcsible at gmail dot com 2020-08-05 15:45 ` msebor at gcc dot gnu.org [this message] 2020-08-05 15:56 ` [Bug tree-optimization/96468] " josephcsible at gmail dot com 2020-08-06 0:07 ` [Bug c/96468] " msebor at gcc dot gnu.org 2020-08-06 23:09 ` egallager at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-96468-4-4G51H5uvLC@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).