https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79479

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING

--- Comment #13 from Martin Sebor <msebor at gcc dot gnu.org> ---
The false positives/negatives I'm concerned about would result from moving the
warning from the front-end to the middle-end.  This would be necessary to
handle some of the non-trivial cases I mentioned in comment #11.  In the
front-end the warning only sees as far as the end of a full expression.  The
front-end does no data flow analysis beyond attempting to evaluate expressions.

In the middle-end, to expose dependencies between statements (such as the
dependency of expr on cond in "if (cond) { expr; }" the warning would depend on
various transformations done by optimization passes (such as constant
propagation and dead code elimination).  Some of these transformations could
also simplify or remove expressions that involve constant overflows, leading to
false negatives, and others could introduce them even though they didn't exist
in the original code (e.g., along new code paths that may never be even
executed), causing false positives.

Bugs certainly should be raised for these problems (and many have been) but
because of the complex interactions between the transformations they tend to be
quite difficult to fix, and some can't be fixed at all.  The net result would
be a trade-off between one set of fairly simple bugs or complaints vs another,
much more complex bugs.  There are a number of examples of these trade-offs in
Bugzilla with even more discussion on gcc-patches.  This doesn't mean that
warnings shouldn't be implemented in the middle-end, just that they aren't
going to be perfect there either, or make everyone happy (in fact, simple
warnings like -Woverflow tend to be less controversial than data flow warnings
because they are for the most part decidable.)

In any case, since bug 4210 already tracks the enhancement you would like to
see I propose to close this as a duplicate of that bug.  Please let me know if
you disagree, otherwise I'll go ahead and resolve it as such.

Reply via email to