Getting Familiar with GCC Parameters
Subject:   Forwarded: Comments from Henrik Nordstrom (Squid developer)
Date:   2007-05-31 23:42:47
From:   mulyadi_santosa
Recently, some people gave me feedback via e-mail. Since I think their comments are valuable, I copy them here. Please consider them as both errata and critic:

Page 1, at the end. You talk about branch prediction. GCC can do better if you give it feedback using profiling of the actual use of the code, without any need to manually instrument the code with hints. See the -fprofile-use and -fprofile-generate options.

Also -O3 does not always generate faster code than -O2. In most cases it does, but it also enlarges the code size by more aggressive inlining and loop unrolling which might cost a bit in cache misses on modern CPUs.

Page 2: GDB actually works pretty well with -fomit-frame-pointers if the program is built with gdb debug data using -ggdb or just -g on platforms where gdb is the default debugger such as Linux. But it's true that a backtrace will not show you the full trace. Also true in general when
using -O3 (or -O2 with manually inlined functions) which gets even more confusing to debug.

Page 4: Using -E as a general preprocessor for things like HTML is not such great idea. Easy to get bitten by various implicitly defined symbols and some C preprocessor assumptions. I would advice against recommending this as one possible application of -E.

It is what it is meant to be used for. To check what the pre-processor did to your code, or on other words what the compiler actually compiled.
With complex macros etc it is not always obvious, and it's easy to get badly bitten by a missing () in a macro or similar which isn't obvious when reading the original source.

Trivial example where -E helps in explaining what happened:

#define ADD(a,b) a + b

int a = ADD(5,6) * 4