https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94675
--- Comment #14 from Martin Sebor <msebor at gcc dot gnu.org> --- I can think of only one way the warning code could avoid triggering here: by assuming that the difference between two pointers into the same array is less than or equal the size of the array (with non-array objects being viewed as arrays of a single element). That's necessarily true in any valid C/C++ program so it would be a safe assumption to make here as well. Since there is no array subscripting involved here, issuing -Warray-bounds might also be considered inappropriate, and the warning could be made not to trigger. But that would just mask the problem which would come back if __ps_skip attempted to access ps->s[len]. It would also come back if/when GCC started to warn more diligently for forming out-of-bounds pointers (I already submitted one patch to do that and the work I'm doing in the path isolation pass is an opportunity to revisit the feature). So we're back to deriving assumptions about the results of pointer arithmetic based the sizes of pointed-to objects. The warning would need to work quite hard to figure this out in general, so hard that I don't think it would be worth the effort unless it benefited code generation as well, or at least all other warnings like it (-Warray-bounds isn't the only one that can be triggered -- a number of others could be made to). Which was also the point of my comment #1 (and related to Richard's observation in comment #4 about an missed optimization opportunity). That said and codegen improvements aside, I think the submitted test case is sufficiently tricky that I don't see issuing a warning for it as a problem. All flow-based warnings have a non-zero rate of false positives (as do many front-end warnings) and there are mechanisms to avoid them. Compared to some of the other false positives we have, avoiding this one seems like a low priority to me.
