https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103483
--- Comment #18 from Jason Merrill <jason at gcc dot gnu.org> --- (In reply to Martin Sebor from comment #17) > https://developers.redhat.com/blog/2019/03/13/understanding-gcc-warnings- > part-2 Yes, this is a good description of the general problem. > It might seem like the common denominator in all these instances is ranges, > but they're a red herring. The same effect can be demonstrated without > them. The root cause behind them all is that (again) warnings are designed > to trigger for apparently reachable invalid IL. But for this and several other warnings, we only think it's invalid because of ranges; I disagree that they're a red herring. > If you consider any of the warnings above false positives you must consider > as such all of them. Agreed. > The best solution, in my view, is to show users the conditionals > under which the invalid statements can be reached. I hoped to be able to do > that by extending Ranger > (https://gcc.gnu.org/pipermail/gcc/2021-December/237922.html) This sounds useful, and somewhat related to what I was trying to suggest: recognize the case where the only information we have about a value range is path-derived, and make that subset of warnings optional, for warnings we don't give when we have no information at all about the value range. To put it another way, if the only reason we think a statement is invalid is because of information deduced from conditions we took to get here, we probably don't want to warn by default.
