https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79828
--- Comment #7 from Jeffrey A. Law <law at redhat dot com> --- The thing is, if we could prove the trap is always executed, then we'd just zap everything prior to the trap without visible side effects and everything after the trap. It's actually not an interesting case. It's critical to remember that a trap introduced by the compiler is on a *path* through the CFG and a series of conditionals has to be met for the trap to be executed. The compiler has already tried to prove the path is infeasible and failed. In fact, that pass was originally introduced specifically because there are cases where the compiler will never be able to prove a particular problem path can't execute and as a result it must keep the path in the CFG, which in turn leads to false positives from -Wuninitialized later. By isolating the path and introducing a trap on that path, the CFG simplifies in useful ways *and* if the program were to erroneously get on the path, it gets halted prior to execution of undefined behavior which is desirable from a security standpoint. There is some code in tree-ssa-uninit.c which does predicate analysis to further reduce the set of false positives for -Wuninitialized. However, that code won't solve the problems that folks are looking at here (if it did, we wouldn't have erroneous path isolation to begin with).
