https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86761
--- Comment #5 from Hans de Jong <r.j.dejong at student dot utwente.nl> --- (In reply to Marek Polacek from comment #3) > You can use -fsanitize-undefined-trap-on-error if you don't want to link > libubsan. Thanks, this has been very useful. I see the sanitizer doubles the executable size to perform all the run-time checks, but significantly less with the simple illegal instruction trap. (In reply to Jonathan Wakely from comment #4) > (In reply to Hans de Jong from comment #0) > > Code runs fine on GCC, despite the warning. > > In C the behaviour of a non-void function that fails to return anything is > only undefined if the return value is used by the caller. > > > Code runs only on G++ with no optimizations. Unpredictable fatal behaviour > > occurs on various optimization levels. > > In C++ standard it's undefined behaviour if a non-void function fails to > return anything, even if the return value is not used by the caller. > > Because you're compiling C++ the behaviour is undefined. The compiler can > assume that the function is never called, because if it was called it would > produce undefined behaviour. > > > hard to track down since the function "setFlags" was nested 3 levels down in > > the code. > > I don't understand how that can make any difference, the warning tells you > where the missing return is. That's the location you need to fix. I understand the discrepancy now that I've been seeing. I'm transitioning a embedded project from C to C++ actually because the language is more strict, so it sounds I shot myself in the foot on this one. Having said that, I suppose it depends from what direction one is used to debugging. In my case I expected the compiler to at least evaluate up to the offending call, and/or execute as many parts around it. But in fact it removed a whole bunch of code at a top level of the program, which at first was very confusing. Some of these "changes" do not have to result in crashing results, but for example the code ends up in a finite for loop that is overflowing, or while single-stepping I saw that a function call towards the offending piece of code was redirected to another function. If you put the warning at face value as a cause then of course it is obvious. I suppose it's not a compiler bug in the sense that you cannot expect the compiler to create a correct program given that the input program is not correct. However my report is initiated by the (implicit) hiding of compound statements and redirection of function calls that I've seen and whether that is desirable, especially since this seems to be different from the more predictable behaviour of GCC 7. Certainly the sanitizer helps in catching undefined behaviour more explicitly.
