https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89056
--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Darryl Okahata from comment #6)
> I just wish the C++ standard instead just allowed an undefined value to be
> returned, instead of generating bad optimized code.
It does allow it. The behaviour is undefined, so anything is allowed.
Nobody is claiming the standard *requires* GCC to do this. But it allows it.
> With the current state,
> I either have to add compiler-specific extensions or unreachable return
> statements to insure that correct code is generated (unexpected and violates
> POLA).
Or fix the code. Your original example was buggy code. The warning told you
about it. So fix the code.
> The issue is that g++ (understandably) can't always detect if there
> is always a proper return statement (execution can never hit the end of the
> function). Grossly-oversimplified example (real code is much more
> complicated):
>
> enum E { A, B };
>
> bool bah(const enum E a)
> {
> if (a == A)
> return false;
> if (a == B)
> return true;
> }
>
> Compiling with (8.2.0):
>
> g++ -S -O badbad.cc
>
> gives:
>
> badbad.cc: In function 'bool bah(E)':
> badbad.cc:10:1: warning: control reaches end of non-void function
> [-Wreturn-type]
> }
> ^
If somebody calls bah((E)2) the function has undefined behaviour.
Consider using the -fstrict-enums option if you want GCC to assume nobody
creates invalid enum values.
> Understandable, as I don't expect g++ to figure out complicated code
> machinations. However, I don't know all the circumstances under which this
> warning means that g++ is generating bad code.
It only generates bad code *if the end of the function can be reached*. If you
know it can't be reached, good for you. The warning is bogus in that case.
Either suppress the warning for that function, or ignore the warning for that
function. If you don't know for sure, and maybe the end of the function can be
reached somehow, then the warning is useful and adding the return statement
improves the code.
This really does seem like whinging. Some warnings aren't perfect, but in your
original report the warning was entirely right, and pointed out a bug that
helps fix the code (if you actually heed the warning).
