https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86768
--- Comment #3 from Martin Sebor <msebor at gcc dot gnu.org> --- Yes, the warnings are issued by call expansion. In past reports like this one Jeff has made the argument that warning for such code is appropriate (e.g., pr82103 comment 4) or that it highlights missed optimization opportunities, or both. In my opinion, this one is an example of both: the code is reachable (provided the right argument values), but GCC could also avoid introducing invalid calls to built-ins. It could either avoid threading that case if it detects one, or it could emit a trap/unreachable instead. It could be done with or without a warning (Jeff has argued for a trap and a warning). If with a warning, it could be a different kind of a warnin (a "may exceed" rather than "exceeds", analogous to -Wmaybe-uninitialized). I can look into implementing this when there is consensus on how to handle these situations. By moving the warning earlier to avoid dealing with these cases we would miss out on both opportunities.
