https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103483
Aldy Hernandez <aldyh at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |aldyh at gcc dot gnu.org,
| |amacleod at redhat dot com,
| |jwakely.gcc at gmail dot com
--- Comment #6 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Martin Sebor from comment #4)
> I don't think this can be "fixed." Most middle end warnings work a single
> statement at a time and depend on optimization like constant propagation and
> dead code elimination to do their job. If one optimization exposes an
> invalid statement that would otherwise be eliminated by another optimization
> that doesn't take place, the warnings trigger. That's all by design and
> there's no way change that. In the test case in comment #0 where the
> precondition is that d be less than a, making it explicit (e.g., either as
> Andrew suggests in comment #1 or by adding an equivalen assert statement)
> seems like the best and only solution.
Oh, it totally could be fixed. Whether you want to or not, is a separate
issue. These false positives "by design" arguments are just a cop-out.
As Jonathan said, if the warning code can't handle the IL as presented, it
should give up, not assume code is wrong by default.
It seems we do very bad with a lot of these warnings at -O1. We should just
disable them at low optimization levels if we can't/won't take measures to
reduce the false positive rate here.
