[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    Re: Warning specifically for a returning noreturn
From:       Julian Waters via Gcc <gcc () gcc ! gnu ! org>
Date:       2023-07-25 2:38:38
Message-ID: CAP2b4GM-qfEx_ssxUCG_oO3PpiqbiGvyCth219sf_f8B5oqCbA () mail ! gmail ! com
[Download RAW message or body]

I see. I think it may be appropriate to adopt what clang has done and have
one -Winvalid-noreturn for both cases, thoughts?

On Fri, Jul 21, 2023 at 5:43 PM Jonathan Wakely <jwakely.gcc@gmail.com>
wrote:

> On Fri, 21 Jul 2023 at 04:28, Julian Waters via Gcc <gcc@gcc.gnu.org>
> wrote:
> >
> > Hi all,
> >
> > I've found the places responsible for the warnings, but before I do
> > anything I'd like to discuss a couple of things.
> >
> > 1. What would a good name for the warning switch be? How does
> > -Wreturning-noreturn sound?
> > 2. I've thought about this for a while, and I feel like throwing a
> warning
> > for a noreturn method that isn't explicitly noreturn in the Control Flow
> > Graph is a little too harsh. The point of the attribute is to hint to gcc
> > that the method will never return even if it appears so,
>
> Is it? My understanding is that it's for functions the compiler can't
> see the body of, e.g. user-defined functions similar to abort(). A
> function that doesn't return "even if it appears so" implies the
> function body is visible to the compiler. I don't think that's the
> primary use case. The compiler is already perfectly capable of
> optimizing callers appropriately if the function clearly never
> returns, you don't need the attribute for those cases.
>
> > and requiring that
> > the body explicitly do something like call abort() or loop infinitely
> kind
> > of defeats the purpose of the attribute, in my opinion
>
> I disagree, because the attribute is for the benefit of the calling
> code, not the function body itself. And so it still serves that
> purpose whatever the body of the function looks like.
>
> If you've added the attribute, so that calling code can be optimized
> accordingly, but then the body actually does return ... what are you
> playing it? That's weird and certainly deserves a warning. The calling
> code might not work correctly if the function does return, because
> it's been optimized assumed that can never happen, so you cause the
> program to have undefined behaviour by returning from a noreturn
> function. That certainly deserves a warning.
>
> The attribute's primary purpose is to inform callers the function
> won't return. A side effect of that is that the function itself might
> generate warnings if it appears to violate the contract you've made
> (that it won't return). To avoid those warnings, you need to write the
> function body so that it doesn't return. So instead of allowing the
> function to return, call another noreturn function (like abort), or
> add a __builtin_unreachable (or call std::unreachable in C++23), or
> throw an exception.
>
> > 3.
>  If (2) is just me missing something, should I split the warning into 2
> > different warnings for a noreturn definition with an explicit return
> > statement and an implicit one in the case of a method not explicitly
> > throwing/looping infinitely, etc?
>
> I'm not sure it's worth it, as they're closely related. Although I
> suppose you could have a noreturn function that must have a non-void
> return type in order to conform to some expected API (e.g. a virtual
> function, or a function who's address is taken and used as a
> callback), so want to disable the warning about a non-void return, but
> still get warnings for the function body to help you ensure it really
> doesn't return by mistake.
>
[prev in list] [next in list] [prev in thread] [next in thread]