I've noticed, on occasion, that sometimes the CMake builds on the UN*X buildbots get warnings that the autotools builds don't.
Recently, I tried to figure out what was different about the CMake builds; after some fixes that removed some incorrect differences between them, I eventually stumbled across the way to get CMake to produce makefiles that did verbose builds, printing the compile command as part of the build output, and found that the difference was very simple - autotools builds weren't building with a -O option, while CMake builds were building with -O2.
The optimizer is what does some, if not all, of the dataflow analysis that produces "use before set" warnings, so those warnings were showing up on the CMake builds but not the autotools builds.
So:
Is there any reason not to do whatever is necessary to use a -O option on the autotools builds? In addition to getting extra warnings from optimized builds, we also presumably want optimized code in the binaries we ship, and want to at least require third-party packagers to explicitly decide *not* to ship optimized code.
Should we use -O2, -Os, or some other option (for both autotools *and* CMake)? The GCC 4.9.1 manual says of -O2
"Optimize even more. GCC performs nearly all supported optimizations that do not involve a space-speed tradeoff. As compared to -O, this option increases both compilation time and the performance of the generated code."
and of -Os:
"Optimize for size. -Os enables all -O2 optimizations that do not typically increase code size. It also performs further optimizations designed to reduce code size.
-Os disables the following optimization flags:
-falign-functions -falign-jumps -falign-loops
-falign-labels -freorder-blocks -freorder-blocks-and-partition
-fprefetch-loop-arrays"
and the Clang manual at
http://clang.llvm.org/docs/UsersManual.html
says, err, umm, nothing useful, because it really sucks at documenting command-line options.