On Sun, Aug 3, 2014 at 1:40 PM, Guy Harris <g...@alum.mit.edu> wrote:
> 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. > I could have sworn my autotools builds used -O2... *goes to check* Yup, my master-1.12 vanilla autotools build adds -O2 to CFLAGS and CXXFLAGS. I don't have a master autotools build handy, but I can't recall any changes that would have affected that... > 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. > I vote that: 1. In development (i.e. the default when getting the git repository) we default to -Og for compilers which support it. The GCC 4.9.1 manual says: "Optimize debugging experience. -Og enables optimizations that do not interfere with debugging. It should be the optimization level of choice for the standard edit-compile-debug cycle, offering a reasonable level of optimization while maintaining fast compilation and a good debugging experience." And fall back to -O2 when the compiler does not support -Og (older versions of GCC... I dunno about clang). 2. In release builds (including source tarballs and buildbots) we default to -O2.
___________________________________________________________________________ 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
