https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100477
Martin Sebor <msebor at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |88443 --- Comment #4 from Martin Sebor <msebor at gcc dot gnu.org> --- The case of _size being very large and n very small may be handled correctly by the original code thanks to the check for _capacity but because its value isn't known it affects neither the codegen nor the warning. The warning is designed to flag bounds greater than PTRDIFF_MAX and that's just what it sees here as is evident from the output of the -fdump-tree-optimized option. There is nothing to fix here. Code that's unreachable as a result of preconditions GCC cannot prove may be susceptible to false positives. That's a problem shared by all flow-sensitive warnings, not just in GCC but in all static analyzers with flow analysis. In general, GCC warnings are designed to "report constructions that are not inherently erroneous but that are risky or suggest there may have been an error." Not every instance of every warning necessarily corresponds to an error, and some may even be false positives. Unhelpful warnings can be disabled either globally, on the command line, or on a case by case basis by #pragma GCC diagnostic. Adding preconditions like 'if (_size >= __PTRDIFF_MAX__ / 4) __builtin_unreachable ();' (the 4 should be replaced by sizeof (value_type) in the original test case) often helps not just warnings but also codegen. They're not required but can be helpful and preferable to suppression. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 [Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings