I wonder how much harder this approach will make compiler updates for them.
Today clang will typically build all of google's software with the new warning on and look at the results. Then they look at each one and decide if it is a real bug or false positive. For the real bugs they look at how serious each bug is (if it is a previously unknown security hole that worse than it could fail in the real world only in unusual situations). For false positives they consider silencing the error changes the code (in some cases the code is very ugly and cleaning the code up fixes the warning, while in others the code was good until the ugly stuff to silence the warning was added). Then the consider the rates of all of the above to decide if the false positives are worth the potential gains. I believe other compilers do similar things, though I don't have insight into their processes (Chandler Carruth gives great talks at C++ conferences on clang which is where I get my information).
Compiler writers are in competition in this area. As a result most things that should be warned about are already warned about, while things that are not worth warning about are not warned about. Thus updates to the compiler are quick because you keep having "how did we ever get by with this mistake" moments, which in turn keeps you motivated to fix the next warning.
Still, I wouldn't expect so many of these that updating a new compiler would be too onerous.
Conversely, here's one where a warning is produced only without -O2:
orth$ cat z.c
int foo (int a) {
int x;
if (a == 5) { x = 3; return 42; }
return x;
}
orth$ gcc -O2 -Wall -o z.o -c z.c
orth$ gcc -Wall -o z.o -c z.c
z.c: In function ‘foo’:
z.c:4:4: warning: ‘x’ may be used uninitialized in this function [-Wmaybe-uninitialized]
return x;
^
orth$ gcc --version
gcc (Debian 4.9.2-10) 4.9.2