https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105562
--- Comment #27 from Jakub Jelinek <jakub at gcc dot gnu.org> --- That is just a very partial solution. As mentioned in lots of other bugreports, one should simply ignore or take with a grain of salt warnings from the instrumented builds (whether it is -fsanitize=undefined, -fsanitize=address, -fsanitize=thread or I think -fprofile-generate or similar as well). Any such instrumentation significantly modifies the intermediate language and prevents various optimizations which necessarily lead to more false positives in the non-frontend warnings. So, best similarly to what libtool does when compiling a file twice, once with -fpic, once without, redirects diagnostics of one to /dev/null, go with 2 builds, one sanitized/instrumented with -w, another non-instrumented with full warnings. The big question is if the compiler should do that by default (simply ignore all middle-end warnings in instrumented functions), or if we should provide some support in the driver for building stuff twice, once instrumented without middle-end warnings, once non-instrumented with warnings. We already have -fcompare-debug which does something similar (build normally and -gtoggle -w.
