This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/79828] missing div-by-zero warning


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).

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]