[Bug c++/89056] New: Optimizer generates bad code for non-void function that fails to return a value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89056
Bug ID: 89056
Summary: Optimizer generates bad code for non-void function
that fails to return a value
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: darryl_okahata at keysight dot com
Target Milestone: ---
Created attachment 45530
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45530&action=edit
preprocessed file
System: ancient Red Hat Enterprise Linux Server release 6.10 (Santiago)
Intel x86_64 system.
g++ -v
Using built-in specs.
COLLECT_GCC=/hped/builds/tfstools/gcc540/linux_x86_64//gcc/8.2.0/bin/g++_x86_64
COLLECT_LTO_WRAPPER=/a/new/sr/proton/d11/build/tfstools/gcc472/linux_x86_64/gcc/8.2.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure --enable-checking=release --enable-languages=c,c++
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --disable-multilib --with-system-zlib
--prefix=/hped/builds/tfstools/gcc472/linux_x86_64/gcc/8.2.0_rebld
--with-gmp=/gfs/sr/sherry/d1/local/dbjornba/btmp
--with-mpfr=/gfs/sr/sherry/d1/local/dbjornba/btmp
--with-mpc=/gfs/sr/sherry/d1/local/dbjornba/btmp
Thread model: posix
gcc version 8.2.0 (GCC)
If you have cruddy code with a non-void function that fails to return a value,
the gcc optimizer can generate an "infinite" loop for a simple iterative loop
(see the end of the *.ii file):
bool test::bah(void)
{
std::deque::iterator iter;
for (iter = values.begin(); iter != values.end(); iter++)
iter->myval -= 0.1;
// returning a value here causes correct code to be generated.
}
The bug can be easily seen using:
g++ -S -O badbad.cc
badbad.cc: In member function 'bool test::bah()':
badbad.cc:42:1: warning: no return statement in function returning non-void
[-Wreturn-type]
}
^
The generated assembly code shows an "infinite" loop for the simple iterative
loop (which only "terminates" when a bus error occurs). The correct code is
generated if you add a proper return value.
Yes, this is a poster child for using -Werror=return-type, but gcc should still
not generate bad code (the return value will, of course, still be undefined).
[Bug c++/89056] Optimizer generates bad code for non-void function that fails to return a value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89056 --- Comment #4 from Darryl Okahata --- This seems rather draconian but, if the standard allows for that, so be it. Thanks.
[Bug c++/89056] Optimizer generates bad code for non-void function that fails to return a value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89056
--- Comment #6 from Darryl Okahata ---
(OK, at this point, I'm just whinging, so please feel free to ignore this.)
I just wish the C++ standard instead just allowed an undefined value to be
returned, instead of generating bad optimized code. 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). 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]
}
^
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. As a result, I have to add
unreachable return statements to insure that g++ does not generate bad
optimized code. Our code runs on multiple platforms, and so I'd rather avoid
the use of g++ extensions (e.g., __builtin_unreachable() or attributes) and
cluttering #ifdefs. Adding an unreachable return is undesirable but simple and
portable:
enum E { A, B };
bool bah(const enum E a)
{
if (a == A)
return false;
if (a == B)
return true;
return false; // UNREACHABLE
}
[Bug c++/90349] missing return with turned on 03 causes infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90349 Darryl Okahata changed: What|Removed |Added CC||darryl_okahata at keysight dot com --- Comment #3 from Darryl Okahata --- The warning really should be turned on by default, with perhaps just the slightest hint that stunningly awesome unexpected optimized code might be generated. If it weren't for the false positives, I'd suggest making this an error when optimization is used. For those of us who merely use compilers (as opposed to those of you who develop them), this appears to be such a POLA violation. Yes, it's a bug in our code, and the code must really be fixed, but you really need to slap us in the face, punch us in the stomach, and kick us in the rear to emphasize just how big a problem this is. Otherwise, "Meh, it's just a warning".
