From: Richard Biener <rguenther@suse.de>
To: Martin Sebor <msebor@gmail.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] Remove more stray returns and gcc_unreachable ()s
Date: Tue, 30 Nov 2021 08:51:20 +0100 (CET) [thread overview]
Message-ID: <46pr48os-7po3-rsq6-qs93-n0rsnrr4638@fhfr.qr> (raw)
In-Reply-To: <0e306fb4-1ec1-1c33-6a0d-6f0e359aee33@gmail.com>
On Mon, 29 Nov 2021, Martin Sebor wrote:
> On 11/29/21 11:53 AM, Martin Sebor wrote:
> > On 11/29/21 6:09 AM, Richard Biener via Gcc-patches wrote:
> >> This removes more cases that appear when bootstrap with
> >> -Wunreachable-code-return progresses.
> >>
> > ...
> >> diff --git a/gcc/sel-sched-ir.h b/gcc/sel-sched-ir.h
> >> index 8ee0529d5a8..18e03c4cb96 100644
> >> --- a/gcc/sel-sched-ir.h
> >> +++ b/gcc/sel-sched-ir.h
> >> @@ -1493,8 +1493,6 @@ bb_next_bb (basic_block bb)
> >> default:
> >> return bb->next_bb;
> >> }
> >> -
> >> - gcc_unreachable ();
> >> }
> >
> > Just skiming the changes out of curiosity, this one makes me
> > wonder if the warning shouldn't be taught to avoid triggering
> > on calls to __builtin_unreachable(). They can help make code
> > more readable (e.g., after a case and switch statement that
> > handles all values).
>
> I see someone else raised the same question in a patch I hadn't
> gotten to yet:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585431.html
>
> If you do end up removing the gcc_unreachable() calls, I would
> suggest to replace them with a comment so as not to lose
> the readability benefit.
>
> But I still wonder if it might make sense to teach the warning
> not just about __builtin_unreachable() but also about noreturn
> calls like abort() that (as you explained in the thread above)
> gcc_unreachable() expands to. Is there a benefit to warning
> on such calls?
I'm not sure. I've chosen to eliminate only the "obvious"
cases, like above where there's a default: that returns immediately
visible (not always in the patch context). I've left some in
the code base where that's not so obvious.
IMHO making the flow obvious without a unreachable marker is
superior to obfuscating it and clearing that up with one.
Yes, I thought about not diagnosing things like
return 1;
return 1;
but then what about
return 1;
return 0;
? I've seen cases like
gcc_unreachable ();
return 0;
was that meant to be
return 0;
gcc_unreachable ();
? So it's not entirely clear. I think that if there was a way
to denote definitive 'code should not reach here' function
(a new attribute?) then it would make sense to not warn about
control flow not reaching that. But then it would make sense
to warn about stmts following such annotation.
Richard.
next prev parent reply other threads:[~2021-11-30 7:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-29 13:09 Richard Biener
2021-11-29 18:53 ` Martin Sebor
2021-11-29 19:04 ` Martin Sebor
2021-11-30 7:51 ` Richard Biener [this message]
2021-11-30 23:08 ` Martin Sebor
2021-12-01 8:05 ` Richard Biener
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=46pr48os-7po3-rsq6-qs93-n0rsnrr4638@fhfr.qr \
--to=rguenther@suse.de \
--cc=gcc-patches@gcc.gnu.org \
--cc=msebor@gmail.com \
/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: link
Be 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).