https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79265
--- Comment #6 from Franz Sirl <sirl at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #4) > This is a new warning, the fact that we didn't warn on some code and now > warn with a new warning is not necessarily a regression. Well, I wasn't so sure either if it counts as a regression, that's why I asked on IRC first and then changed it. If you feel otherwise, you can remove the marker again. I guess it is kind of a "usability regression": - "gcc-6 -Wall -Werror": compiles - "gcc-6 -Wall -Werror -fsanitize=undefined": compiles - "gcc-7 -Wall -Werror": compiles - "gcc-7 -Wall -Werror -fsanitize=undefined": doesn't compile because of false warning So it's no longer enough to "just add -fsanitize=undefined" and recompile, now you have to adjust warnings as well. If it can't be reasonably solved within the GCC-7 timeframe, I would be fine with a stop-gap measure like removing -Wformat-overflow from -Wall when UBSAN is active (for example).
