https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100477
--- Comment #6 from Martin Sebor <msebor at gcc dot gnu.org> --- In C/C++ the size of the largest object is PTRDIFF_MAX - 1 bytes. This is necessary so that the difference between the address of its first byte and that just past its last byte fits in ptrdiff_t. A number of GCC warnings point out code that breaks this assumption, including allocations in excess of the maximum or calls to functions like memset or memcpy that would access more than the maximum. None of these warnings considers the conditions that must be true in order for control to reach the problem statement, so if the statement hasn't been eliminated from in the IL (i.e., can be seen in the output of -fdump-tree-optimized or whatever pass the warning runs in) the warning triggers. Taking the conditions into consideration and issuing "maybe" kinds of warnings (like -Wmaybe-uninitialized) is a work in progress but as of now no warning other thanb -Wmaybe-uninitialized does. No such distinction as "there's definitely a bug" vs "there may be a bug" is feasible because there is, in general, no way to identify functions that are defined but never called, or those that are only called with arguments that make certain code paths unreachable. As a result, with few exceptions every GCC warning is of the latter kind. If you're interested, the following two-part article discusses some of the challenges in this area: https://developers.redhat.com/blog/2019/03/13/understanding-gcc-warnings/ https://developers.redhat.com/blog/2019/03/13/understanding-gcc-warnings-part-2/ If the #pragma suppression doesn't work with LTO please report that as a separate bug. There's nothing we can do to avoid the warning in this case.
