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.
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
