https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88771
--- Comment #11 from Martin Sebor <msebor at gcc dot gnu.org> --- I understand what jump threading does but I don't know enough about how it works to have a clear idea how viable marking up the created statements would be. To avoid false negatives it would need to make it possible to distinguish invalid statements in the original code from invalid statements it introduced. At the time it runs there may not be a way to tell one from the other yet (the distinction between valid and invalid isn't exposed until after the constants along the newly introduced path have been fully propagated into those statements). I have been meaning to look into it for a couple of releases. It won't happen for GCC 9 but in 10, the planned integration of the strlen and sprintf passes (and perhaps also -Wstringop-overflow, and maybe even -Wrestrict, which would include this warning) may be a good opportunity to experiment with some of these ideas. That said, no solution will ever be perfect. There will always be some false positives (and false negatives), no matter how early or late these warnings run. What I think is even more pressing and important than the redesign (and far more realistic than hoping it will completely solve the problem) is to make #pragma diagnostic work reliably for middle-end warnings.
