The most useful GCC options and extensions
antoarts.com"If Java had true garbage collection, most programs would delete themselves upon execution." — Robert Sewell
Nice ;-)
How is that nice? And I can't find this quote in the article.
It's in the sidebar. Just amused me is all.
The quotes are randomly chosen from a database of my favorite ~50 quotes, so it isn't related to the article, though
I was definitely not expecting an article about useful GCC options to mention -trigraphs. The -ansi option isn't particularly useful either, imo, since just about every interesting program is going to do something crazy like open a network socket or list the files in a directory.
By far the most useful gcc extension wasn't mentioned at all. typeof().
I mentioned trigraphs as an example of a C standard feature disabled by default in GCC, and then I just mentioned how to enable just that feature. It wasn't supposed to be included among the most important options, it just got there ;-).
Has anybody used the __builtin_expect feature to good effect? We had been using this extensively in our codebase in places where there is an obvious common "fast path".
I tried an experiment where I did a comparison of the __builtin_expect version against a version with our likely/unlikely macros defined to the identity, and I actually saw no difference, which was disappointing. When I did some digging I found this blog post: http://bitsup.blogspot.com/2008/04/measuring-performance-of-... which suggests the same result for the Linux kernel.
FWIW GCC also has a reasonable set of PGO options (not mentioned in this article), and those actually can (anecdotally) make a noticeable difference, although you're subject to the overtraining problem if you're not careful.
Another useful GCC extension is statements within expressions:
#define max(a,b) ({ typeof (a) _a = (a); typeof (b) _b = (b); _a > _b ? _a : _b; })
A few others I use are -Wsign-compare and -Wformat-nonliteral. Sign compare warns on possible bugs/vulnerabilities due to comparing signed and unsigned values. Using nonliteral formats can lead to vulnerabilities (such as the famous attacks on FTP servers http://seclists.org/bugtraq/1999/Sep/328)
-Wall includes -Wsign-compare
You must be a C++ user -- I (a C guy) immediately thought "what? No, that's in -Wextra, not -Wall", checked the man page to confirm, and sure enough, it differs (-Wall includes sign-compare when compiling C++, but not C).
Sometimes when compiling and trying to use system calls gcc will complain about the functions not existing. This is usually because of some preprocessor guard not being defined. An easy way to see what macros have been defined is to run gcc with the "-E -dM" flags.
-fmudflap always interested me, but I never seem to remember it when I'm actually confronting a hard to debug pointer issue.
My favorite is the "weak" attribute. http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html
Makes separate compilation for languages that compile to C much easier.
My favorite would be "pure" -- it's perfect for saying "this function pointer, which calls an assembly function, doesn't muck with any of your data structures, so you don't have to reload every single pointer after it returns".
But unfortunately, since it was basically written only for libc purposes, it doesn't work on function pointers, so it's useless for this purpose.
Is it me, or is this statement from the article wrong:
"All warnings can be enabled with -w."
man g++ says:
"-w Inhibit all warning messages."
Inhibit means to prevent (not to enable).
It is case sensitive; -W enables more warnings, not -w, which as you noticed suppresses them.
Thanks for mentioning that. I fixed my mistake.
No love for --coverage?
A similar article about C code coverage tools would be great.