https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100477
--- Comment #5 from andysem at mail dot ru --- (In reply to Martin Sebor from comment #4) > 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 But sizes above PTRDIFF_MAX are valid sizes. IMHO, triggering the warning based on possible sizes is just not the right approach to begin with. If what you're trying to detect is an integral overflow then *that* is what should be detected, and pointed to by the warning, not the unrelated memset. As an illustration to my point, I worked around this warning by replacing memset with std::fill_n with no other changes to the code. The optimizer will likely convert it to memset anyway. This shows that (1) if the supposed bug is an overflow in `_size + 4` then it is no longer being detected and (2) there is no problem in filling more than PTRDIFF_MAX bytes (as expected, of course). > 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. False positives is a very good reason for the warnings to be disabled or ignored, meaning that they are useless. Is there any reliable detection implemented in -Wstringop-overflow? Meaning that, when the compiler can tell "there's definitely a bug", as opposed to "there may be something fishy going on"? If yes, then it may be sensible to separate the reliable and speculative parts into different warnings. Personally, I would like to have a warning when the compiler is certain that something is wrong, but not the false positives, like shown in this bug. That's the only thing stopping me from just disabling this warning globally. > Unhelpful warnings can be > disabled either globally, on the command line, or on a case by case basis by > #pragma GCC diagnostic. #pragma GCC diagnostic doesn't work with LTO. I was actually suppressing that warning in the real code base with a #pragma, but it no longer works when LTO is enabled by default in my distro. > 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. Again, that precondition is incorrect.
