https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100477
--- Comment #8 from Martin Sebor <msebor at gcc dot gnu.org> --- The PTRDOIFF_MAX limit is a general restriction implied by the language requirement that the difference between any two pointers must be representable in ptrdiff_t. In practical terms, GCC internally represents pointer offsets in a type like ptrdiff_t so all pointer expressions are so restricted. To enforce the restriction and prevent bugs, GCC rejects declarations of larger types or objects with an error, and issues warnings for attempts to create others (malloc, VLAs). Most LP64 systems (all major Linux distributions) have much lower limits still (see for example https://access.redhat.com/articles/rhel-limits). Calls to malloc() fail with sizes far smaller than that, the stack cannot grow to accommodate them, etc., so any access of that size is inevitably an error (solutions like PAE are bound to run into the GCC internal limitation). As for the alloc_string() example, there is no way to differentiate between the two kinds of cases you mention. A single code path can be split into two or more with constants propagated into each, rendering one or the other unconditionally invalid even when the original code is valid for a subset of operand values. This is a limitation inherent to all flow-based GCC warnings (those that depend on optimization). The static analyzer (-fanalyzer) doesn't depend on optimization so it's not prone to this effect. Submitting a bug for the LTO problem is only helpful if it comes with a test case to reproduce it. I have heard about problems suppressing warnings in LTO builds but I'm not aware of it being a design limitation, and other than the mention of the inlining caveat (the -Wstringop-overflow example) I can't find it mentioned in the LTO section of the manual pointed to by the link.
