On Wed, Mar 20, 2019 at 02:08:09PM +0000, Moritz Strübe wrote: > Ok, I played around a bit. Interestingly, if I set -fsanitize=udefined and > -fsanitize-undefined-trap-on-error the compiler detects that it will always > trap, and optimizes the code accordingly (the code after the trap is > removed).* Which kind of brings me to David's argument: Shouldn't the > compiler warn if there is undefined behavior it certainly knows of?
What does it mean certainly knows of? The sanitization inserts (conditional) traps for all the constructs that it sanitizes, you certainly don't want warning for that. Even if the compiler can simplify or optimize out some of the guarding conditionals around the traps, that doesn't mean it isn't in dead code that will never be executed. The only safe warning might be if the compiler can prove that whenever main is called, there will be a trap executed later on, but that is not the case in most programs, as one can't prove for most functions they actually never loop and always return to the caller instead of say exiting, aborting, etc. (and even if main traps immediately, one could have work done in constructors and exit from there). Otherwise, would you like to warn if there is unconditional trap in some function? That function could not be ever called, or it could make some function calls before the trap that would never return (exit, abort, throw exception, infinite loop). Jakub